I think you’d identify pretty well with my dear friend Peter.
Growing up in Queens, New York, he was a tremendous nerd and outcast. Today it might be cool to be into nerdy things, but Peter loved science back when you’d get beat up for admitting that sort of thing to your friends.
Peter took advantage of being shunned, though, and turned it into a bit of a superpower. Encouraged by his aunt and uncle, he excelled so much in school that he got a full scholarship to college. But it was there that his story took a life-changing turn.
For one of his classes, Peter had to attend a demonstration about nuclear radiation. During the talk the craziest thing happened – he was bitten in the arm by a bright neon glowing spider! Absolutely shocked and very grossed out, he shook the now dead spider off and instantly began feeling very ill.
Luckily, he made his way home to safely. But, when he awoke the next morning, he looked at his hands and was shocked! As you’re expecting, Peter Parker did indeed have superpowers from a radioactive spider bite – he now completely understood how to use Git and GitHub!
Okay, so maybe that’s not exactly how the story goes – but when it comes to game audio, having a solid understanding of Git and similar “source control” software is indeed a superpower that will set you apart and help you save the lives of others just like Spiderman does.
Today, let’s go over three basic Git commands that can be utilized with GitHub Desktop which will give you the skills you need to be useful in AAA studios incredibly quickly:
- Pull
- Commit/Push
- Diff
Real quick before we go any further – after reading this I’ll be recommending next steps for you to step through what you’re about to learn on your own time. Don’t worry, it’s super easy, and you won’t need to become a programmer to do it – just make it to the end!
“Pull” is the act of syncing remote repository data to your local computer.
If you’ve never worked on a game or any other software before, that heading was probably a little daunting to you. But, it’s not as complicated as it seems, I promise.
Long before multi-synchronous text editing systems like Google Docs or automated cloud backup systems like Dropbox existed – there was Git and other types of source control. The basic idea is simple – you have a local copy your software’s source code and content on your own PC, and there’s also a copy in a remote “repository” or “depot”. In modern terminology, the terms “remote” and “cloud” are pretty synonymous: server computer that isn’t yours.
With one person involved, this system looks more like a glorified way to backup or share your data with strangers. But, give numerous developers access to the repository and you have a solution for a fully-fledged software company.
So, unlike Dropbox, when working with Git when data is changed on another user’s machine it isn’t automatically uploaded to yours (or the server). Instead, to get the latest version of your software’s code and content, you have to do something called “pulling”.
To confuse you slightly further, on GitHub Desktop this is called “fetch” and Perforce calls it “get latest”. If it’s one thing I can almost guarantee you – every source control solution does very similar things but they all call them different names. Welcome to development!
The first thing you’ll need to know when you start working in game development is simply how to get the most up-to-date content. To do that, you’ll need to “pull” it from the depot. Once you’ve done that – you can both play build you’re working on, and change it yourself!
That leads us to the next question – what do you need to do when you’ve made a sound and you want to upload it?
“Committing” and “Pushing” is the act of saving and uploading your changes from your local computer to the remote repository.
Git is probably the most funky and unique when it comes to the terminology of adding your changes to the remote server, as it’s a two-step process. Creating a “commit” saves a “changelist” to your local computer. It’s like telling your machine “yes, I’m happy with all these changes, please save this moment in history so I can come back to it if I need”
Once you’ve created a local “commit”, you can then “push” that commit to the remote server. This takes that local save point and uploads it – making it available to “pull”, like you just learned.
Most source control solutions at AAA game companies (I’m looking at you, Perforce) actually combine these two actions into one act called “submit”. With Perforce, for example, any changes you make locally are automatically tracked and you simply hit “submit” when you’re ready to upload the changes.
You might be asking yourself what happens when two people have submitted the same file with different changes, or if you need to compare an older version of a file with a newer one to see what changed. Let’s take a look at that…
A “diff” is the act of comparing two different versions of the same file to compare their differences.
Everything else thus far has been pretty stock-standard source control usage that you’d have to learn with any company wanting you to use it. Here, at least for audio content creators, is where we get into some new territory.
“Diff”ing comes up quite often with text files – as sometimes you’ll need to remember what changes you made 3+ versions back of a file. You’ll also hear it come up when people are working on the same file on two different machines and the changes need to be “merged”.
Thankfully, for your job, you’re half off-the-hook for learning to “diff” – you mostly get the easy part, because binary files (ie: all of your sound files) cannot be “diff”ed. Instead, the primary time you’ll ever “diff” files is when comparing text files generated by your middleware. Wwise “.wwu” work units, for example, are simply XML text files.
This is where you’ll also truly earn your “superhero” status with the team. Being able to compare Wwise XML text to solve difficult-to-find bugs is something that the vast majority of audio people can’t do. This is actually something that would take you 5-10 minutes to learn just by reading a simple XML tutorial and opening up a .wwu file on your computer!
“But Adam!” you say, “Do I really have to learn this stuff? Can’t I just use Dropbox to share assets?”
If you’re going to work for a AAA company, you 100% need to know how source control works. The easiest (and only free) one to learn at home by yourself is Git. While all of this pulling, committing, and pushing stuff may seem totally unnecessary if you haven’t ever done it before – it is!
To clarify the difference between source control and Dropbox – ask yourself if you’d be happy with your client hearing every unfinished audio file you saved, live in the game, before it was done. With an automatic backup system, that’s exactly what would happen. But with source control, you can make local changes all you want and choose when you’re ready for everyone to get your changes.
On top of that, all the version history from the beginning of time itself is backed up. Therefore, if you make any mistakes, it’s all 100% reversable – awesome, right?!
So what were those three commands again?
Just remember these three words:
- Pull
- Commit/Push
- Diff
If Peter Parker were a sound designer, he’d definitely know Git.
I know this to be true, because Peter excelled both in his studies and his superpowers. You can do the same and skip ahead of a ton of your job competition just by learning and applying these concepts. I promise, just having “pull”, “commit”, and “diff” come out of your mouth in complete sentences is enough to shock some people.
If you don’t believe me…
Try this out and learn hands-on.
You only need 30 minutes of free time, just jump into this YouTube tutorial by Kevin Powell. He’ll walk you through the basics of GitHub account creation, downloading, and using GitHub Desktop. The video is a few years old, so the Github Desktop interface is slightly different, and he’s speaking to web developers – but the concepts all still apply today.
Feel free to make a “burner” GitHub account too if you never plan on coding again in your life. Just remember, around 30 minutes of your life and you’ll have skills that a lot of audio professionals don’t have or aren’t good with!
Copyright 2016-2021, NIR LLC, all rights reserved.