Development workflow using git.

As most of you know I am a big fan of git. I use it for all my programming as well as the kernel compilation. This article is aimed at explaining how to use git as a workflow for development.
The model was first introduced by nvie in a blog post called A successful Git branching model

What is this git enabled developer workflow?

It’s actually nothing new, it’s a way of organizing your development workflow using branches, consisting of two core branches and several supporting branches.

Core Branches

The core of the workflow exists of two branches.

  • master
  • develop

The master branch is the branch where HEAD reflects the production-ready state of your software and HEAD of the develop branch reflects a state with the latest development changes for the next release, you could see this branch as a release candidate branch, but the version numbering of your software doesn’t reflect a new version.

Supporting Branches

To help stream line the workflow, several supporting branches will be used.

  • Feature Branches
  • Release Branches
  • Hotfix Branches

These branches are usually temporary branches and can be seen as the branches where you actually do the coding. I will explain them a bit more but already I can tell you, I sometimes code on the develop branch as well, if and only if it is a very small task in the development branch. Never ever will I code in the master branch.

Each branch is created from either the develop branch or the master branch, and after the work has been completed they will be merged back.

Feature Branch

Branched from: develop
Merged back to: develop

The feature branch is used, well, to develop new features or improve existing features of your software. When the development and testing is finished the changes will be merged back into the develop branch.

Release Branch

Branched from: develop
Merged back to: master and develop.

When you are ready to release a new version of your software, you would create a release branch. On the release branch you should bump the version of your software and you could make some last minute changes, like typo, missing changelog entries. I will never change code on the release branch, should something come up that requires code changes while I have the release branch active, I will dump the release branch, make the code changes on the develop branch and create a release branch again.

When the release branch is merged into the master branch we tag it with the new version.

Even though I stated the release branch is merged back into the develop, technically we are merging the master into the develop. We are merging the tag commit into develop.

Hotfix branch

Branched from: master
Merged back to: master and optionally develop.

When we are developing on the develop branch and a serious bug is reported in the production release that need immediate fixing, we will be creating a hotfix branch.
On the hotfix branch we will fix the bug, bump the version, and merge the hot fix back in to the master branch. Again we will tag the master branch with the new version.
Depending on whether or not the fix applies to the current development, we will merge the fix back into the develop branch.

Tools to support the workflow

If you want to use this workflow, and in all honesty why wouldn’t you, you can use a set of shell scripts to streamline the workflow.
I have forked the original set of scripts, called git flow, and implemented several features that were requested. You can find git flow in my gitflow repository on github

I will write some articles on how to use git flow in the near future.

This article is filed under the category Development and has the following tag associated with it: .
  • Dan

    Hi Peter,

    It’s nice to see someone promoting and continuing work on git-flow. I see you have been making a ton of changes to the project you forked from nvie. Can you give a summary of what you have done?