Quick and Dirty Source Control

Jan 31, 2013

I recently received a number of questions from a reader about version control for hobby videogame projects. Responses follow.

Q: How big does a project need to be to benefit form version control?

A: In the laziest, simplest form, I think even a solo game jam can benefit from some crude form of version control (see my last answer here for exactly what I mean by that). As for “real” version control, I tend to only bother if at least 3 programmers are involved with the project, and the project is expected to take at least a few weeks or more.

Q: If I use version control, what should I use? Git, Mercurial, or something else?

A: My opinions on this are likely out of date, so I’d suggest investigating the options to see what’s being said about these newer options. For large-scale commercial development I’ve used Perforce, and for smaller independent student teams I’ve only used svn.

(Update: Michael Foord suggests, via Twitter, to check out Mercurial or Bazaar. He has provided some details in a comment below.)

Q: What client should I use? Github, BitBucket, or something else?

A: Likewise, my tastes here may be outdated, but I used TortoiseSVN when I was in Windows, and just handled svn via command-line when I was in Mac. I can say that I’ve witnessed a number of fairly experienced programmers, myself included unfortunately, bind up a bit when running into certain conflict or folder mismatch issues via command-line using svn, and a good client would also probably go a long way in simplifying that experience. Having a good file comparison tool is important to spot diffs in a conflict, and that’s often part of the client with Perforce or Tortoise, although on Mac I used a program called FileMerge which if I remember correctly was a tool application bundled with XCode.

Be aware that some online services that provide hosting servers or other niceties may come with strings attached, such as requiring that your program is open source, etc. That may sound fine, but even if you’re keen on the spirit of it, that can sometimes drag out a project needlessly by making someone overly self-conscious of how well organized and documented their code is. When code isn’t open source we can occasionally resort to hackery to get things done in special cases without getting self-conscious about it, making conscious tradeoffs to optimize our development time in that case (as opposed to, say, making tradeoffs in readability to optimize code execution time). Of course, if you’re a full-time software engineer and used to or interested in joining larger team environments, for that same reason open source might be a constructive exercise, in which case such licensing implications may not be a concern one way or the other.

Q: How often should I upload a new version?

A: I’m a proponent of trying to work on one relatively isolated, bite-sized (1-4 hours of work) feature at a time. I’ll tend to commit:

  • Each time I’ve completed and tied up a functional chunk, generally amounting to several hundred lines of code or less. This can even become a nice part of the ritual, punctuating a finished task, like scratching something off a todo list.
  • Whenever I finish solving a tricky or creative code issue, or finish a tuning/balancing pass I’m pleased with, that I’m not confident I could easily reproduce a second time.
  • Upon finishing something monotonous that I would not want to do again. This mostly happens when doing some type of hand-adjustment to assets, for example tweaking spacing offsets for every character of a medium/high resolution bitmap font, or renaming several folders of sound and image files to fit an improved naming convention.

It’s important to only check in code that’s ready to compile and run though without interrupting other features or debugger output (i.e. for log/trace statements: clean up, remove, or make toggled on/off in code that defaults to off, before committing to svn), or it’ll throw off other programmers on the project, including future you. If that code is otherwise incomplete, then for now make sure it has been safely isolated from other code still in use, flagged with a short comment at the top indicating it’s not ready for use. Be careful to not break the build, hog the debug output, or degrade performance with a half-finished check-in that will leave others wondering whether their local changes caused it.

Q: Is version control worth it if you are the only programmer on the project?

A: Here’s what I’ve been doing for the past 5 or 6 years when I’m the only programmer on the project (which is very often the case for my hobby projects, even when there’s a team of people involved with assets), it’s a habit I picked up from John Nesky:

  • Every night, when I’m at a good stopping point, I zip up the project’s folder. I save most of the old ones of this, or at least 1 per week, and it makes it easy for me to dig my way “back out” if I find that I’ve coded myself into a corner or introduced some nightmarish bug I’m having trouble undoing. Sometimes it’s also fun when I’m done with a project to look back on old zip files to see what the project was like earlier in development – what didn’t make the final cut, how much rougher it looked earlier, etc.
  • At least once a week, I copy the zipped folder to a location online, like a folder on my FTP server not visible to the outside world. A local external hard drive for back ups is handy, but not sufficient. Nowadays I just copy the zip with dated filename into a special folder that I keep on Dropbox specifically for development backup, and it’s automatically copied to the cloud. The idea of keeping a version of the full source at a remote location is that no matter whatever disaster could happen locally – backpack with my laptop in it falls into a deep puddle, catastrophic hard drive failure, my home gets broken into and my computer and backup drive both get stolen, home burns down, whatever – then at least I have something to pick back up from.

Loss would still be inconvenient, it would still be expensive, it would still be lame, but things can be replaced with money, whereas lost game development work is simply lost time, a huge loss to morale, and if there are other people on your team or a business counting on you to finish, not tending to this properly can make your/my misfortune spread to also become their misfortune. It’s way too simple to back up a project remotely to have any excuse to ever completely lose a project’s code and source/raw/PSD art files.

It’s not your fault if something goes wrong and a hard drive utterly fails, but it is your fault if that happens and you’ve not taken any steps to mitigate that loss.

If a project is tiny enough and you’re at a game jam, and don’t want to set up a Dropbox (but you really should, it’s free and easy to do), at least e-mail yourself a zipped copy of the source every so often. If you don’t have internet access for some reason, occasionally copy that latest zip to a USB stick so it’s not all one the same physical point of potential failure.

It’s not either-or, though. There’s a continuum of source control between having the technical infrastructure of a massive studio, which needs a fully staffed IT department to keep it running, compared to the resources of a hobbyist or student trying to moonlight. While it’s important to not become bogged down with sorting through non-game technical troubles, it would be reckless to have all of the work invested into a project living only in a single directory having one version on one machine. That’s terrifying. At the very least, make a new zip of the directory after a good night’s work on it, and occasionally toss a dated version of that file onto a server in a remote location. If the project is so large, distributed, or complicated that using that method isn’t practical, then it’s time to look into setting up some real source control, whether svn, git, or one of the other solutions out there.

Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.

Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!


  1. voidspace says:

    Once you get used to setting up a new version control repository (whatever version control you settle on as your favourite) it becomes very easy to setup a new one.

    Once it’s easy, even if the project is small and you’re the only developer, the advantages of using version control outweigh the minor cost of setting up a new repo.

    The advantages include:

    * The code is no longer on one machine – a version control repo is a backup
    * Moving development to another machine is easy – just check out the repo
    * Revert unwise changes easily – just revert to a previous revision
    * Branching and merging are typically easy – experiment with changes in a new branch and merge to mainline if it works out
    * Small projects don’t always start out small – adding new developers is easier if you already have a repo. Even with two developers version control makes collaboration much easier.

  2. Jonny D says:

    Being bitten by poor backups is awful. I suggest that you always use version control for small projects, even if you’re the only developer. I often don’t use it for quick one-off test programs, but always for game jams. Assembla.com is doing a good job for my free, private, web-based Subversion needs.

    For me, it is way easier to use one big repository for a bunch of small projects than to obsessively zip up and transmit a project and whatever huge binary executables or object files are in it. Proper use of SVN ignore, export, and tagging will keep your source and binaries separate and clean. Just to be extra safe, I periodically (every few months) save a local SVN dump.

    I even store headers and binaries for each platform of the various libraries I use (externals) in my repo. That way, I never need to install libraries when I set up a new computer/OS.

    Going back in time with version control is simple and you should make tags if you have a nice version that you don’t want to recompile.

  3. Jarin Udom says:

    Yeah, I always always always use version control, even if it’s just a one-page website and I’m the only one working on it.

    It’s so much easier to type `git diff` and see what you’ve changed than to stop what you’re doing and try to remember it. Also, simply taking 3 seconds to type `git add .; git commit -m “Changed X”` any time you change something can save you hours and hours of time later.

    You never know when that little tiny one-off toy project might turn into something bigger or you’ll need to grab some code from 3 revisions ago for some other project, and the negligible amount of time it takes to `git init .` a project folder is well worth the benefits.

  4. Personally I use source control even for tiny single-file projects. (let me check… the largest programming project I have ever created in the last decade or two that didn’t use source code control is… 41 lines.)

    Once you know what you’re doing, setting up a new repo is a five second operation. If you’re a game developer, you’re also a developer, and you owe it to yourself to learn your tools. Getting by with zipfiles and backups is like using a familiar pixel editor when you ought to be learning a new tool to edit vector art – destructive and tiresome and error prone.

    Git has the greatest mindshare these days. It’s tremendously powerful (it’s the tool I use most) but also is needlessly complicated to understand (I once produced a parody explanation of it http://tartley.com/?p=1267) If you do choose Git, and want a GUI tool, then I prefer ‘gitx’, which is open source and cross-platform.

    Mercurial and Bazaar are pretty much just as capable as Git, but are marginally easier to understand. For historical reasons they aren’t as popular as Git.

    Svn is older, and has fewer features due to not being ‘distributed’, as all the others are. But it’s by far the easiest to understand, and still works just fine, especially for single developers.

  5. I said ‘gitx’ is cross-platform: I was wrong, it’s OSX only.

Leave a comment

Comments Form
  • Your email will not be used for any purpose other than to update you in replies to your comments. Your website address will be shown as a link from your name with your comment. Your profile photo is auto-magically provided by Gravatar.

All contents Copyright ©2017 Chris DeLeon.

Site production by Ryan Burrell.