What is the difference between trunk based development and gitflow?

Question

I've been searching the internet and I can't find a good question to this so I believe I have a fundamental misunderstanding on what they are.

Is the only difference that in gitflow there is a release branch for your "not released yet" changes and in trunk based there isn't one?

Because for either method, you are going to need some way to identify where "production" is - in gitflow that's via the main branch and in trunk based development, that's via a tagged commit.

And wouldn't for whichever method you choose, if a hot fix is required for production, isn't that fix going to need to branch off the tagged commit or the head of the main branch? And then afterwards, you are going to need to merge those hotfix changes with your release changes.

It seems either way it's going to end up the same. I don't understand why gitflow encourages long lived feature branches. That sounds like a problem that can happen with both trunk or gitflow.

I also hear of people complaining that in gitflow it's common to get merge conflicts when merging your release changes into main. I don't understand how that can happen unless you're already doing something wrong. There should never be conflicts because the only branch that ever gets merged into main is release.

What fundamental differences am I missing here?

Answer 1

On a "mechanical" level, you seem to understand both version control strategies and their branching models. I believe there is a philosophical component that you are missing.

The main philosophy with trunk-based development is to always have your main branch in a releasable state. This implies several things, some of which you already noted:

• Short-lived branches.
• Good automated test coverage.
• Feature toggles or switches to hide "in progress" work from end users.
• Reduced merge conflicts, because branches are short-lived, and all work in progress and bug fixes can be based on the same branch.
• Feature branches tend to exist at the task level, rather than the story or epic level of work.

You can achieve 3 of the 5 items above using Gitflow. In my experience, merge conflicts happen more often simply because feature branches exist. Several lines of "in progress" work are built simultaneously, but not merged together. Long-lived branches are not mandatory in Gitflow. Branches tend to live longer in Gitflow simply because it is more permissible to create longer-lived branches.

There is also a difference in what "feature branch" means. In Gitflow, a feature branch is longer lived because people tend to implement an entire user story or application feature. It is not uncommon for a developer to complete several tasks in a single feature branch. This takes longer, which is the reason why you get more merge conflicts.

Feature branches in trunk-based development are used for tasks. Completing a story or application feature might require several tasks. Each task gets its own feature branch in trunk-based development. You likely need several feature branches to complete a story.

You can emulate trunk-based development in Gitflow by using feature branches to complete 1 task, and merging everything into dev. This is an over-complication of trunk-based development, because the dev branch is yet another long-lived branch. Feature branches, the dev branch, release branches — they all serve to isolate work.

The main difference between trunk-based development and Gitflow is how each isolates different lines of in-progress work. Gitflow achieves isolation of work using version control. New features are isolated in their own branches. Trunk-based development achieves isolation of work using feature toggles and other coding practices rather than how the team uses version control.

To summarize:

• Gitflow uses version control strategy to isolate work.
• Trunk-based development combines a simpler version control strategy with a more complex coding style to isolate work.

Answer 2

I guess I need to write an answer explaining why the two are identical.

Here you can see diagrams for both methods.

Now lets rename "trunk" to "develop". You can see that the only difference is that the release branches in GF are merged into main.

But unless there has been a "hotfix" branch this merge results the main branch being identical to the release branch.

hotfixes are not shown in the official TBD pic, but you would by definition have to do them on a release branch, which would make it functionally equivalent to Gitflow.

_{Figure 1:Trunk/Master based development (altered to be gitflow)}

_{Figure 2: sStandard Gitflow}

The more extreme (only use for "v-small teams") version of TBD, where you push directly to trunk/main, isn't even worth addressing. Practically speaking any form of PR, approval, build testing, CI/CD etc will force the creation of a feature branch behind the scenes. If anything goes wrong with your small feature you will end up creating branches from earlier commits to deal with it.

Gitflow is a way of managing your branches so that you can deal with the bad things, features that get delayed, feature flagging not being possible for some reason, manual release testing that takes a long time etc.

TBD which takes into account these possibilities "TBD at scale" is identical to gitflow

Answer 3

Trunk Based Development and Git Flow have several differences. There are things that each one includes where the other is silent. Neither is a complete solution to the problem of how to make software, so they both leave some things unspecified where a team needs to make its own decision, or take direction from elsewhere.

I treat https://nvie.com/posts/a-successful-git-branching-model/ as the authority on Git Flow, and https://trunkbaseddevelopment.com along with https://cloud.google.com/architecture/devops/devops-tech-trunk-based-development as the authority on TBD.

Long lived feature branches don't happen with TBD because TBD is explicitly defined as a workflow that doesn't involve long lived feature branches. Of course they do happen sometimes with teams that are trying to follow TBD - people don't follow methods perfectly.

The git flow blog post can be seen as encouraging long-lived feature branches because it only permits merging "finished features". Depending on how big a change you consider a feature, and what you call "finished", it may be hard sometimes to finish a feature within a day.

Stackexchange doesn't support tables, so here is a list of topics:

• Time interval between branching and merging:
  • GF: As long as it takes to finish a feature
  • TBD: At most one day, or at most a couple of days.
• Branches:
  • GF: Develop, master, feature branches, release branches, hotfix branches
  • TBD: Trunk, optionally release branches, optionally any other short-lived branches for work in progress (e.g. feature branches)
• Hotfix branch created from:
  • GF: Master
  • TBD: Trunk, with a cherry-pick to release if required.
• How to know where production is:
  • GF: Master is production-ready, but may or may not be already in production. How to know which commit on production was last deployed is not specified. If deployment automation is in place then it may be assumed that master as it is now or as it was very recently is generally in production.
  • TBD: Unspecified, but if deployment automation is in place then it will generally be from the latest release branch, or from trunk if release branches are not used.
  • In both cases something needs to be added to make it possible to see what version(s) are in production, or released for installation on customer machines. There may well be multiple versions in operation at once, either just while deployment jobs are running, or for a long time if many copies of the software run in different places, e.g. on customer's computers.