What follows is a raw, completely unedited (sorry) excerpt from the next book I’m in the process of writing (you can preorder it here). In it, I cover some of the basic ideas behind source control for the layman.
If you’re looking to break into audio for games, knowing how to use and utilize source control can put you at an advantage against peers who don’t. It’s one less thing a studio will have to teach you the concepts of (even though you’ll have to learn their version) on the job.
If you’re looking to break into the audio-side of the games industry, I’m writing this book for you. So if you’re overwhelmed by information on the internet, don’t know what to focus on, read too many threads on Reddit and Twitter, can’t focus, are stuck in a catch-22 where you need experience to get hired but can’t get it without being hired, or super depressed and never think you’ll get a shot… This one’s for you. I’m bringing my industry pals in to voice their opinions (that may not agree with me) too. Again – preorder here.
Hope you enjoy the content.
What is Source Control?
If you’ve never even heard of it before, source control (or “version control” is another name) is largely used in the software development world as a way to manage project development among teams of people. You see various core concepts of source control employed in a “live” context in applications like Dropbox (shared file storage on a server & local machine), and Google Docs (collaborative editing). But if you’ve never used the real thing before, there are enough differences where those analogies break down fairly quickly.
In its most basic form and concept, source control is simply used as a “cloud” storage mechanism very similar to Dropbox. You have a local copy of your work on your computer, and when you make any changes (add/delete/edit), source control automatically detects these and lets you upload a new version of your work when you’re ready to do so. If you’re collaborating with other individuals, they can upload their work and download your work too. The magic starts to happen when you’re both working on the same document or file – source control can detect conflicting changes and help you parse/merge the differences. You can also roll back to old versions of your work, as source control keeps a permanent history of everything done on the project. There are additional features like branching – which allows various things such as to maintain “stable” public versions of your work, or for you to work on sub-disciplines separate from one another.
Within games you’ll quickly hear of a software called Perforce (also known as P4) used for version control. There’s also Git and Team Foundation Server (TFS, created by Microsoft) among others
How to Learn at Home
If you don’t already have a team to work with, the easiest free software to use in order to learn version control by yourself would be Git. Specifically, you should sign up for GitHub (https://github.com) and download GitHub Desktop. I’ll walk you through this, and creating a simple project, in just a second.
First though, if you’re unfamiliar, the terminology around Git can be incredibly confusing. Let’s take a look at it together, and I’ll break it down into something that’s hopefully easier to understand.
Git itself is source control software. If you were to just go download a copy of Git by itself, you would be downloading a program that runs entirely by the command line. There is no out of the box GUI for Git.
While Git by itself can do all of the things that any version with a server or GUI can do, it’s way less user friendly to use if you don’t know what you’re doing (and at this point, you likely don’t).
So all that you truly need to know and concern yourself with is that Git itself is the core tech behind all sorts of the source control services I’m about to tell you about.
GitHub (https://github.com/) is a free (for public use) online service that allows you to create and host “repositories” (projects) on their servers.
You can think of it much like Dropbox in that you create a GitHub account, and using any one of numerous Git-based applications, you can use their servers as your “cloud storage”. Another similar-but-not-quite analogy is if you think of GitHub as your web host, and Git as FTP on steroids. Again, neither of these descriptions is perfect, but hopefully it helps you wrap your mind around the concept a bit.
GitHub is at this point, likely the largest and most publicly recognizable face of Git as a “brand”. When most people think of using Git, it’s fairly synonymous with GitHub in general. There are other options online which provide a similar service (I’ll get to those shortly), but GitHub is far and away the easiest to get started with.
GitHub Desktop is a desktop application developed by GitHub to be used as an easy to understand GUI for Git. It isn’t nearly as “powerful” (meaning, you can’t use every esoteric command with it) as some other desktop Git applications, but it is by far the easiest for you to pick up and just start using to successfully understand the concepts of Git in general.
GitHub Desktop works directly with GitHub (the web service) in order for you to easily create and work with repositories on your computer. It takes away the vast majority of the Git learning curve and is a great place to start your first project. Luckily, it’s also available on both Windows & Mac platforms!
Git vs GitHub vs GitHub Desktop
At this point you may still be confused with the terminology. With the word “Git” being used 3 times for 3 different things – I can’t blame you. Here’s a quick reminder:
- Git is the source control system itself. It runs locally, via the command line if you don’t have a GUI for it. It will only handle projects on your local computer unless you have a web server to store projects on.
- GitHub is a web server/service that you can use for free so long as your projects are publicly view-able. It’s designed to be used with the Git source control system.
- GitHub Desktop is a desktop application designed to be a GUI for the Git source control system. It can only work with GitHub, and is targeted to newcomers due to its extremely small learning curve.
Services Beyond GitHub
If all the previous terminology wasn’t confusing enough, I’m going to throw some other things at you that are entirely beyond the scope of what you need to learn. I think it’s fun to know what else is out there, and if you’re interested you can always take a look at these extra things. Perhaps they’ll help you understand the concept of Git/source control better.
Similar to GitHub, Bitbucket (https://bitbucket.org/) and GitLab (https://gitlab.com/) are online web services that host Git-based projects. Where they differ lies a bit in workflow and usage, but primarily by pricing scheme.
Where GitHub is focused on providing users unlimited free public (meaning anyone can see your code) repositories and charging for more than 1 private repository – Bitbucket charges by number of users on a project, allowing for unlimited private repositories. This is a bit of an advantage, obviously, for a solo or extremely small team who wants to build a business and keep their work private. GitLab on the other hand, provides unlimited private repositories and users, but charges for advanced workflow features and support.
Like GitHub, the parent company of Bitbucket has their own desktop application for Git called SourceTree. Unlike GitHub Desktop, SourceTree can be used with any Git-based web service (like GitHub or GitLab).
There are also service-independent Git-based desktop applications such as GitKraken. Much like the differences in web services, each desktop application comes with it’s own unique, appearance, workflow, and features set. As I said before, not all Git commands are available on every desktop application.
Introducing the terminology
If you’ve gotten here, first off, great job – you are in the vast minority of audio professionals globally who even know how to do that. This is stuff largely left to programmers.
However, I’ve likely left you a little confused as to what you’re doing and what some terms mean. I want to clear that up before we add a file to your project, so you’ll know what the hell you’re doing before you actually do it. Therefore below I’ve made a list of some important words, and what they mean in layman’s terms. Keep in mind that Git has some language not exactly shared across other source control solutions – but for the most part if you understand Git’s terminology, you can make the connections what things mean in other source control programs.
A repository is essentially another name for a project. It’s not analogous, as a repository can actually hold multiple projects (as it’s simply a named storage space), but this is a pretty solid place to start. You, generally, are not going to use a repository for more than one project at a time.
Cloning is Git’s term for copying a repository, even when it’s empty. What you did to get earlier was create an empty repository via GitHub’s website, and then you cloned it (copied it) to a local folder. If you add something to the repository at this point, push it to GitHub’s servers, and then clone the repository on another computer – you’ll get new file on the 2nd computer. This acts just like if you have an existing Dropbox account with files in it, and then add Dropbox to a new computer, Dropbox will sync all of your files.
Commit/Push, in a bit we will add a simple text file to your repository. To upload it to GitHub’s servers, you’ll have to complete both a “commit” and a “push” action. Many times in other source control solutions – these are combined and called a “check in” or “push”. Simply put, creating a commit is where Git allows you to add a comment about what you’ve changed in your files and then tell Git to prepare everything to be uploaded to the GitHub server. The “push” action is simply uploading it to the server.
Pull is the opposite of push. When something is changed in your project that hasn’t occurred on your local copy, GitHub will indicate that you need to “pull” an updated copy of the project. This simply means downloading a new version of whatever files have changed. Again, you can think of Dropbox here. Where Dropbox automatically syncs when you add or change files, Git requires you to confirm at every step that you actually want to change whatever you’re working on. Other source control solutions sometimes call this “get” or “get latest”.
A change created any time you edit, add, or remove something from the repository. Git tracks each change, and you must confirm them through the commit/push process. Changes can also be reverted (or, rolled back/undone). Changes themselves are tracked via change lists. You can, for example, go back to a specific change in history by having its change list number (or usually by using a GUI).
For what you’re going to do in this book, those are really the only things you need to know. However, I’m going to introduce you to two other concepts really quickly simply to expand your knowledge and prepare you for the future, it will probably help you later.
A Merge occurs when a file has been changed by two different people, usually at the same time. When this happens (on text files only), it needs to be evaluated for what lines will be kept and what lines will be discarded. There are two caveats to this… 1) This can only occur on text files, “binary” files (which audio files are) get completely overwritten, not merged, so somebody’s work will get stomped. 2) Some source controls add functionality such as “check out” and “scratch check out” which help prevent merge/overwrite issues. Essentially if a user has a file checked out, nobody else can touch it. A “scratch” check out would mean a user can only make local changes and won’t upload them to the server.
A Branch is an idea that can quickly get complicated – but you can think of it as two separate versions of your project that are being developed simultaneously. Generally this occurs to prevent conflicts, segregate unstable/prototype features of software, and create stability for main releases. You don’t need to know how to create a branch of work with them, but simply that they exist. For example, you could have branches such as “Engine”, “Audio”, “Art”, “Physics”, and “Main Release”. Each of these branches could be worked on by their respective disciplines, and when features are complete, they will be moved to the “Main Release” branch.
If you’ve gotten something out of the content above and you’re interested in more (like being walked step-by-step through using source control) you can preorder the book now.
Regardless, I’d love to hear from you and what you’re most struggling with when trying to land your first gig – tweet me @adamtcroft
Copyright 2016-2017, Adam T. Croft, all rights reserved.