6

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?

6
  • 1
    think ive answered this before: softwareengineering.stackexchange.com/questions/390885/…
    – Ewan
    Commented Dec 19, 2022 at 12:52
  • TLDR: there isnt a real difference
    – Ewan
    Commented Dec 19, 2022 at 12:52
  • @Ewan: in my experience there is a difference between Gitflow and trunk-based development. But I agree that Gitflow does not imply long-lived branches. Regardless of branching strategy or philosophy, the longer a branch lives, the more merge conflicts you need to deal with. Commented Dec 19, 2022 at 12:55
  • @GregBurghardt yes, i think you sum it up well in your answer, my only criticism would be that feature toggles and small features are normal things to do regardless. They don't belong to "trunk based" and removing the dev or feature branches from Gitflow has no bearing on their effectiveness
    – Ewan
    Commented Dec 19, 2022 at 13:07
  • @Ewan: you are also correct, but I do not think a feature branch is necessary when using a feature toggle, which reverts Gitflow to trunk-based development. An argument could be made to mesh the two version control strategies together where it makes sense. Not very code change is 100% backwards compatible and hidden from the end user. Commented Dec 19, 2022 at 13:15

3 Answers 3

11

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.
9
  • Thanks but I still don't understand why this statement is true - "Branches tend to live longer in Gitflow simply because it is more permissible to create longer-lived branches" since feature branches exist and is used in trunk-based development. I also don't see why trunk based development's version control is simpler. It's simply using tags in place of branches. But they're both just used as markers to mark a significant development event (eg. like the last prod release)
    – RoboShop
    Commented Dec 19, 2022 at 13:15
  • @RoboShop: you might be getting confused by the term "feature branch". This does not imply the branch lives a long time. It implies it is not the main branch. Commented Dec 19, 2022 at 13:16
  • Ah ok, so when I mean feature branch, I'm talking about whenever I'm implementing a new user story or fixing a bug, I'll do it in a "feature" branch before PRing it into the main or release branch. Is that what you are meaning too? Cause my understanding of that is that in trunk development, you would do that too and therefore if you have multiple feature branches by multiple devs, the chances of a merge conflict would be the same?
    – RoboShop
    Commented Dec 19, 2022 at 13:23
  • 2
    Ok, I'm seeing the misunderstanding now. The term "feature branch" is used in trunk-based development to mean "not the main branch". Let me update my answer in a little bit. Commented Dec 19, 2022 at 13:26
  • 2
    Thanks Greg - I understand your point now and appreciate the differences between what is considered a feature in TBD and GF - that to me seems like the biggest difference and in many ways, makes these two methodologies almost two sides of a spectrum - like a project team may not solely be in the TBD or GF camp but might be leaning towards having task or story based feature branches and those factors could be dependent greatly on the domain and the problemset it's operating in.
    – RoboShop
    Commented Dec 19, 2022 at 14:04
4

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)

Trunk Based

Figure 2: sStandard Gitflow

git flow

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

8
  • 1
    I really do not see how these are the same. If really have feature branches in Gitflow that live for only a single task, then you are doing trunk-based development with extra branches, merging, and headaches. They can be pretty similar, but the difference is philosophical. Gitflow isolates work in progress using version control. Trunk-based development isolates work in progress using feature toggles or switches. The existence of feature branches is independent of trunk-based development. Commented Dec 19, 2022 at 16:36
  • maybe you can point out which branches are extra?
    – Ewan
    Commented Dec 19, 2022 at 16:55
  • In TBD, release branches are only necessary if you need to patch the release. Tags will suffice. The dev branch is unnecessary in TBD. The other difference is how feature branches are typically used by people in real projects. I see lots of feature branches in Gitflow living for multiple days or even weeks, not because this is prescribed by Gitflow, but simply because of the scope of work. The scope of work in TBD is inherently small, since everyone is working off of main, and merging into main, and main is always kept releasable. Commented Dec 19, 2022 at 16:59
  • 1
    This ignores the "merge within one or two days" rule, which I think is the most important part of Trunk Based Development, and does not exist in Git Flow.
    – bdsl
    Commented Dec 19, 2022 at 18:32
  • 1
    Agreed that development is a renamed trunk. So the only difference is how aggressively you merge in feature branches (feature flags compared to never, ever merging in anything “unfinished”). Git Flow is also similar to TBD in that all branches except development and the feature branches are unnecessary (so for sake of comparison you can ignore them). Commented May 18, 2023 at 20:34
1

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.
15
  • "Hotfix branch created from: [...] TBD: Trunk, with a cherry-pick to release if required." --- I can see cherry picking between feature branches. Base your hotfix on the release, and then merge to the main branch. Cherry picking between your main branch and a release branch just invites merge conflicts. Commented Dec 19, 2022 at 13:48
  • 1
    For context, I personally advocate for TBD to be used a lot more than it is, and for GF to be generally avoided.
    – bdsl
    Commented Dec 19, 2022 at 13:52
  • 1
    I don't know what sort of application you work on, but for anything like a web app, where there is just one production environment and it's controlled by the people who write the code, I would generally avoid having release branches in TBD, and deploy code from trunk instead, doing continuous delivery. Each commit on trunk is sent through a series of automated quality and correctness checks, and then deployed to prod if all checks pass.
    – bdsl
    Commented Dec 19, 2022 at 14:11
  • 1
    @Ewan No, the biggest difference is the time interval.
    – bdsl
    Commented Dec 19, 2022 at 15:58
  • 1
    The role of master in GF is more like the role of the series of release branches in TBD with release branches.
    – bdsl
    Commented Dec 19, 2022 at 16:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.