Gitflow

Written by Luka Kerr on March 31, 2018

Gitflow is a branching model for Git based around creating different types of branches depending on whats being developed. It’s essentially a workflow for developing with Git using an agile approach.

There are 5 main branches involved when using Gitflow - master, develop, feature/, hotfix/ and release/.

Gitflow can be used on the command line, or in a GUI such as Tower.

The original Gitflow idea was written about by Vincent Driessen here.

Workflow

Master

All production level code lives inside the master branch. When deploying to production, master is always the branch to be deployed. This is important as master can be deployed anytime without worry that bugs will popup.

Develop

Along side master is the develop branch which contains the latest development changes for the next release. This can be thought of as the “staging” branch or “integration” branch. It should contain code that is quite stable from new features but still needs testing in a production like environment.

Feature

All new features and non-emergency bug fixes should be developed in a feature/ branch. For example, if a new feature is wanted to optimize images, a feature branch called feature/optimize-images would be created. Usually feature branches should be created off of the develop branch, although in some cases they may be created off master. When feature branches are finished, they should be merged into develop.

The workflow of a feature branch is as follows, where MYFEATURE could be optimize-images:

$ git checkout develop               # or master
$ git pull                           # make sure your up to date
$ git checkout -b feature/MYFEATURE  # create your feature branch
$                                    # do some development
$ git checkout develop               # once finished, switch back to develop
$ git merge feature/MYFEATURE        # merge the feature branch into develop
$ git push origin develop            # push the newly merged develop branch
$ git branch -d feature/MYFEATURE    # delete your feature branch

Hotfix

hotfix/ branches are used specifically for quick, important fixes that arise on production. Hotfixes are created off the master branch, not develop. This allows other developers to continue work on develop while a hotfix is pushed out.

For example, if a hotfix pops up related to an xss vulnerability, you would do the following:

$ git checkout master                # checkout master branch
$ git pull                           # make sure your up to date
$ git checkout -b hotfix/xss-vuln    # create your hotfix branch
$                                    # do some quick fixes, commit and test
$ git checkout master                # once finished, switch back to master
$ git merge hotfix/xss-vuln          # merge the hotfix branch into master
$ git push origin master             # push the newly merged master branch
$ git branch -d feature/MYFEATURE    # delete your hotfix branch if the issue has been resolved

Release

When code in develop wants to be released, a release/ branch is created off of the develop branch. This release branch is also “tagged” with the release number.

To find the latest tagged release run git describe. To see all tags, run git tag. It is best when creating a release to use the next logical release number. If the release is big enough, a new major release number may be created. The release tagging convention is to use semantic versioning.

For example, if you were releasing version 1.8.0, you would do the following:

$ git checkout develop               # checkout develop branch
$ git pull                           # make sure your up to date
$ git checkout -b release/1.8.0      # create your feature branch
$ git tag 1.8.0                      # tag the release branch
$ git checkout master                # switch to master
$ git merge release/1.8.0            # merge the release branch into master
$ git push origin --tags             # push the new tag(s)
$ git push origin master             # push the newly merged master branch
$ git branch -d release/1.8          # delete your release branch AFTER master has been deployed, incase hotfixes need to be released in the same release version