Choosing a version control system: git vs SVN, part 1

Have you ever been in a situation where you feel that your product reached a pretty solid and stable stage? Everything ran smoothly just fine. You were the happiest person in the world.

Good feelings died young. You suddenly realized that “Oh, this could be better if I tweak the behavior of a spider a little bit more. Attacking the player is too violent, it should scare his ass off only.”

Wasting no time, you started to implement it. You were a careful person, you didn’t want your product being messed up. You decided to copy your whole project into another place, so that you can enjoy tweaking while being sure that you still safely had a stable version elsewhere in your computer.

Days after days, cool and interesting ideas kept coming. Many of them had failed, but also many of them truly brought something unique to your game. With each idea, you followed the same approach above to store the stable state of the project. Now your folder which storing ‘stable’ versions contained:

Not so pretty, huh? I know, I used that kind of safe versions before. This method seems to be helpful at first, but when the project grows, it has many disadvantages:

  • Bulky “safe” folder takes up a shit load of disk space.
  • Easily lose tracks between versions.
  • Lack of flexibilty.
  • Full of redundant dupplicated files.

Version Control 101

Luckily, our problem has been solved long ago, with a thing called Version Control System, or VCS. Basically, this kind of systems helps you to log your development process, with the changes throughout the process are described cleanly. Which lines of which files did you change, remove or add? For what purpose did you make it?

The ability of tracking development process also helps you to jump back into any time of the project in the past. All these nice features turn VCS into a must-have tool for every software development project, including games.

A few useful terms for beginners

To get started with a VCS tool, there are a few jargons which are worth mentioning first:

I’m sorry if there are so many glossaries. I did my best to use simple words and keep the explanation interesting
  • Repository: the storage of all versioned files in your project.
  • Working copy: the copy of the file/folder/project that you are actually working on.
  • Versioned: a versioned file is a file that is under observation of the VCS. The VCS will immediately recognize changes in versioned files.
  • Unversioned: an unversioned file is a file that the VCS is not yet aware of. You can turn it into a versioned file or ignored file.
  • Ignored: the VCS knows that it should not spend its efforts to watch those files. Usually generated files are ignored.
  • Local and Remote: most VCSes available are designed for team collaboration. So there will be a remote repository somewhere accessible for team members, then they can always stay tuned for their teammates’ lastest work. Their working copy will be placed in their machine, called the local copy or local repository.
  • Commit: this is the most basic command of a VCS. When you commit your changes, the VCS would take that and store into the commit history (also called the log).
  • Update/Sync: this is the act of checking and getting new changes from the remote repository into your working copy.


Another important concepts that I would love to discuss in a separate section, which is branching. Simply put, creating a new branch is make a separate “copy” of your repository using the VCS, so that you have two or more independent lines of development.

Let’s recall the scary spider example above. The idea of scary spider seems to be interesting, but in game development we can be sure of the fun of nothing before it is actually made. So you will have two branches, one for the main, stable state and other for experimenting your scary spider. When you feel good and reached a stable state of the scary spider, you can merge it back to your main branch. And now your project, in its stable state, has scary spiders.

Branching illustration

Now, as you need time to understand those concepts, I would stop this part here. I highly recommend you to find a VCS tool and play around yourself, since the purpose of this post is not explaining how to use a VCS.

In my next part, I will discuss about two VCSes that I used, their own concepts (yes, almost every VCS has their own concepts), and their weaknesses as well as their strengths, so that you can decide which fits you better on your own.


One thought on “Choosing a version control system: git vs SVN, part 1

  1. […] the previous part, I described why do you need and what on earth is a version control system (VCS). In case that you […]

Leave a Reply

Your email address will not be published. Required fields are marked *