Why you should bother with git-flow

What is git-flow?

git-flow is the common branching workflow in industry when working with software projects and a team of developers. For those of you that don't know what it is, I'd recommend reading the original article. I won't repeat information that's already available in this article, but instead focus on my thoughts from using this model at work.

P.S. Many developers these days use Git IDEs, e.g. Sourcetree, Tower, that have baked in support for this workflow and easy setup. If you prefer the command line, you may like this tool.


  1. Clean timeline of project history: git-flow tidies up the git history, making it easy to see what features were developed for particular releases, how long features were in development for, what hotfixes were pushed at what time, who worked on particular tickets, and much more. As a project grows in size, git-flow manages the complexity of working in distributed teams with a simple unified framework.
  2. Clear separation of concerns: git-flow clearly separates the main branch as live, production code, and develop for code in development. With clear separation of environments, we can also further know where to find feature branches (from develop), and hotfix branches with clear separation or concerns. SoC is a well-known best practice in software development, and git-flow easily enforces this for Version Control.
  3. Automated release version management with git tags: Git tags are an easy way to mark a release as complete. If you want to quickly rebuild the project for a given release version, GitHub enables us to checkout the source code at a particular tag version. GitHub also has the option to convert GitHub tags (from git) to GitHub releases. This could be helpful for public vendors of the repository. Tags can also help for debugging legacy bugs in production.
  4. Simple, bug-free automation: Without git-flow, the process of branching, tagging, merging, branch naming and so forth were not standardised. git-flow simplifies a workflow because we don't need to manually create a tag, and we can't accidentally merge into the wrong branch. The model automates best practices, and prevents cluttering up a pristine project history.
  5. Options for CI: CI takes automation to the next level, and is commonly practised for most large software projects to save time. git-flow's unique branching model means that we can trigger specific deploy to the App Store / prod environment when merging a release to main for example. Similarly, hotfixes can be quickly uploaded to the alpha/beta environments for every commit and to production environments whenever they are merged. The workflow is very customisable.


  1. git-flow is a merge-based workflow: As such, if you prefer to rebase branches when joining develop or main, git-flow will not be able to support you. The disadvantage here is a personal preference rather than strict disadvantage. Merging vs rebasing is a common disagreement among developers, one arguing that seeing the branch timeline is more important than a pristine history.
  2. Challenging to get used to: git-flow is very different to how developers may have managed their own personal projects. The branching model can be overwhelming at first with all the details, and we have to be careful with every action we take to ensure a pristine history. Once you get used to the workflow however, you won't look back. As with most automation, it's hard at the start but pays dividends in the long-term.
  3. Designed for git specifically: As the name suggests, git-flow was made to work best with git or DVCS'. Subversion projects are centralised, and have less developed implementations for tagging, as well as weaker handling of merge conflicts. For these projects, Trunk-Based Development is the way forward: it's a development workflow that predates git-flow. I haven't used Mercurial but I would think the ecosystem is less developed than git.
  4. Designed for traditional release models (not CD): git-flow works well for products in a more traditional release model, where releases are done once every few weeks, but that this process breaks down considerably when you’re releasing once a day or more.

TIP: At first, all we need to know are high-level details, so focus on getting those concepts right before worrying about the details.


git-flow is a powerful workflow that is well-used across the industry for a wide variety of reasons, most notably that git is the most widely used VCS. git-flow makes it easier to manage large software projects, and keep track of the evolution.

I personally used git-flow in my previous job, and enjoyed the simplicity of the workflow once I got used to it. If you're working in industry, or looking to, you will definitely need to know about this branching model. So, try using it for your own side projects, and get to grips with it.


  1. git flow article
  2. git flow cli tool and cheatsheet
  3. Trunk-Based Development