Version Control Techniques
For Rapidly Prototyping

I am a big believer in using version control no matter how small the project is. It’s especially important when you are doing any kind of rapid, agile, or iterative development. Recently I took part in Ludum Dare, which is a 48 hour game jam, and wanted to share my own personal technique for staying on top of versioning my work. While I use Git, this will work in any VC system that support branching and tagging.

Consistent Naming Convention

The most important thing to have when doing tagging and branching of a project is to keep your naming consistent. I follow a system where I use the version number followed by a suffix denoting the state of the project or future features that will be added. To start, create a new project and immediately create a tag v0.1.0-alpha for my initial import. The next thing I do is create a branch called v0.2.0-features and switch over to that branch to work. As I continue my development, I increment the tag version number of each stable build and the next branch build I am working on. Once I pass v0.5.0 I consider it to be stable and start using beta as the suffix of my tags: v0.6.0-beta. At the end, when I reach v1.0.0 I will use rc as my suffix which stands for release candidate. After this, I will only do minor increments such as v1.0.1-rc as I clean up outstanding bugs. By the time you hit release candidate you should not be adding any new features.

If I am going to build a new version of the project or continue development for a second version I will increment v.1.x up following the same convention above where anything below v1.5.0 is alpha and above is beta until I reach an rc version of v2.0.0. Here is an example of the tags from one of my projects:

Branching and Merging

It is important to note that I never work in master or trunk of the project. This should always be a safe place to do merging, tagging and branching. The code that lives in the trunk of the project should not only be stable but should also be the latest build of the project. From here I can do all my work in branches. Just like I do for my tags, I set up branches with forward looking version numbers. So if my project’s trunk is on v0.1.0-alpha I am going to create a branch called v0.2.0-features and work inside of that branch. Once I am happy with the build in the branch or I have added the features I have decided on doing for that version I merge it into the trunk of the project and tag it. I then create a new branch for the next version’s features and switch over to it so I can continue my development. Here is a picture of the branches from one of my projects.

What is great about this approach is that I can quickly iterate through builds of my project or implement a backlog and work against that. Even if you are doing a small little project you should try to organize what features you need to build and when you plan on implementing them. This shouldn’t be set in stone but enough of a guide that you don’t end up with too much scope creep. I think being this organized on smaller projects, especially during game jams or timed events, is a key to success because you also protect yourself from making mistakes. By focusing on features instead of trying to do the entire project at once you can minimize those simple mistakes that happen when you accidentally overwrite files or introduce larger bugs that can overwhelm you to the point of where you can’t figure out how to get the code stable again.

What Do You Think?

I have used this process on my own personal projects and even on client based enterprise size projects with 20+ developers. If you look through any of my github repos you can see how this has worked out for me. While this is not an earth shattering technique, I thought I would at least share it since I am OCD about version control, organizing the code in my project, and making sure I don’t make stupid mistakes which always arise when you are under the gun.

I setup a G+ thread here to share your own techniques or to give me some feedback if you try this out and like/modify it.

Subscribe To My Mailing List

Want to learn how to make a game? Not sure where to start? Even if you are a seasoned game maker there is still a lot you can learn from my free 15 page guide on how to build, release and market a game.

Simply sign up for my mailing list and also get access to great tips and advice on how to make better games. I promise to not spam your inbox!

Join Now