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.
> 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<p>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.<p>Maybe I just misunderstand what "long-lived" means in this context.
<a href="https://trunkbaseddevelopment.com" rel="nofollow noreferrer">https://trunkbaseddevelopment.com</a> is probably a good resource to look at. Long lived feature branches have <i>never</i> worked well in my experience.
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.<p>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.
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.
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.
TLDR<p>Trunk-based development = putting unfinished work in the team's shared branch.<p>Feature-branches = finishing your work first.<p>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.