Version control with game development - When should I branch?

Question

I recently started using Version Control with my projects (even though I'm working alone on them). I find that it gives a nice way to keep history of the whole development process (with issue tracking) and allows me to keep backups for my projects along the way.

As I slowly discover the features and advantages of using version control, I am stuck around the idea of branching. When should I do it?

Should it be every single time I go and develop a new feature, or only once in a while when I reach a certain milestone?

Obviously, branching is pretty useless when working alone, but I'd rather pick up good habits now and get used to it.

As I was reading the book Game Coding Complete by Mike McShaffry (which is a great book by the way), I got totally lost when the author recommended keeping three branches, something along the lines of:

• Main: Main development branch where regular changes are made.
• Gold: Gold branch where the last milestone reached is kept.
• Research: Branch for testing stuff that could badly impact the Main branch (modifying important components of the game engine, etc.).

Is that how it is supposed to be? How does it really work in the world of game development with big teams of developers?

Basically: When does one usually branch (and merge) in game development?

Answer 1

Branching depends a little on VCS support for the feature (ie: whether the VCS makes it easy or difficult).

But at a minimum, you want a branch for each independently supported release of your project. That is, if you have "Game 2", and "Game 2 + Expansion" which are separate products built from the same codebase, and which you need to be able to patch and issue updates to, then you want to have each of these exist in their own branch off of the main codebase, so that fixes to the core codebase can be merged into each of these products independently. (Typically, these branches are created when each product is released, or perhaps a few days/weeks before, if you have people working on things in the codebase which you don't wish to go out with the initial release)

When working with a VCS which makes the use of branches tricky or painful (SourceSafe, svn, etc), then you'll probably be happiest maintaining a "release" branch for each released product, and doing your main development in "trunk", merging changes from "trunk" into the "release" branches if and when you need to release hotfixes for those releases.

If, on the other hand, you're working with one of the newer VCS systems which are built around branching and merging (git, Bazaar, Mercurial, etc), then you'll probably be happiest doing your development in a lot of short-lived "feature" branches. For example, if you're working on AI pathfinding, you can make a "pathfinding" branch and implement the code in there. When you finish, you merge that branch back into your main trunk of development, and (optionally) delete the branch you were working in. The benefit of this approach is that it lets you work on multiple tasks simultaneously, instead of needing to complete one task before starting on the next.

In my current home project (using git), I have five different feature branches active right now, working on various different features. Two of them are alternate approaches to doing the same thing (for profiling), two are experimental game mechanic ideas, and one is a big refactor of my AI systems, and is actually broken in such a way that the code won't compile right now. But it's committed in its feature branch for reference and for backup, and it being broken doesn't stop me from working on the other features; Those other feature branches (and the main development trunk as well) still compile and run correctly.

In my experience of big-team professional game development, we're still mostly stuck with older (and commercially supported) version control systems. Perforce is probably the most commonly used, followed by Subversion. Everywhere I've worked, we've had a 'trunk' branch, and then a separate 'release' branch for every deliverable (milestone/demo/release/etc). Occasionally someone will make a personal branch for some huge change they're making or testing, but this is extremely rare, and is usually for things like "converting the game to run with this different physics library" which may not actually go through to the released product.

Answer 2

Already an excellent answer above but one thing to to note is when you want to branch and when you want to tag.

Most vcs will allow you to tag (sometimes they call it labeling). You should apply a tag every time you make a major build (either for a playtest, or a beta test, or for a feature going in). If you are using some kind of Continuous Integration (and you should) then the CI system should tag successful builds. Basically any time you do something that you might want to go back to (either to create a branch or to check back how you did something in that version) make a tag/label. They are usually low cost and simple to add.

The other thing I would very strongly advise is to keep your assets and code in the same versioning system. Having a branch (or tag) of code is completely useless if you cant match up (and then branch) the assets. This is one of the main reasons game companies love Perforce - it is equally happy storing binary art files as it is storing code, and (unlike git) it is understandable to non-technical types!

Oh and any time you feel like you want to check compiled files into your VCS stop and think about how you can avoid doing so. In my experience it almost always leads to mismatched data, missing source (where for instance a compressed DDS texture gets checked in but not the source png), and chaos down the line. If you have an asset pipeline that is better served by exported files being cached somewhere (so everyone is not re-generating the same set of files) by all means have a process building the source assets in your VCS and placing the exported files into a cache (or shared drive, or even a separate VCS). But don't check those exported files in by hand - it will bite you (especially if you are working in as part of a team).

Answer 3

I loved that book, and I recommend it to everyone with relevant interests. For one man indie projects, there's no real need to branch at all unless you need or want to create separate versions; like one for Android and one for PC, or something along those lines.

As you said, if you want to pick up good habits, I would go with Mike's approach. It makes a lot of sense and its the approach I use in my two man indie projects.

Answer 4

Anything you need to be able to go back and do more work on, should be branchable (but not necessarily branched... yet).

The reason for this is simple. You need to be able to issue a fixed version of that code, not any other code, so at that time you need to work on a branch.

VCS'es are different. Some - like git - is very easy to branch from any commit at any later time, others - like CVS - is very cumbersome to work with later.

Perhaps you want to open a question on stackoverflow, asking how to work the best with the version control system you've chosen? If you have not really started yet with a lot of history, you may want to open a question describing the way you work and ask for a recommendation of the best version control system for you?