Trunk-based development vs. long-lived feature branches

https://ardalis.com/trunk-based-development-vs-long-lived-feature-branches/

by freedude • 3 years ago

22 45 3 years ago

freedude• 3 years ago

Full Title: "Trunk-Based Development vs. Long-Lived Feature Branches: Which One is Right for Your Software Team?"

modeless• 3 years ago

Was this article written by ChatGPT? It's the same wishy-washy style. Ignore the article, the actual answer is always trunk-based development. Long lived feature branches will always come back to bite you.

bastardoperator• 3 years ago

Agreed. If you like pain, long lived branches are key.

tsak• 3 years ago

You can have both. Some bigger features can take a while to complete and you can keep the pain to a minimum be rebasing your feature branch on the latest mainline branch often.

rqtwteye2• 3 years ago

Our testers work on a branch often for half a year or more. I always “love” helping them merge their stuff.

hinkley12• 3 years ago

If you want to foment resentment and infighting, few things work as well as long lived branches.

mvdtnz3• 3 years ago

100% yes it's written by ChatGPT. Just look at the "practical example", it's about as shallow as a puddle.

da39a3ee2• 3 years ago

It's not about long-lived branches. It's about defining a solvable problem and having the discipline to finish your work on that problem before merging.

mqus• 3 years ago

Branching strategies like Git Flow popularized this approach, and it's extremely common in open source software, where typically community contributors do not have mainline access, and so much create branches and make pull requests

No? I thought Git flow had feature branches, but those were not supposed to live long, just like in every case. Long-lived feature branches should get long-lived by necessity (someone working a long time on a feature that can't or shouldn't be cut down), not by choice. In open source, feature branches are long-lived because either they don't get reviewed or the contributor lost interest/does not have the time to finish it. They didn't choose to make those branches long-lived.

Maybe I just misunderstand what "long-lived" means in this context.

mvdtnz3• 3 years ago

I have found that I need to be specific when I talk to developers about "long lived" branches. In the past I have questioned teams about why they are developing in long-lived branches and they defensively claim they aren't - their branches only last two or three weeks. In my view that's a very long-lived branch.

throwbadubadu• 3 years ago

Lol, I feel that is the average ticket/branch time in my >50 safety critical project, time is relative ;)

bunderbunder2• 3 years ago

Oftentimes the argument is made that even work that can't be broken down should still be frequently integrated, and instead you use feature flags to control whether it's active in production.

I haven't had enough experience working that way to say whether it's better. But I will say this: the root cause of many of the nastiest regression defects I've had to deal with was surprising outcomes when merging a long-lived feature branch into code that had had a few weeks of time to accumulate behavioral changes since the feature branch's creation.

miked852• 3 years ago

https://trunkbaseddevelopment.com is probably a good resource to look at. Long lived feature branches have never worked well in my experience.

jeffbee• 3 years ago

Well, the OP clearly lays out the case when long-lived feature branches are better. They are great for enabling you to do things you should not do. They are good for landing huge, un-reviewable changes, or working in code bases with no tests.

Every argument I have ever seen in favor of feature branch development, and frankly 90% of the arguments in favor of git, take the form of "It makes it easier for me to [[terrible idea]]."

miked852• 3 years ago

Yeah, I'm not saying there is never a need for a long-lived feature branch, there are use cases. I would say it's fairly rare in practice for it to be preferable, at least in my experience.

bonzini• 3 years ago

What terrible ideas?

hinkley12• 3 years ago

And here's the thing about refactoring:

If you know what the fuck you're doing, you can sneak new features in just as easily as with a feature branch. Maybe even moreso.

So if you are working for an organization that is actively attempting to self-destruct, to the point where you feel like there needs to be a conspiracy to keep the wheels on, even then feature branches don't help. And in fact they make things worse because your coworkers who defect are busy breaking things on their feature branches, undoing all of your carefully laid plans to unfuck the code and thereby the organization.

Learn to refactor code that has unnecessary constraints into code that doesn't. Then those features you can't get out of the backlog become 3 weeks instead of 3 months, and you can actually work on them, because you've already made the change easy.

hinkley12• 3 years ago

Once someone pointed out to me that these dynamics are the bargaining phase of loss, I couldn't unsee it. All this rationalizing is people not wanting to admit that merging is hard (most of the people who really want feature branches are also the people I categorically and empirically cannot trust to do merges properly.) They are trying to avoid dealing with their problem by making it everybody's problem.

willsmith72• 3 years ago

The long-lived feature branch "pros" made me shiver. I hope I never work in an environment like that again

senfiaj3• 3 years ago

Yap, the merge issue is one of the worst nightmares for developers.

hinkley12• 3 years ago

If you don't master your fear, then your fear will master you. - The Sphinx

hinkley12• 3 years ago

I don't even like the 4 business day feature branches we have. When we were rapidly developing we saw all sorts of merge problems. It only works now because the commit rate has dropped off, and the chances of merge problems are somewhere between quadratic and factorial.

da39a3ee2• 3 years ago

TLDR

Trunk-based development = putting unfinished work in the team's shared branch.

Feature-branches = finishing your work first.

Anyone who's ever completed a complex PR knows how much plans change over the course of the work. Obviously those immature stages shouldn't be shared with the team, let alone be in main, whether behind feature flags or not.

hinkley12• 3 years ago

The main observation of CI/CD is that problems don't get better by avoiding them. If something sucks, you either need to figure out how to stop doing it ever again, or grow callouses.

The draw of feature branches is the same draw as quarterly or yearly releases: People don't know how to decompose problems into stand-alone subproblems that they can tick off one at a time. The solution is the same here. Don't avoid decomposing problems. Do it every week until you figure it out.

sebazzz2• 3 years ago

Another practical issue with trunk-based development is that most code review tools only support reviewing complete branches and don't support reviewing a bunch of individual commits. Well, Jetbrains Upsource supports it, but unfortunately that has been canned by Jetbrains.

However, trunk-based development allows high-paced development of applications, and testers can easily review the combined result on a test environment.

gettodachoppa• 3 years ago

Why would you want to review individual commits when the same lines can change from one commit to another? It seems like more work. Personally I want to see the final list of changes when I review, and not waste my time with intermediate stuff.

I know some people are diligent about using rebase to present a clean commit history, but that's rare in practice in my experience. And it's incompatible with devs who aren't skilled at git.

senfiaj3• 3 years ago

Maybe there is a middle ground, such as creating "v2" (or whatsoever) folder with the newest changes where you can easily switch between the old and the new functionality.

zabil• 3 years ago

You can enjoy the benefits of both approaches by adopting trunk-based releases. In our experience, we make small pull requests (like short lived feature branches) on GitHub, each focusing on a complete feature or a segment of it.

GitHub Actions automatically test these pull requests and create temporary environments for further testing. If all tests pass, the code enters the merge queue and gets released as soon as it's merged into the main branch. We release every commit, keeping the main branch's release log tidy. We also use a mono-repo and implement caching, ensuring that only the modified code gets packaged and released.

ulizzle• 3 years ago

Long lived means gigantic. It’s not a bad idea if you have a decent test suite. But if you don’t have one it’s too risky and can easily get out of control.

Trunk-based development vs. long-lived feature branches

Related Stories