6 ms·

I tried using Gitflow on our team, but there was too much complexity for me. We ended up switching to Trunk Based Development (TBD)[1] which I and my team found

by umvi 7y ago

I tried using Gitflow on our team, but there was too much complexity for me. We ended up switching to Trunk Based Development (TBD)[1] which I and my team found to be much simpler. [1] https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/

wcarss 7y ago
+1 to trunk based. There's obviously a lot there, but one of the best bits is the idea that each release deserves a branch. It makes hotfixes, ci/cd, and rollbacks all much simpler to reason about.
alexbanks 7y ago
I didn't know there was a name for this, but I've been doing it for 2 years now and I don't think I could go back.
- obelos 7y ago
  Same here. My team has been managing our git repo like this for years, but I didn't realize there was a named practice around it.
  - mixmastamyk 7y ago
    It was the way in the svn days and common before. But folks attracted to git are often the same that like to desimplify things.
billti 7y ago
I would love all the hours back I spent in discussions around branching strategy, trying to keep complex models understood across the team (and myself), dealing with painful merges and flowing changes through, trying to figure out if a change is in a branch already, etc.. It's so much simpler and more productive if everyone works in master, with new features behind a flag if need be, with just critical fixes ported to release branches. There will always be arguments for why a more complicated branch strategy needs to be introduced. Resist those arguments. In my experience, the cost rarely pays for any benefits. Writing good software is hard enough already.
- sethammons 7y ago
  We work on a branch and merge to master only after code review and (usually) quality assurance. We also deploy asap after merging to master and passing all regression tests. We can and often do deploy the same service many times a day.
zoomablemind 7y ago
Same here. Trunk based is easy to explain and enforce. The only challenge we faced was maintaining patch releases. Folding in fixes for common issues which were found in newer releases sometimes involved more than just cherrypicking the fix into a patch release for an older version. This inevitably led to asking users to update to more up-to-date versions. This further enforced the linear development paradigm.
- gregmac 7y ago
  This is the one thing that I find lacking in trunk-based development. I work on multiple products that have a release branch for each minor release, and it works incredibly well other than this as a minor pain point. I find the easiest way is that if you know you want (or even think you might want) a particular fix in a patch version, you can make a branch from the oldest release branch you want to support. When you create a PR, you can easily target to the release branch (or another later release branch) or master, depending on what you want. You can even do multiple PRs to merge it multiple places. No matter how you go about it, it should always be safe to merge a release branch back into master. In fact, this is a good thing to do after you release a patch version, but can also be done whenever you need a particular fix in newer (master, or other feature branch code) code immediately. Merging release branches like this makes following a fix significantly easier than if you do it with cherry picking. Consider if you're looking at bug ticket, and trying to figure out what branches/releases it was fixed in. If the PR was merged to master, then later cherry picked to an older release, all you'll see is it was in master. Unless someone manually comments about it or your tooling picks it up based on references, the only other thing to do is check the code itself to see if the fix is there. When you instead merge forward, even if the ticket comments are wrong or not there, you can literally follow the branches from the PR/commits and see every release it got into.
  - brandmeyer 7y ago
    > Unless someone manually comments about it or your tooling picks it up based on references. I don't find this to be overly burdensome on the tooling. If the ticket-tracking system can't automate traceability between git commits and tickets, then it isn't well-suited to git-based software development. We use the following policy: - A bugfix commit must fix the bug, the whole bug, and nothing but the bug. If that seems impractical for the task at hand, make it practical by breaking up the bug's ticket into smaller elements. - Bugfix commits always cite the bug tracking system's ticket number. - The bug tracking system observes the git tree and maintains its own linkage to it. - When cherry-picking the bugfix to other affected branches, pass the `-x` argument to `git cherry-pick`. That's it. The (cherry-picked from) comment helps out when just viewing the git history on its own. And the bug tracking system lets you quickly see all of the commits and pull requests that referred to the bug.
Legion 7y ago
Trunk based using short lived feature branches is the only thing I've used that has made any sort of sense in terms of value vs. complexity.
bosswipe 7y ago
TBD is fine for web apps, but not for software that you have to maintain multiple versions in the wild at the same time or when the release cycle takes several weeks.
- wikibob 7y ago
  So...shouldn't the focus be fixing the fact that release cycles take several weeks? This is well researched and discussed in Nicole Forsgren's book: Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339 https://www.amazon.com/Accelerate-Software-Performing-Techno...
  - brandmeyer 7y ago
    Sometimes long test cycles are just the nature of the business, especially in hardware-software co-development, and especially in high-reliability development. Nobody will believe that running software tests on a workstation or server somewhere counts for release readiness if it gets deployed to a wind turbine, robot, or megawatt UPS. The software team's automated tests indicate that the software is ready to start an expensive physical testing cycle, not that its ready to go to the field.
- lilbobbytables 7y ago
  That isn't true at all. Trunk based is perfect for this because you have the clean release branches from the trunk. I've worked in large companyies very successfully using TBD and releasing quarterly to enterprise customers using our software on their systems.
  - blondin 7y ago
    > I've worked in large companyies very successfully using TBD and releasing quarterly to enterprise customers using our software on their systems. care to elaborate? curious about those companies and the software you are talking about. i totally see the trunk based process work for software that doesn't need to maintain multiple versions as the original commenter said. but for multi-versioned software you can't afford to have a single trunk and let your developers have a go at it. i went and checked the repos for some of the multi-versioned software that i use that are open-source. well confirmed.
jpswade 7y ago
Absolutely agree. I think git flow makes sense to begin with however once you start to do CI/CD, you need something a bit more robust. Trunk based development gives you that. No long lived branches. No merge hell. It’s considerably better.
- mixmastamyk 7y ago
  I’d argue that starting simple and adding complexity only when needed is a better strategy.
mcv 7y ago
The thing I don't get about trunk-based development is: if everybody always pushes straight to master, how do you do code review? Or don't you do code review in TBD? I like having explicit pull requests where a new feature can be reviewed.
- deleted 7y ago
  [deleted]
- adrianmsmith 7y ago
  That link does say that you can use pull requests for merging the short-lived feature branches back into master. It says that, for small teams, pushing directly into master might be acceptable (presumably without code review).
  - mcv 7y ago
    But how short-lived can they be? Feature development isn't necessarily short. Reviewing bits and pieces of a feature without having the whole thing together may not be very informative. And small teams may also care about code review.

by umvi 7y ago

wcarss 7y ago

+1 to trunk based. There's obviously a lot there, but one of the best bits is the idea that each release deserves a branch. It makes hotfixes, ci/cd, and rollbacks all much simpler to reason about.

alexbanks 7y ago

I didn't know there was a name for this, but I've been doing it for 2 years now and I don't think I could go back.

obelos 7y ago
Same here. My team has been managing our git repo like this for years, but I didn't realize there was a named practice around it.
- mixmastamyk 7y ago
  It was the way in the svn days and common before. But folks attracted to git are often the same that like to desimplify things.

billti 7y ago

I would love all the hours back I spent in discussions around branching strategy, trying to keep complex models understood across the team (and myself), dealing with painful merges and flowing changes through, trying to figure out if a change is in a branch already, etc.. It's so much simpler and more productive if everyone works in master, with new features behind a flag if need be, with just critical fixes ported to release branches. There will always be arguments for why a more complicated branch strategy needs to be introduced. Resist those arguments. In my experience, the cost rarely pays for any benefits. Writing good software is hard enough already.

sethammons 7y ago
We work on a branch and merge to master only after code review and (usually) quality assurance. We also deploy asap after merging to master and passing all regression tests. We can and often do deploy the same service many times a day.

zoomablemind 7y ago

Same here. Trunk based is easy to explain and enforce. The only challenge we faced was maintaining patch releases. Folding in fixes for common issues which were found in newer releases sometimes involved more than just cherrypicking the fix into a patch release for an older version. This inevitably led to asking users to update to more up-to-date versions. This further enforced the linear development paradigm.

gregmac 7y ago
This is the one thing that I find lacking in trunk-based development. I work on multiple products that have a release branch for each minor release, and it works incredibly well other than this as a minor pain point. I find the easiest way is that if you know you want (or even think you might want) a particular fix in a patch version, you can make a branch from the oldest release branch you want to support. When you create a PR, you can easily target to the release branch (or another later release branch) or master, depending on what you want. You can even do multiple PRs to merge it multiple places. No matter how you go about it, it should always be safe to merge a release branch back into master. In fact, this is a good thing to do after you release a patch version, but can also be done whenever you need a particular fix in newer (master, or other feature branch code) code immediately. Merging release branches like this makes following a fix significantly easier than if you do it with cherry picking. Consider if you're looking at bug ticket, and trying to figure out what branches/releases it was fixed in. If the PR was merged to master, then later cherry picked to an older release, all you'll see is it was in master. Unless someone manually comments about it or your tooling picks it up based on references, the only other thing to do is check the code itself to see if the fix is there. When you instead merge forward, even if the ticket comments are wrong or not there, you can literally follow the branches from the PR/commits and see every release it got into.
- brandmeyer 7y ago
  > Unless someone manually comments about it or your tooling picks it up based on references. I don't find this to be overly burdensome on the tooling. If the ticket-tracking system can't automate traceability between git commits and tickets, then it isn't well-suited to git-based software development. We use the following policy: - A bugfix commit must fix the bug, the whole bug, and nothing but the bug. If that seems impractical for the task at hand, make it practical by breaking up the bug's ticket into smaller elements. - Bugfix commits always cite the bug tracking system's ticket number. - The bug tracking system observes the git tree and maintains its own linkage to it. - When cherry-picking the bugfix to other affected branches, pass the `-x` argument to `git cherry-pick`. That's it. The (cherry-picked from) comment helps out when just viewing the git history on its own. And the bug tracking system lets you quickly see all of the commits and pull requests that referred to the bug.

Legion 7y ago

Trunk based using short lived feature branches is the only thing I've used that has made any sort of sense in terms of value vs. complexity.

bosswipe 7y ago

TBD is fine for web apps, but not for software that you have to maintain multiple versions in the wild at the same time or when the release cycle takes several weeks.

wikibob 7y ago
So...shouldn't the focus be fixing the fact that release cycles take several weeks? This is well researched and discussed in Nicole Forsgren's book: Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339 https://www.amazon.com/Accelerate-Software-Performing-Techno...
- brandmeyer 7y ago
  Sometimes long test cycles are just the nature of the business, especially in hardware-software co-development, and especially in high-reliability development. Nobody will believe that running software tests on a workstation or server somewhere counts for release readiness if it gets deployed to a wind turbine, robot, or megawatt UPS. The software team's automated tests indicate that the software is ready to start an expensive physical testing cycle, not that its ready to go to the field.
lilbobbytables 7y ago
That isn't true at all. Trunk based is perfect for this because you have the clean release branches from the trunk. I've worked in large companyies very successfully using TBD and releasing quarterly to enterprise customers using our software on their systems.
- blondin 7y ago
  > I've worked in large companyies very successfully using TBD and releasing quarterly to enterprise customers using our software on their systems. care to elaborate? curious about those companies and the software you are talking about. i totally see the trunk based process work for software that doesn't need to maintain multiple versions as the original commenter said. but for multi-versioned software you can't afford to have a single trunk and let your developers have a go at it. i went and checked the repos for some of the multi-versioned software that i use that are open-source. well confirmed.

jpswade 7y ago

Absolutely agree. I think git flow makes sense to begin with however once you start to do CI/CD, you need something a bit more robust. Trunk based development gives you that. No long lived branches. No merge hell. It’s considerably better.

mixmastamyk 7y ago
I’d argue that starting simple and adding complexity only when needed is a better strategy.

mcv 7y ago

The thing I don't get about trunk-based development is: if everybody always pushes straight to master, how do you do code review? Or don't you do code review in TBD? I like having explicit pull requests where a new feature can be reviewed.

deleted 7y ago
[deleted]
adrianmsmith 7y ago
That link does say that you can use pull requests for merging the short-lived feature branches back into master. It says that, for small teams, pushing directly into master might be acceptable (presumably without code review).
- mcv 7y ago
  But how short-lived can they be? Feature development isn't necessarily short. Reviewing bits and pieces of a feature without having the whole thing together may not be very informative. And small teams may also care about code review.