"So what do we do now?" Lessons on learning Git during GlobalGameJam

Last weekend I had the opportunity to take part in GlobalGameJam once again. Being my third time going to GGJ, I seem to be creating some sort of tradition: each time was a different location and each time I worked with people I just met.

A Unique Scenario

While each time it was different, this year was an especially great and unique experience. It was the first time I was a part of a large team. In fact it was large by accident; during the idea pitch and subsequent recruiting, multiple members recruited at different areas of the large room and it wasn't until it was over that we found how big the team was: 13 in all. We unfortunately couldn't contract a burgler to be our lucky number person on our journey.

As soon as we went off to our work locations, I knew that one of the challenges with such a large team was going to be logistics. Along with the game concept, we discussed our options on how our production was going to go.

We initially thought dropbox was our best quick and dirty solution for source control. It had benefit of automatically syncing changes and conflicts sometimes become "NAME (X's conflicted copy DATE).TYPE" instead of being overwritten. Our other idea was using Google Drive desktop client which works similarly. We decided to go with dropbox and try setting it up.

However we ran into our first logistical problem; the facility's computers had their admin privileges locked, which prevented us from installing most software, especially dropbox.

"So what do we do now?"

So... Git?

Instead of having to resort to passing project files via a USB drive, I proposed that the people who were going to work with Unity3d try using Git for our source control.

It was risky proposal; my experience on Git was limited. In fact, the last time I used it was the previous GlobalGameJam which luckily my awesome team mates were able to coach me step by step how to use Tortoise Git. The other programmers experience with Git was limited to nonexistent as well, but the challenge seeker inside me wanted to learn more at this jam.

By stroke of luck, Github for Windows client was able to install without admin privileges, so it did end up as our solution. The rest of the team stayed with Google Drive where they would upload assets that we could put in Unity.

After installing Github for Windows on the facility computers, we were ready to start developing! We started the Unity project, synced... and ran into conflict issues quickly.

Lesson 1: The value of .gitignore

Whenever we tried to commit on our Unity project, there were the files we worked on and then there was a huge list of other files, most of them were from the /Library folder and especially the /Library/metadata folder. Those files were the culprit of a majority of merge conflicts.

This brings us to our first lesson: using .gitignore!

Before, I haven't thought much on the .gitignore file; I've seen it on a few open source projects and at last year's gamejam I was oblivious to its function since a more experienced team member has set it up perfectly.

What I learned is this file is your ally in Unity project source control. It will be your faithful wingman following your orders as the Wing Commander. It does precisely what its name suggests, it makes Git ignore whatever files and folders you tell it to.

As soon as I discovered that, I told the team members and we started adding the worst offender files that caused merge conflicts. Immediately it was becoming easier to synchronize. Some of the files were still not getting ignored, however it was manageable (later on I learned that git 'remembers' files after they were committed).

Lesson 2: Learn what to NOT .gitignore

One of the things that slipped into the .gitignore sometime was a *.meta rule. I didn't notice it since I was busy setting up the player health and a variety of other tasks. However hours later is when the we looked at each others' scenes, many objects had all sorts of missing references, from missing textures to missing scripts.

Commit: "It turns out that meta files are important after all" - Justin

Like any computer, it's only works as good as the commands you give it. With great commands, your life is so much easier, with poor commands you're left with a larger headache. Which brings us to the overall lesson.

Lesson Stupidly Obvious: Do some research before hacking away

There are things you can easily spot from a distance, especially in hindsight. I know that someday I will read this knowing truly clueless I was, like what some of you are thinking right now.

Some of our early headaches could have been prevented through looking up the Unity documentation on source control. And instead of having to manually add rules to the .gitignore we could have gotten one already made for Unity projects like this awesome one by Kleber Lopes da Silva. We were fortunate to find these resources halfway through and on the last day of our jam respectively, so it wasn't a total loss.

Lesson 4: Know the limitations of your repository host

During the morning of the final day, it was time to download and implement the final assets that were finished the evening before by our awesome art team. I took upon the task of downloading them from Google Drive's Final Assets folder and put them in the project. I did precisely that, committed and started uploading, easy!

remote: error: File Assets/FinalArt/Asteroids/Asteroid_Final(High).obj is 180MB; this exceeds Github's file size limit of 100MB

Turns out Github has a hard limit on file's size that can be uploaded. The file in question was actually a high-poly asteroid one used to create the title screen image and wasn't meant to be used as in-game asset, oops. So I deleted it, committed and tried pushing again. Same Error.

After looking up how to fix it, I eventually ran into this piece of information. It turns out just having a file that size in your commit history is enough to throw that error. I tried following the instructions, spending too much precious time learning command line syntax and downloading tools to no avail. In the end, I saved the folders with the new assets, deleted and re-downloaded the project and put them back in without the large file.

Sometimes the best way to fix a Git problem is to not do it through Git.

Lesson 5: Make sure everyone on your team is (near) current

In the last two hours, we were ready to hook up our two scenes together to complete our GlobalGameJam project! Things were looking up.. until a problematic merge ended up screwing with our Main menu script. That script somehow got reverted to a version many hours earlier since one of us edited the previous version and resolved the conflict with theirs.

Luckily it was recorded in the version history. However unluckily monodevelop was throwing a fit and we couldn't copy/paste anything into it. It was a last-hour WTF moment; I somehow managed to pop a stress ball at this time to hilarious effect. In retrospect that problem probably came from our hack to get Unity to run on the facility computers without "installing" it.

That rewrite and the final details were worked on in the last few minutes, but it got done and Rocksteroids was successfully completed!

A Successful Jam

Despite it all, this was the smoothest gamejam I've been a part of. We managed to implement all of our chosen features (which I think is mindblowing) and work on some polish as well! Most of us even got to sleep both nights!

And through this trail by fire of learning the lessons, I feel comfortable enough to start using Git as a source control for my future projects. There's still plenty of concepts to learn (such as forking), which I'm sure would have helped in some of the scenarios we encountered. And after reading about Dolphin's development setup, it appears I've just scratched the surface of Git's power for source control.

I hope that this was informative for some newbies, and at the very least some comic material for those more knowledgable in these matters.