GitFlow in practice

How to use GitFlow common operations.
Posted in Early industrialization, the 16/07/2022.


Source control empowers developers in their work, but it’s also interesting to think about the role these tools can have on a team rather than on each developer individually.

As a team lead, I think those tools really shine when being used to organize the collaboration process, also called workflow.

There are different kinds of source control workflows, and it’s always interesting to compare them to find the one that best suits your organization. There’s one in particular that has grown pretty popular: the GitFlow workflow. Let’s have a look at how you can put it into practice.

What is GitFlow

The GitFlow workflow is a way of organizing the team collaboration around the use of git branches.

Here are its main principles:

  • You have two protected branches to start with (one called main, and another one: develop), and then three types of branches you can open depending on what you want to do: features, releases, hotfixes (we’ll explain more on that shortly).
  • With this workflow, you can think about the main branch as the state that is currently in production, develop as the state that is currently in staging, and each feature branch as the state that is currently on a developer’s local machine, which is interesting to have in mind.
  • Compared to the feature branch workflow, when you start a new feature, you still create a feature branch, but it starts off develop instead of main, and gets merged back to develop (instead of main again) once completed. This is a time, to do pull requests and code reviews.
  • When you want to merge code to main, you open a release branch, this is a new kind of branch that will take your code from develop to main. Generally, you do this when you have finished one or more features in develop, and you want them to go live on your production environment. Typically when you do this, you increment your product, app, or site version number.
  • There’s a third kind of branch that is hotfixes. Why would we need such things you might ask? It’s because in GitFlow, you never push code on the main branch directly. You first push changes into the develop branch, then merge the develop branch into the main one. That can be a problem if you want to push code into production, but don’t want to push code that is already on the develop one. If you see a problem in production, you’d want to patch it quickly. That’s when you open a hotfix branch.

With these principles in mind, here’s an explanatory video to better understand the GitFlow mechanics.

GitFlow advantages and disadvantages


  • As we’ve seen in the previous section, with this workflow, thanks to the fact that you associate the main branch as the state that is currently in production, and the develop one as the state that is currently in staging, you have a clear vision on the state that is currently deployed on your environments, and that’s important.
  • There’s no “work in progress” on main or develop, only stable features, which means you can deploy or redeploy them at will, and with confidence.
  • This branching model created identifiable times to open pull requests and favors code reviews. And code reviews have many advantages on code quality and knowledge sharing.
  • It’s an interesting workflow for CI/CD strategies.


  • Feature branches are created from the develop one at some point, then the developer works on it, then wants to merge it back via a pull request: that involves some teamwork that can slow the team velocity down. It does slow the team down, that’s a fact we’ll embrace. It turns out, it does slow you down, but in a good way. Problems can occur more frequently if you rush things into production.
  • Once the branch is ready to be merged back into develop, develop might have progressed over time, and the merge might not be possible right away because of conflicts between the feature branch state and the develop state. Conflicts will need to be fixed before merging.
  • GitFlow has become so popular in many software teams to the point where people have started treating it like a standard. It is not a standard, it’s a branching model, that shouldn’t be treated as a dogma.

How to use GitFlow in practice

Installing GitFlow

GitFlow is a branching model, a git-based workflow, that requires its users to create a lot of branches, and switch often between them.

You can do all of those manipulations with standard git commands, but it can become fastidious.

Instead, you can use some GitFlow-enabled tooling. I use Atlassian SourceTree in my daily work, which supports GitFlow natively. For command line users, packages for git-flow are available on multiple operating systems. On OSX for example, you can execute brew install git-flow. On Windows, you will need to download and install git-flow

The GitFlow scenario

Here’s a typical GitFlow sequence we’ll be covering in the video tutorial:

  • Given an empty repository.
  • Make sure the main branch is valid
  • Configure GitFlow
  • Create a feature branch
    • Create a pull request for this feature branch
    • Merge the feature branch into develop
    • Pull develop locally
    • Cleanup the local feature branch
  • Create a release branch
    • Make some release adjustments
    • Merge it into master
    • Push local changes over remotes
  • Create a hotfix
    • Apply the hotfix
    • Merge it
    • Push local changes over remotes

Using GitFlow with SourceTree

Let me show you how I perform this entire scenario with SourceTree in the following video:


GitFlow is an interesting Git-based workflow that can organize the way your team operates while developing software. I like the way it orchestrates the delivery process around branch manipulations, and gives those branches specific roles. Another advantage from a team lead point of view: it creates times for pull requests and code reviews to improve quality and transmission. Those times can also be used to trigger CI/CD pipelines to automate delivery. The main and develop branches are clean and reflect the state of what’s currently in the staging or production environments which is a big readability bonus.

I hope you enjoyed the video. Don’t hesitate to let me know on Twitter or YouTube.