If the VCS command most used is blame your company has a bad development culture.

A version control system (VCS) are used to keep track of changes to source code or any other form of digital documents. They are also known as revision control or source control system. There are two main types of version control systems, centralized and distributed. A centralized system store the VCS database in external location, often a server, so many VCS actions require the server to be queried. In a distributed system a clone of the database is stored locally so you can do most actions locally. Both have their advantages. For distributed I prefer Mercurial and for centralized Subversion. Perforce is nice for Unreal.


    • Version control is not a backup system.

    • Write commits messages for the future person that have to search the repository for your commit.

Centralized version control systems

    • Easier to understand and use.

    • Performs better with binary files.

    • Set access level on directory level.

    • Support locks where only one person can work on a file.

Distributed version control systems

    • No need to be connected to the network all the time.

    • Branch and merge easier.

    • Great for programmers that work on mostly code.


    • Repository: The database where they files current and historical data is stored. Often on a server so other can connect to it.

    • Working copy: A local copy of files from a repository, at a specific revisions.

    • Revisions:A version of the content in the repository history of changes.

    • Commit: To write the changes in your working copy to the repository.

    • Ignore: To ignore files add the name of the file to the property ignore on the directory where the file is found.

    • Tag: A name set on a revisions to make it more easy to find. Ex is to mark release versions of the game.

    • Trunk: The commits in a repository form a series of changes that is known as the trunk. Using the vcs system you can go to any part in the history and get the files in your working copy as it was at the time. If you then change something and commit it again a branch will be created.

    • Branch: A branch start at a revisions from the trunk or another branch and then you are free to change it as you like. Each branch have it's own name and you can merge content from one branch into another. It can turn into a spiderweb of branches so it's good to have some rules, known as branching strategies, on how to use them.

    • Merge: When you take the one branch and put's its content into another branch it is known as that you merge the branch with the other. Ex creating a branch called 'railgun' from the trunk of your game, work for it for a while and then merge it back into the trunk. The merge does not end the 'railgun' branch so you can keep working on it and merge it to trunk multiple times.


    • Checkout

    • Id: Used to identify a revisions in a Centralized system. Often in the form of an integer that increase with each new commit.


    • Hash: Used to identify a revisions in a distributed system.

    • Clones:

    • Pull: Get changes from another repository into yours.

    • Push: Send changes from your repository to another one.

Branching strategies