I will here drop some thoughts and design recommendations that you should consider when migrating from a formerly used VCS (Version Control System) to a newer one. As I am a fan of the usage of workflow concepts, the periodic workflow scheme will be focused in this article.

Version control systems

A Version Control System (VCS) is a concept which is used to organize and manage arbitrary kinds of data like documents, images, source code and even binary data. As a code developer, you can of course host and manage your own source code like you want; you are just responsible for your own. But when working together with others, some kind of collaboration must be used.

In a VCS your data can be versioned, which means it can be reset to a recent state at a certain moment (often called snapshot). You can even have a look at who added, modified or deleted a file and why (by watching the attached message hints).

In the past (and still used), the following concepts were the most popular centralized ones:

• OpenCVS, OpenSource
• Subversion (SVN), Apache Foundation, OpenSource
• Visual Source Safe (VSS), Microsoft
• TeamCity, JetBrains

Another approach is the decentralized structure. In this area, the following concepts gained popularity (all openSource):

• Bazaar, Canonical
• Mercurial (recently BitKeeper), Matt Mackall
• git, Linus Torvalds

Of course there is a bunch of other software, where each of the projects has its own advantages. This short list above is just meant to give a short overview over some of the most common ones.

As stated above, in 2001, the well-known IT hero Linus Torvalds invented a different concept of version controling, called git [2]. The wording means more or less a fool, which is explained by him as follows:

At my current work, I was asked to evaluate a new version control concept, which must be designed and installed in order to fit the needs of our team. Having the mentioned opportunities of version controlling in mind, I decided to have a deeper look at git, as it is the most common VCS in the IT landscape and offers a nice integration in most of the IDEs. It has a large community and is known to be very stable. So here we go - another facts about git:

• Developed in 2005, almost monthly releases
• Decentralized structure
• Non-linear development using a branch concept
• Cryptographic authentication of history (commit hashes)
• Lots of GUI clients, IDE interfaces, etc.

Let me show you, which aspects I considered during my evaluation of how to organize our team with git.

git basics

At first, some wordings have to be introduced and explained. I focus on the most common commands and workflows that are useful for the daily work with source code.

Fetch: Get the latest changes from your origin to see, what other participants have done since your last fetch.

Merge: When you merge from another branch and this branch is ahead of your currently checked-out branch, the remote changes will be merged into your branch, mostly resulting in a new merge commit.

Pull: Is a combination of Fetch + Merge. It can be used to save one click, if you are going to merge the latest changes from the remote anyway.

Push: Writes the changes that you applied locally (Your commits) to the origin (like your provider, for instance github.com). Once a commit is pushed to its origin, it is backed-up and can be seen by other contributors of the repository.

More commands can be investigated in depth by reading these articles @atlassian.

Workflow strategies

After working for some time with git in different teams, I got in touch with some of the most common concepts:

• Linear, centralized concept (1 master branch)
• Gitflow Workflow
• Forking Workflow
• Periodic Releases (Feature Branch Workflow)

At my current work, I was asked to develop a version control concept. Therefore, I decided to introduce the Feature Branch Workflow in our company. In my eyes, this is the most effective strategy when you are working together with some (at least 4) other developers.

Which aspects did I consider when finding a decision?

• Do we have periodic releases? Yes, every 2-3 months
• Do we work on different features in parallel? Yes
• Do we have customers having different versions installed? Yes, hotfixes can be necessary at some point

If your team includes less then 4 members, it is probably a good idea to use one of the other mentioned workflow concepts. You will for sure save time and organizational effort when doing this, as the Feature Branch Workflow must be understood from every user in order to succeed.

The Feature Branch Workflow in detail

The above diagram explains, how periodical releases can be realized by using the obligatoric master and develop branch. In addition, there can be on top hotfix, bugfix, feature and release branches as well.

1. master: This branch contains always a stable version of the application. It contains exactly the version of the software that is rolled-out at your customers.
2. develop: This branch contains the current development status of the source code, independent of any release.
3. hotfix: A branch of this type is created based on the master, when there is a need to provide an urgent fix for certain customers, separated from the common release cycle. It must not contain any code that is planned to be part of the upcoming release, hence it has to be based on the latest release on the master branch. It is important to think at this purpose when starting to code on a hotfix issue.
4. feature: When a new feature is planned to be part of your software, all coding effort according to this feature must be committed onto this branch. It can exist in parallel to the develop branch, but should be synchronized frequently in order to prevent the branches from diverging.
5. bugfix: Fixes on the code that are not that urgent and can wait for the next planned release to be rolled-out, are best-placed on a bugfix branch. It can perfectly be managed together with a project management tool, e.g. to trace the reported bug and the referencing source code by using a common identifier. The bugfix branch is missing in the diagram above, but can be imagined to be identical to a feature branch (They should be synchronized with the develop branch as well).

Assuming that all collaborators of your team have understood the Feature Branch Concept, they must merge their changes from their topic-specific branches to the parent branch (mainly the develop branch) in any way. Because of this, some of the available hosting providers are offering the feature of pull requests which I recommend to make use of.

Pull requests as an option for code reviews

The concept of pull requests is pretty new in the area of git, but provides a huge improvement when working together in a medium-sized team.

Pull requests let you tell others about changes you've pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch [1].

Each time a branch is ready to be merged into the develop branch (or also into the master branch, in case of a hotfix branch), it should be done by using a pull request instead of merging it directly. This provides the option to review all changes on the code that were affected by any commits of this branch. Just when the reviewer can't found any open issues on the code, the request is accepted and the branch gets merged.

Summary

In a very short manner, I tried to introduce the purpose of Version Control Systems (VCS), the strenghts of git and hence the Feature Branch Workflow.

If you'd want to know, how this workflow behaves in real life and if there are some common pitfalls, feel free to ask me.

Online tutorials

• Atassian: https://de.atlassian.com/git/tutorials/what-is-version-control
• Nvie.com: https://nvie.com/posts/a-successful-git-branching-model
• Atlassian Hooks: https://de.atlassian.com/git/tutorials/git-hooks

Literature

• Git Basics and Workflows: git @ google books