I had heard about gitflow before! But I though it just meant “this is how we git”. Which it kinda does, but it is a name for a specific approach. When people talk about GitFlow, they can mean:

• The model introduced in this 2010 blog post: A successful Git branching model
• The tools built to use that model, like nvie/gitflow and jgit-flow

From previous gig, I’ve been used to a straight forward world of trunk based development:

A source-control branching model, where developers collaborate on code in a single branch called trunk, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after.

That said, these notes are not really about upsides and downsides of gitflow vs trunk. This is only about me understanding the technical implications. Let’s go!

Main branches (unique and infinite)

• master — always production-ready
• develop — always with the latest delivered changes for the next release

Supporting branches (multiple and short)

• features — branch off develop, work on feature, merge back to develop
• releases — branch off develop, complete release, merge back to develop and to master
• hotfixes — branch off master, fix, merge back to develop and to master

Release branches 🚀

I’ve honestly not been used to thinking much about releases. It was something that the automation handled in the background without any ceremony. The only time I dealt with a release number, is when debugging a problem in the deploy pipeline. But now I need to get a grip on releases.

Release branches support preparation of a new production release. They allow for last-minute dotting of i’s and crossing t’s. They allow for minor bug fixes and preparing meta-data for a release (version number, build dates, etc.). By doing all of this work on a release branch, the develop branch is cleared to receive features for the next big release.
– Vincent Driessen about GitFlow

Atlassian has a really nice tutorial on Comparing Workflows and describes that:

The Gitflow Workflow defines a strict branching model designed around the project release. This provides a robust framework for managing larger projects.

Hotfix branches 🔥

The essence is that work of team members (on the develop branch) can continue, while another person is preparing a quick production fix. – Vincent Driessen about GitFlow

---

Automating gitflow

• Original command line tool: github.com/nvie/gitflow
• Fork that is still under development: github.com/petervanderdoes/gitflow-avh
• A maven plugin to handle bumping in pom.xml jgit-flow
  • built on Eclipse JGit (a Java implementation of Git)
• and then we have our own scripts to handle it all with our setup 🤖

More links

• git-flow cheatsheet
• “GitHub flow is a lightweight, branch-based workflow that supports teams and projects where deployments are made regularly.” Understanding the GitHub flow
• …and 3rd model with almost the same but different name: GitLab Flow

---

What I misunderstood

I thought it would be fine to update a small thing with a branch and merge request to master.

What I understand better now

Using gitflow, there’s more effort involved in keeping the two main branches in sync. (When you do trunkbased, you can throw your hands up and not have to think much about branches. Any merge conflict is up to the owner of a feature branch to solve, because master alone is the boss.)

What I’m happy about

Many a h/t to the friend who thoroughly taught me git theory years ago — or gitflow would break my brain. (Now it only fries it a bit on the edges.)