Release Management with GitFlow — Part II

You can get the basic idea of the GitFlow workflow from my first part of this article series. Check it out from here.

Release Management with GitFlow — Part I

In this part, I will explain the core ideas of this workflow.

Let’s go ahead.

Gitflow takes advantage of an essential feature of Git, which is the power of branches. In this model, a git repository has two main branches:

The main branches

The central repository holds two main branches with an unlimited lifetime.

1. master
2. develop

The master branch at origin should be familiar to every git user. Parallel to this master branch, another branch exists called develop.

We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.

We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Also, this branch is called the “Integration branch” by some people.

When the source code in the develop branch reaches a stable point and is ready to be released, all of the changes should be merged back into master somehow and then tagged with a release number.

Therefore, each time when changes are merged back into master, this is a new production release by definition. We tend to be very strict at this so that theoretically, we could use a Git hook script to automatically build and roll-out our software to our production servers every time there was a commit on master.

Apart from those two primary branches, there are other branches in the workflow:

Supporting branches

Next to the main branches master and develop, this development model uses a variety of supporting branches for the ease of development. Unlike the main branches, these branches always have a limited lifetime, since they will be removed eventually.

There are different types of branches we may use,

1. feature branch
2. release branch
3. hotfix branch

Each of these branches has a specific purpose and is tied to strict rules as to which branches may be their originating branch and which branches must be their merge targets.

feature branches

may branch off from develop and must merge back into develop

Naming convention: release-*, hotfix-*

feature branches are used to develop new features for the upcoming or a distant future release. When commencing the development of a feature, the target release in which this feature will be incorporated may well be unknown at that point. The essence of a feature branch is that it exists as long as the feature is in development, but will finally be merged back into develop (to add the new feature to the upcoming release definitely) or discarded (in case of a failing experiment).

feature branches typically exist in developer repositories only, not in origin.

release branches

may branch off from develop and must merge back into develop and master

Naming convention: release-*

release branches support the preparation of a new production release. They allow for minor bug fixes and preparing meta-data for a release (version number, build dates, etc.). By doing all of this work on a release branch, the develop branch is cleared to receive features for the next big release.

Hotfix branches

May branch off from master and must merge back into develop and master.

Naming convention: hotfix-*

hotfix branches are very much like release branches in that they are also meant to plan for a new production release, also it unplanned. They arise from the necessity to act immediately upon an undesired state of a live production version. When a critical bug in a production version must be resolved quickly, a hotfix branch may be branched off from the corresponding tag on the master branch that marks the production version.

The essence is that the work of team members (on the develop branch) can continue, while another person is preparing a quick production fix.

You can see the end-to-end workflow chart of GitFlow below.

Author: Vincent Driessen, License: Creative Commons BY-SA

So I will wrap up the article from here. I hope now you guys got to know about the basic and core idea of the Gitflow.

In the next article, we will look at a hands-on example(demo) on all of those things.

Release Management with GitFlow — Part III