Expanded Gitlab Information

This is an addendum to my previous post on setting up Github with Gitlab. We’ve decided to start doing some expanded things with Gitlab, so felt I should lay out some things for those new to the system in general.

First and foremost, we have a CIE group on Penn State’s Gitlab. All members related to CIE are being added to it and that group should be where all new CIE repositories are created under. This is important for that first step of my previous post where you create the repo. Be sure that it’s under CIE by selecting “cie” under the Repository URL dropdown. This will let us keep all the projects collected and hopefully make it easier to find and hand off repo links to people that need various project files. During this setup, you should also check the box to “Initialize repository with a README”. This will make it easier when cloning the repo through Github to set up the connection properly.

Another important thing to keep in mind when creating the repository is the visibility level. Gitlab provides 3 options for visibility: Private, Internal and Public. Private means the project will only be visible to those within the CIE group. This is good for when you’re just setting up and working on the project. Internal means anyone with a Penn State ID can find the repository by searching the PSU Gitlab. This level should be used for larger University projects that aren’t going to be shared outside the University. Finally, Public level can be seen by anyone without any login. This would be the final level for smaller projects that we want to design to share as a codebase for everyone. Only Owner level CIE members can change the repository visibility.

Next, an important step we found out while working collaboratively: when setting up a project, make sure the .gitignore file is properly set up first, before you start adding your project files. You can find various examples of gitignore just by googling. For example, the common Unity gitignore can be found here. There’s a few ways to set up a gitignore if you don’t just have the file already on hand. One method is using Github. If you go to the Repository Settings (after having the repo set up and connected of course) you can click the “Ignore” tab and paste the gitignore text there. Alternatively, you can easily create a blank text document using Notepad/TextEdit and copy-paste the gitignore code into it. Then be sure to save the file as simply “.gitignore” and place it in the correct part of your folder structure. By correct part, I mean to look at the gitignore: if it says just “/[Ll]ibrary/” in it, be sure you’re putting it on the level where the Library folder is visible. If you put it a folder to high or low in the heirarchy, it can’t find the folder it’s trying to ignore and you’ll get a lot of junk added that’s awful to try and remove. So for a Unity project, the gitignore should be in the same folder as the Assets and ProjectSettings folders.

Now for a bit that may not come up with many users, but still important to discuss. If you’re working on a project collaboratively, you need to make sure to avoid merge conflicts. To do this, when working with others on the same repo, always make sure to do your work in a new branch. By making a new branch, you can avoid messing with the project while others are trying to make stuff on their branch. You then merge the branch back to the main repo once you finish whatever task you were working on. Before you merge your branch, be sure to pull the repository and do “Branch -> Update from Master”. This will give you a box with any possible file conflicts if the master branch has been updated while you were working on your own branch. If you’re doing it on Github Desktop, you should get little dropdowns to choose which files to keep to resolve the conflicts. Afterwards, you should be able to safely merge your branch. Again, this is only really an issue for groups working on the same repo at the same time, but still good to know.

This post may have some additional points added in the future, but for now, we’ll leave it at that and hope things go well with moving our larger group to Gitlab.