Git: gitflow workflow

The gitflow workflow defines a strict branching model designed around the project release. This workflow assigns very specific roles to different branches and defines how and when they should interact. It uses individual branches for preparing, maintaining, and recording releases. This article is based on a article written by Atlassian.

The core idea behind the gitflow workflow is that all feature development should take place in a dedicated branch instead of the master branch. This encapsulation makes it easy for multiple developers to work on a particular feature without disturbing the main codebase. It also means the master branch will never contain broken code, which is a huge advantage for continuous integration environments. Instead of committing directly on their local master branch, developers create a new branch every time they start work on a new feature. This workflow uses a central repository and uses two branches to record the history of the project.  The master branch stores the official release history, and the develop branch serves as an integration branch for features. It’s also convenient to tag all commits in the master branch with a version number. The main gitflow diagram:

Screen-shot-2009-12-24-at-11.32.03

The main branches

Sidenote: origin is the original remote repository, by convention it is the ‘primary’ centralized repository as well.

Gitflow has two main branches:

  • master
  • 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.

When the develop branch should be released all of the changes should be merged back into master. Therefore, each time when changes are merged back into master, this is a new production release by definition.

Supporting branches

Unlike the two main branches, these branches always have a limited life time, since they will be removed eventually. The different types of branches we may use are:

  • Feature branches
  • Release branches
  • Hotfix branches

Feature branches

May branch off from: develop
Must merge back into: develop
Branch naming convention: anything except master, develop, release-*, or hotfix-*

Feature branches are used to develop new features. The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into develop. Feature branches typically exist in developer repos only, not in origin.

git-workflow-release-cycle-2feature

Release branches

May branch off from: develop
Must merge back into: develop and master
Branch naming convention: release-*

Release branches are created from the develop branch. Release branches support preparation of a new production release. They allow for last-minute changes or bugfixes. Furthermore, 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. When the state of the release branch is ready to become a real release:

  • The release branch is merged into master. That commit on master must be tagged for easy future reference to this historical version
  • The changes made on the release branch need to be merged back into develop, so that future releases also contain these bug fixes
  • The release branch may be removed (we don’t want to many branches piling up)

git-workflow-release-cycle-3release

Hotfix branches

May branch off from: master
Must merge back into: develop and master
Branch naming convention: hotfix-*

The essence is that work of team members (on the develop branch) can continue, while another person is preparing a quick production fix. Hotfix branches are very much like release branches in that they are also meant to prepare for a new production release, albeit unplanned. They arise from the necessity to act immediately upon an undesired state of a live production version. When the state of the hotfix branch is ready to become a real release:

  • The hotfix branch is merged into master
  • The changes made on the hotfix branch need to be merged back into develop, so that future releases also contain these bug fixes
  • The hotfix branch may be removed (we don’t want to many branches piling up)

git-workflow-release-cycle-4maintenance

 


Leave a Reply