What is the GitFlow code branching strategy?
Tags: git, programming, github, productivity
Published: 2023-02-06 04:28:58

**What is [GitFlow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow)?**

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](https://aws.amazon.com/devops/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](https://git-scm.com/)' is the most widely used modern version control system in the world today.

## What is GitFlow?
'[GitFlow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow)' 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).

![GitFlow Main branch + Develop branch](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/p86w289lehinatncvldh.png)

## 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.

![GitFlow Feature branches](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wfrcyip7gt8mhw8uls8c.png)

## 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.

![GitFlow Release branches](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kit0bx5weoe2w8odu0ft.png)

## 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.

![GitFlow Hotfix branches](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/j12cz627k7yyeds1payh.png)

## 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?