Release Management with GitFlow — Part III

I believe you guys have gone through my first part and second part of this article series and captured some brief idea about this model.

If not check the below links.

Release Management with GitFlow — Part I

Release Management with GitFlow — Part II

In the final part of this GitFlow article series, I would like to show a basic demo on this model.

You already know that the central repo holds two main branches called master and develop . Next to the main branches, this development model uses a variety of supporting branches. Let's go one by one.

Create a feature branch

When starting work on a new feature, branch off from the develop branch.

Switch to a new branch “myfeature1”
$  git checkout -b myfeature1 develop

Integrate a finished feature on develop

Finished features may be merged into the develop branch to clearly add them to the upcoming release:

Switch to branch "develop"
$  git checkout develop
Merge "myfeature1" into "develop"
$  git merge --no-ff myfeature1
Delete branch "myfeature1"
$  git branch -d myfeature1
$  git push origin develop

git merge with/ without — no-ff

The --no-ff flag ensures that a fast forward merge will not happen and that a new commit object will always be created. This can be helpful if you want git to maintain a history of feature branches

Check the comparison image above.

Create a release branch

Release branches are generated from the develop branch. As an example, say version 2.2.6 is the current production release, and we have a major release coming up. The state of develop is ready for the next release, and we have selected that this will become version 2.3 (rather than 2.2.7 or 3.0). So we branch off and give the release branch a name indicating the latest version number:

Switch to a new branch "release-2.3" from "develop"
$  git checkout -b release-2.3 develop
Update release version
$ nano release-notes/version.txt

Release Version = 2.3

(version bumped to 2.3)
$  git commit -a -m "Bump version number to 2.3"
1 files changed, 1 insertions(+), 1 deletions(-)

After creating a new branch and switching to it, we bump the version number. Here, version.txt is a sample text file in the working copy that indicates the latest version. (here expects some file change.) Then, the bumped version number is committed.

This new branch may exist there for a while, until the release may be rolled out definitely. During that time, bug fixes may be applied to this branch (rather than on the develop branch). Adding large new features here is strictly prohibited. They must be merged into develop, and hence, wait for the next major release.

Finish a release branch

When the new release branch is ready to be released, some actions need to be done. First, the release branch is merged into master (since every commit on master is a new release by definition). Next, that commit on master must be tagged for future reference. Finally, the changes performed on the release branch need to be merged back into develop, so that future releases also include these bug fixes.

Here are the steps in Git:

Switch to the branch "master"
$  git checkout master
Merge "release-2.3" into "master"
$  git merge --no-ff release-2.3
Add a tag reference
$  git tag -a 2.3

The release is now finished and tagged for future reference.

To keep the changes made in the release branch, we need to merge those back into develop:

Switch to the branch "develop"
$  git checkout develop
Merge "release-2.3" into "develop"
$  git merge --no-ff release-2.3

This step may have merge conflict (since we have changed the version number). If so, fix it and commit.

After all, the release branch may be removed as we don’t need it anymore:

Delete branch release-2.3
$  git branch -d release-2.3

Create a hotfix branch

Hotfix branches are created from the master branch. For example, let's say version 2.3 is the current production release running live and causing troubles due to a critical bug. But changes on develop are yet unstable. We may then branch off a hotfix branch and start fixing the problem:

Switch to a new branch "hotfix-2.3.1" from "master"
$  git checkout -b hotfix-2.3.1 master
Update release version
$  nano release-notes/version.txt

Release Version = 2.3.1

(version bumped to 2.3.1)
$  git commit -a -m "Bump version number to 2.3.1"
1 files changed, 1 insertions(+), 1 deletions(-)

Don’t forget to bump the version number after branching off!

Then, fix the bug and commit the fix. (may have one or more commits)

$  git commit -m "Fix bugs"

Finish a hotfix branch

When finished, the bugfix needs to be merged back into master, and also into develop, in order to safeguard that, the bugfix is included in the next release as well. This is completely similar to how release branches are finished.

First, update master and tag the release.

$  git checkout master
$  git merge --no-ff hotfix-2.3.1
$  git tag -a 2.3.1

Next, include the bugfix in develop, too:

$  git checkout develop
$  git merge --no-ff hotfix-2.3.1

The one exception to the rule here is that, when a release branch currently exists, the hotfix changes need to be merged into that release branch, instead of develop.

Finally, remove the temporary branch:

Delete branch hotfix-2.3.1
$  git branch -d hotfix-2.3.1

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

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

So this comes to the end of the article series on GitFlow workflow.

See you soon with another article.