GitFlow ~ It’s not that hard

Git has been everywhere, serving about 27 million users worldwide, including Facebook, Microsoft, Amazon, LinkedIn, Apple; it has become the most widely used Version Control System. But more often than not we find ourselves more committed to blunders than to code, and sooner to this comes a realization that Git is hard and screwing up is easy. Finding ourselves tangled in the web of branches.

This is generally due to failing to properly understand the architecture of git or worse, not following an architecture at all. As the team of developers working on the same project increases, the complexity of branching increases making it difficult and often confusing to interpret what’s exactly happening.

In this blog, we will be sharing the architecture we use, here at CodeNicely. We don’t work with a large team, but projects go through the hands of many developers and without proper architecture, maintaining a record of changes would be almost impossible.

We use the GitFlow model designed and published by Vincent Driessen at nvie, which has turned out to be very successful for release management. It offers you with:

• Parallel development between team members
• Ease tracking of features
• Prepare for production releases
• To assist in quickly fixing live production problems.

What we will be doing here is to present a simple and quick explanation of the branching strategy, making it easier to understand. It will provide a set of guidelines for developers to follow while using a Version Control System, you are free to change it as per your need. Command-line integration is also available for this model. Wasting no time, let’s get started.
The model isn’t as complex as it appears to be on the first go.

MAJOR BRANCHES

Instead of using a single major branch we have two major branches, which are: master and develop

• We consider masterbeing the prime branch which reflects the production-ready state. It is basically a record of official release history.
• We consider developbeing the main branch which has the latest development code. It is an integration branch used by the developers of the team.

SUPPORTING BRANCHES

Apart from the main branches, we have a variety of supporting branches. These branches always have a limited lifespan and will be removed eventually. The subsidiary branches we use are:

• Feature branches
• Release branches
• Hotfix branches

Basically, they are just simple plain branches, with no technical specialty. The branch type will define how will we be using them. These branches have a specific purpose and have some rules regarding from where will they branch off and to which branch they will merge.

Feature Branch:

Branch off and merge back to the develop branch

The name speaks for itself, a feature branch is for adding a new feature to the project. The soul of the feature branch exists only as long as the feature is in development state, i.e eventually it will be merged back to the develop branch.

Say a developer Domesh, wants to start working on a new feature.

• He will pull the latest copy of the develop branch, work on a feature, commit his changes to the newly created feature branch.
• Once the feature is ready, he will merge it back to the develop branch.
• During this course of time, another developer may merge his feature branch to the develop as well.

The naming convention of this branch is generally feature/*.

Release Branch:

Branch off from the develop and then merge back to develop and master.

A release branch is initiated when the develop branch reflects the next new release i.e. production roll out. This branch comprises of minor bug fixes and the final touch up of the feature. Testers will test from this branch and any bugs can be reported here. Keep in mind that no major change or feature is added in this branch.

It is in the release branch that the upcoming release gets a new version number. A release branch is merged to both develop branch and the master branch. Adding a tag while merging to the master branch is preferred so that one can keep a track of all the major releases.

The naming convention of this branch is generally release-1.2/* , where 1.2 is the new version number.

Hotfix Branch:

Branch off from the master and then merge back to develop and master.

Hotfix branch is pretty much like the release branch, it is generally short-lived. A hotfix branch is created when you encounter a bug or an undesirable behavior in the production, in a situation which needs immediate action. Like release, hotfix is also merged in both master and develop. A hotfix can be tagged with 1.2.1 (one increased partition).

There might arise a situation where one needs to create a hotfix when the release is already initiated. In such a condition the hotfix will be merged into the release branch instead of the develop branch. Eventually, the result of the hotfix will be merged to the develop branch as well.

‘Branching model’ can work like a well-oiled machine for version control system management. It not only offers dedicated channels for hotfixes to production but also great release-based software workflow.

One more thing

Check out our website, Codenicely.in and like us on facebook to stay connected. Also, clapping lets us know that you have enjoyed reading this post and we always appreciate your comments. Lastly, GitFlow ~ It’s not that hard! Stay tuned in, there’s more to come.