Decided to finally get to know GitLab a bit more for the sake of backing up my project and hopefully setting things for version control if I work collaboratively in the future. Thing is, I hate git shell and command line stuff and vastly prefer the ease of GitHub. So I took some time to figure out the handshake between them. Here I’ll try to explain the setup process as simply as I can.
First, create your repository from GitLab. GitLab is essentially a git server that Penn State works with to keep their projects internal. If you have access to it, you can login through Penn State Web Access and reach the GitLab at git.psu.edu. Once there you can set up a group (which essentially acts as a folder) or create your new repository right under your name. Either way, once the repository is set up, you can use it as you want if you’re cool with git shell or other git commands, but to make things easier we can link the repo to GitHub instead for a nice clean UI to work with.
Obviously, you need to set up a GitHub account and download the GitHub desktop application first. Once you got those up and running, head back to GitLab, go to Profile Settings and click on Access Tokens (or, alternatively, just go to this link: https://git.psu.edu/profile/personal_access_tokens). Here you’ll set up an Access Token that will act as a password GitHub can use to access your GitLab. Set the name to whatever you want, it’s just a reference in case you need to revoke the token later for security purposes. Be sure to check all the scopes so things can get done. Once you’re ready, generate the token and be sure to copy and save it somewhere securely on your computer. This is the only time you can see the token at all and you will need it in the future, so be sure to keep it accessible.
With all that done, we should have everything we need to finish the setup. Simply go to your GitLab project and under the “Clone” tab, copy the URL. Go to GitHub and Clone a Repo from URL. Paste the URL and select an empty folder on your computer to use as your repository location (make sure you put it somewhere it can stay cause otherwise you’ll have to handle the pain of moving the folder and telling GitHub where it went). When you select to clone, you’ll get an authorization window saying you need to enter a Username and Password. This is what confused me for a while, but it’s actually pretty straightforward: the Username is your GitLab username (which is most likely your Penn State login) and the Password is your Access Token. If you enter those right, the repo should be set up fine. Now if you copy and paste your project into the repo folder, GitHub should recognize the changes and list a LOT of files. If so, you’ve got things working right.
Now, something else to make sure of before you commit and push stuff, you need the proper .gitignore setup. Go to https://github.com/github/gitignore and find the proper file for the project type you’re working with. In my case, doing Unity work, I needed the Unity.gitignore. Click on the one you need, then copy the text into a new blank text document. Save the document as simply “.gitignore” and place it in the root of your repository (the base folder you chose when setting up the repo on your computer). This will let Git ignore all the weird files like .bin that are in the folder which don’t need to be saved.
Once the .gitignore is set up and your other files are in place, add a name to your commit and hit “commit to master”. If things go right you should have no issues. There may be some things like files that are too big to commit. Make sure you’re only committing project files and not stuff like large videos or Adobe files. Once the commit goes through, hit “Push to Origin” and hope everything goes smoothly. If it does the push right, once it’s finished you should be able to refresh your GitLab page and see the files now in the folder like so:
Now any changes you make to the files in that repository folder on your computer should show up in GitHub for committing and pushing to GitLab. This works as a nice, consistent backup for your files when working alone and SHOULD make it so you can work with others on the same project. I say should because in doing that you now enter the realm of possible “merge conflicts” wherein both people edit the same file and try to push only to get the system confused as to what to keep and what to get rid of. In this case, you need some work to separate the commits which I don’t have the experience with currently. To avoid this, if you’re working collaboratively, ALWAYS remember to push your work when you finish your tasks for the day, ALWAYS remember to pull the latest branch before you start working, and ALWAYS remember to not save anything you’re not working on. If you know someone’s tweaking the main scene, stick to editing code or something else and make sure they’re done and you pulled before doing anything in the main scene yourself.
Leave a Reply