Opinion: Students, Version Control!

[Insomniac Games designer Lisa Brown presents an informative primer on version control software for students, offering a crash course, tips, and useful resources, in this #altdevblogaday-reprinted opinion piece.] Here's one for all the students out there. Since I'm still relatively fresh out of grad school (though I don't know when one starts ripening, honestly), I often have students approach me with questions about what they need to do/learn/etc. that will help them get into game development. I try as much as I can to remember the state of not-knowing I had before, which is difficult to do as what once were new insights turn into normal routine. The other day I was futzing around on the internet, trying to find if there was a way to integrate Devtrack and Perforce, when a thought hit me so hard that I nearly fell out of my chair! Version control software! Using version control software is so routine, so intuitive, and so integrated into my daily life that I forget there was ever a time in my life when I had no idea what it was. I feel like that's probably the case with most game developers who use version control every day. So it's not usually the first thing we think of when people ask us what sorts of things are helpful to know/learn for game development. So, if you've never used version control software, or perhaps don't even know what version control is at all, this article is for you. Everyone else, please feel free to comment and add other version control tips for new users that I didn't cover here. (And remember that not all version control users are programmers) What's Version Control? First up, what is this mysterious version control software of which I speak? Version control (also called source control or revision control) software manages changes to files to files over time, keeping track of the revisions of files and who made them, creating not only a backup of your files, but a complete history of the project. It can be used on single-person projects, and is used on large multi-developer projects where many people may be accessing and changing the same files. Here's a basic overview of how you work with version control. Since I'm used to working with Perforce, I will use that as the basis for my example here and throughout the article:

There's a lot of advanced stuff you can do with version control software, but at its most basic, those are the things to know. More details on Wikipedia for those who want them. Making the Transition Learning to use version control software on a day-to-day basis isn't really difficult, it just can be an awkward transition. This is mainly because you often have to unlearn some habits you may have regarding how you work on and save files. Let me travel back in time to graduate school, when I had my first experience using version control, and then the following year when I was a TA for the incoming class. We used Perforce at the ETC, and the very, very first thing we had to do as new first-year students was sync a project folder and add and submit a text file with Perforce, so they got us acquainted very early on. Here's a few common habits that I experienced as a student and saw as a TA that were awkward to break when learning to use version control:

The Usual Mistakes When getting used to working with version control, there are some common growing pains you'll probably have to go through. Here are some common mishaps that new users may experience. Forgetting To Check In - It's the end of the day and you've done lots of work on a binary file. You've saved, but you leave for the day without submitting your changes. Someone else happens to need to work on the file you have checked out, but they can't, because you have it checked out and it is locked for them. The next morning, they throw things at you for wasting their time. The Accidental Full Project Checkout - This is somewhat related to the mishap above. Sometimes you'll have to synch a big chunk of the files to your local machine. In Perforce you do this by right-clicking on a folder and choosing "Get Latest Revision" or whatever. However, it has happened from time to time that a person will right click and instead choose "Check Out." This will check out every single file in that folder. It is not unheard of for someone to accidentally check out an entire project, rendering everyone else on the project unable to work. They come and throw things at you for wasting their time. Checking In Broken Stuff - You made some changes to some code and submitted the files, without running the game first and making sure your stuff works. It turns out that your change had a mistake and it keeps the game from running. The next morning, the rest of the team synchs the latest revisions to the project, only to find that the game doesn't run because you submitted something without checking your work first. Their time wasted, they come to you, and throw things. "Well It Worked On MY Machine…" - Occasionally, something will work on your machine, but after you submit and someone synchs the files it doesn't work for them. Often this happens because you have some other sneaky file locally on your machine that wasn't submitted that is needed for the workage. I bring this up because it happened a LOT in grad school when people were first learning to use Perforce, because they weren't used to "testing a clean build," per say. Synching your project to some completely fresh machine and testing it there helps you learn about these discrepancies, which can take a little getting used to. Otherwise, you know, other people can't work, things get thrown, etc. The moral is, it's easy to accidentally prevent someone else from being able to work, resulting in projectiles being targeted at your head. It's really just another new habit to learn – when on a large team, your work is no longer your own, but affects everyone on the team. It's like a commune! Maybe. Resources So, students, if you have never used version control before, I would highly recommend getting some experience with some, be you an aspiring programmer, artist, designer, producer, or whatever. First off, using version control for your personal projects is a good idea anyway for access to automatic backup, code merging and branching. You can even start using it for your assignments, whatever your discipline is, as it's always helpful to be able to look back at revision history when something that was working yesterday is broken today. Starting to develop some of these basic habits early will help tremendously in the transition to working on large team projects that use version control software. That way you'll be able to spend more of your time doing the things you are training to do, like make games, and less time wrestling with learning version control on the job. Here are more details on how version control works. This site has some really handy visual diagrams for all you visual/spatial learners out there:

Resources to start you out:

Sites where you can host your projects if you want to use centralized version control:

Two past altdev articles related to version control:

[This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]