Even though I’m in the final class of my computer science program, nothing puts more fear into my heart than the concept of operating a group GitHub repository. After talking to a few of my classmates and reading some testimonials online, it seems that I am not the only one.

How Not to Use GitHub

In one of my first group projects, one of my team members wrote a large portion of the code at the last minute and put it up and GitHub. Of course, he checked it into the main branch because we did not have any main branch protections.

Since he was in a different time zone, he made major changes to the code without checking in with us. Since he was using a different IDE, files were checked in that shouldn’t have been and we encountered all sorts of errors trying to run it on our IDEs. No one knew how to use a git ignore or any sort of real git commands. As a result, we had to re-base our whole project on his code and try to merge ours in manually with one person entering the code into his files. My code and another member’s code stayed dormant in lonely, separate branches, with no one understanding how to make pull requests.

Even if you understand the overall process, it’s easy to get knee deep into git and lose your place. One of my classmates mentioned accidentally making their whole computer into a GitHub repository. A quick search online brought up some similar stories. There are plenty of traumatic git interactions to be had. Why else would a site called Oh Sh**, Git!?! exist in the first place

Gitting the Basics

I was really relieved and interested when one of my later courses devoted a lot of time to git, GitHub workflows and continuous integration techniques. After completing this class, I had a much firmer grasp on basic git commands and best practices. One of the hardest concepts for me has been the staging vs. committing process. In fact, even this week, my group mate and I realized that we erroneously had expected that a file on the group repository would be deleted from that location if we added it to a local gitignore file. We kept trying to push the local changes, expecting that file to go away, when really, we were just replacing every other file in the repository. This went on for an hour – which is really painful when you are working full time and going to school. But it was good for a laugh when we realized the flaw in our logic. Yes, it seems really dumb now, but when you really get into the weeds with this stuff, you can easily think git staging follows a different convention.

Every new group interaction brings the possibility that people won’t follow the basic tenants of frequent commits, reviewing pull requests before checking them in etc. So I was glad that my current group mates understood the value in methodically following a standard continuous integration workflow. We will still have plenty of merge conflicts to deal with while working in the same Unity project, but at least there is hope.

It Could be Worse

It’s only fair to talk about an even worse nightmare scenario than using git: trying to have a group project without using a shared repository. Unless each member is dealing with a discrete area of the code and one person is tasked with combining all these together, a group project without a repository seems pretty unworkable. While it does have a bit of a learning curve, the git repository is surely worth that investment.