Git Flow

Workflows

Git flow provides 3 workflows to make it easier and smooth updating the code base in a git repository:

• Feature: Add a new feature or fix a non urgent bug
• Release: Release a new version
• Hotfix: Fix an urgent bug because something went wrong in production

What is git flow?

It is superset of git sub-commands starting with git flow that help automate the above recurrent workflows. It helps you type less recurring and error prone boilerplate git commands in order to focus more on what you really need/love to do.

Setup

Install

Windows and Linux

https://danielkummer.github.io/git-flow-cheatsheet/#setup

MacOS

brew install git-flow-avh

I prefer installing and using git-flow-avh instead of git-flow because it offers more features, like for instance the --showcommands option useful to see the underlying git commands git-flow is running.

Configure

https://danielkummer.github.io/git-flow-cheatsheet/#getting_started

# First off, make sure you have both the develop and master branches available locally
git checkout develop
git checkout master

git flow init

Using the default values (in between square brackets in the screenshot below) is the recommended way to go except you if you have an existing project with a naming convention for branch(es) that differs from default git flow convention.

FYI, this adds at least the following to the git config file (.git/config).

[gitflow "branch"]
        master = master
        develop = develop
[gitflow "prefix"]
        feature = feature/
        bugfix = bugfix/
        release = release/
        hotfix = hotfix/
        support = support/
        versiontag =

Feature

This is how we add a new feature or fix a non urgent bug (not an emergency) to the code base. For urgent bug fix cf. Hotfix.

Here is a diagram that gives a visual representation of the flow

[TODO]

Release

Here is a diagram that gives a visual representation of the flow

[TODO]

Hotfix

We use this process when something went wrong in production and needs to be fixed immediately.

Here is a diagram that gives a visual representation of the flow

Start a Hotfix

A hotfix branch starts off master and ends up being merged into master when you finish it. You don't have to checkout master beforehand because git flow does this for you (see below).

git hotfix start A.B.C-n
# You are now on the branch hotfix/A.B.C-n  ready to commit fixes

For instance, here is how to start the first hotfix for the release 1.9.4:

git flow hotfix start 1.9.4-1
# You are now on the branch hotfix/1.9.4-1  ready to commit fixes

Here is the command git flow runs under the hood to start the hotfix, so you don't have to:

git checkout -b hotfix/1.9.4-1 master

Publish a hotfix branch

Your mileage may vary here, because this command does not exist in all git flow implementations, maybe because pushing a hotfix branch to the remote is not considered a use-case common enough. It however may prove to be useful when a hotfix requires several developper to commit code to a hotfix branch.

git flow hotfix publish A.B.C

If your git flow implementation does not provide the publish sub-command, then use instead

git push origin hotfix/A.B.C

Finish a Hotfix

git hotfix finish A.B.C

Here are the commands git flow runs under the hood to finish the hotfix:

git checkout master
git merge --no-ff hotfix/A.B.C

git tag -a A.B.C

git checkout develop
git merge --no-ff hotfix/A.B.C

git branch -d hotfix/A.B.C

Tags

• Release candidate tags A.B.C-RCn are added on the release branch.
  For instance the RC tag 1.9.4-RC1 is added on the release branch release/1.9.4.
• Hotfix and Release tags are added exclusively on the master branch.
  eg. 1.9.4-1 (First hotfix for release v1.9.4)
  eg. 1.9.4 (release v1.9.4)
  Git flow add the tag for you when you finish a hotfix/feature branch, so you don't have to do it manually!