What is the GitFlow code branching strategy?

What is GitFlow?

I’ve been using the GitFlow code branching strategy professionally for a number of years now, and the amount of times it’s ’saved’ my team and I, I can’t count it.

Let’s dig into it..

First, what is source control / Git?

To explain what it is, well first, you have to know what is source control / Git(?)

'Source control' software helps to store and manage every modification to code.

It provides a history of changes and the ability go back to a specific version in history.

Source control also provides the ability for individuals to create separate derivatives, or branches of the code, which can later be merged back into the main code.

'Git' is the most widely used modern version control system in the world today.

What is GitFlow?

'GitFlow' is a just an abstract strategy for what primary and short-term code branches to have during development. It was created by Vincent Driessen.

It helps individuals and teams manage, integrate, and release their code effectively by providing a framework for how and when to branch code.

It is better suited for teams with planned deployment 'cycles'/releases, and less suited if they do true continuous deployment (CD) with auto-releases.

Here are the various code branches in GitFlow:

Main branch + Develop branch

To start Gitflow requires two primary branches; 'main' and 'develop'.

The 'main' branch stores the official release history.

The 'develop' branch is used as an integration branch for all feature branches (next section).

Feature branches

Each new feature or fix should be started in its own 'feature branch'. The develop branch should be used as the base branch.

When the feature is completed (and preferably tested) it should be merged back into the develop branch.

Release branches

Once it's time for deployment, a 'release' branch is created from the 'develop' branch. After this point the release branch should only have regression issues fixed on it if needed; no new features.

After deployment, the release branch is merged down into the main and the develop branches.

Hotfix branches

If a hotfix/patch for any production release is needed, then a 'hotfix' branch is created from a release point on the 'main' branch.

After deployment, the hotfix branch is merged down into the main and the develop branches.

When to use GitFlow?

• A release-based team/company where there are routine deployments planned over development cycles.
• Where multiple releases may need to be worked on in parallel (i.e. next version and unplanned hotfix version)

When NOT to use GitFlow?

• In truly continuous delivery/deployment scenarios where very short-lived feature branches and a single primary branch are needed
• Where the team merges & deploys the shared branch frequently with automated testing, versus longer deployment/testing cycles

Have you done GitFlow before? If not, what branching workflow/strategy do you use?