The GitfLow branching model was introduced a little over 10 years ago by Vincent Driessen around 2010. It has become since then one of the standards of version control strategies over the world, especially for Scrum development driven teams.
Why though ?
One word: Features.
This workflow mainly focuses on feature branches. It offers a perfect framework for Scrum mode, as Sprints consist on delivering features to a given product.
GitFlow Branches
master and develop
Project is initiated with a master and a develop branch. Master branch handles all official versions of a product. All commits on this branch are versionning commits, you can also tag them with the relevant version of the product. Trust me it’s useful.
Next, fork a develop branch from master. All future development commits will reside here, they’ll allow you to test and validate your development before you version it on master.
$ git flow init
Initialized empty Git repository in ~/project/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
$ git branch
* develop
master
Now, all your branches are initialized and you’re on develop branch.
Feature branches
Features branches are branches that you fork from the develop branch only. They allow you to retrieve the latest version of the code. And as their name indicates, they allow you to develop on feature basis. Which mean you would have branches like :
- feature/feature-1
- feature/feature-2
These branches are forked when a feature development is required. It gives more flexibility to parallel development. You can init a feature branch with the following command.
$ git flow feature start feature-1
A feature development ends when:
- Feature code is functional
- Feature branch of the corresponding feature is merged to develop branch You can end the Feature with
$ git flow feature finish feature-1
Release branches
Release branches allows you to officially version an operational code and product at a certain point of time. Release branches are forked from a commit in the develop branch.
$ git flow release start 0.1.0
Switched to a new branch 'release/0.1.0'
Release ends when the versionned code satisfies product requirements. This means this version is tested and ready to be merged to master.
$ git flow release finish '0.1.0'
This will merge the release branch not only to master, but to develop as well, as we always need to keep latest version of code in develop branch so as future feature branches start from the most recent version of it.
Hotfix branches
As in life, not everything goes as planned… And we must recover fast. Hotfixe branches allow to correct undetected bugs on the master branch directly.
$ git flow hotfix start hotfix-1
They are forked from a version on the master branch, correction is implemented, then merged back to master branch as a new version of code, and of course to develop branch as well.
$ git flow hotfix finish hotfix-1
Code Life Cycle
A complete development lifecycle would be (Without using the git flow extension).
git checkout master
git checkout -b develop
git checkout -b feature-1
# work happens on feature-1
git checkout develop
git merge feature-1
# work ends on feature-1
git checkout master
git merge develop
# feature-1 is released to master
git branch -d feature-1
# feature-1 is deleted
git checkout master
git checkout -b hotfix-1
# work is done commits are added to the hotfix-1
git checkout develop
git merge hotfix-1
git checkout master
git merge hotfix-1
