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 -
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.
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.
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.
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
The workflow of a feature branch is as follows, where
MYFEATURE could be
$ 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/ 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
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