In my experience, working primarily based on integration branches, as opposed to working on master and cherry-picking back into integration branches, provides some short term benefits but is net negative in the long term.
1. People stop caring about master. Then master breaks and nobody fixes it. This is a problem if not _everyone_ is on the integration branch, e.g. if there is a single small team working on a feature for the next+1 release that needs master: they can't fix all the breakage from all the other teams, and they can't get the other teams invested in not breaking master. This ruins that teams productivity, which makes development of larger scale features much more costly. Even if no team needs master, leaving master broken and coming back to it later makes those fixes more costly.
2. Regressions: people mark bugs closed as soon as it is fixed in the integration branch. Then the fix never makes it into master, and you get regressions on the next+1 release. Automatic forward merge (always immediately and automatically merge release/n to release/n+1 [...] to master) as supported by e.g. Bitbucket can help with this, at the cost of the occasional merge conflict(s) and less control in case some fixes actually should not go into a specific intermediate release.
Release integration branches bring the behaviour of big releases. The bigger the release, the bigger the risk, therefore the less you want to do it.
With release integration branches you not only integrate for release (which the bigger the release, the more difficult it is), but also now you have to integrate back from release into main (because bug fixes and what not). The longer that you have had that integration branch, the more likely that you have move forward the main code and the more difficult then becomes the back integration. So you end duplicating the effort.
I’ve personally never worked on one much, but you have to keep (at least) two branches active for a release. Main development would happen on a shared feature branch (to be larger merged), but you also need to keep master/main updated with bug fixes and other changes that aren’t release gated.
More around versioning itself, but having a single big merge is a single high risk point. Releasing everything all at once is more likely to have larger and more severe bugs than many small releases, even if you gate the deployed releases behind feature flags.
Nothing, but you have to do it right. If you look at Linux, you'll notice there is no central git server with a master branch that people push to. The most stable development branch (in addition to the LTS branches), is whatever Linus Torvalds has chosen to merge to his personal master branch. He cuts a new release from there roughly every two months. Whatever is on that branch is the next version of Linux.
That's integration branches done properly. Linux releases are cut from that branch. Literally everything else is an integration branch and it won't get pulled (you don't get to push) by Linus Torvalds until it merges cleanly and passes all the scrutiny that he and his people apply to incoming changes.
Very few companies work like this of course. So instead you get people working on their pet branches and ignoring upstream changes. It's stupid. All you are doing is deferring integration work. Integration work scales exponentially relative tot he amount of change. So, the longer you wait, the worse it gets. The flip side is that having branches means you can distribute the integration work across those branches. And if each branch only has a small delta relative to the main branch, the collective integration work load decreases. The way you keep the delta small is by pulling upstream frequently and staying on top of the upstream changes. If you fall behind, it becomes a problem. And it's exclusively your problem.
Linux doesn't have issues with integration work on the main branch: you are either compatible with upstream and ready to merge or you won't get pulled in. It's that simple. That's why Linus Torvalds can release a stable release regular as clock work. You don't get to stamp your feet and whine about how important your branch is. You do the integration work before your changes are pulled in and it's exclusively your problem to make that happen. So people, integrate upstream changes often and Linus keeps unstable changes out of upstream. They front load all the integration work before anyone even talks to Linus Torvalds. Done right, this scales to an ecosystem with thousands of contributors from a multitude of companies across the globe. It works by distributing the integration work across the ecosystem.
This can work in large companies too. But you have to do it properly and with intent. Pull requests are pretty popular for a good reason: they work the same way. If you have to have long lived branches, somebody needs to worry about those staying in sync with upstream. If that doesn't happen, you have a problem waiting to happen.
It’s a giant pita to manage those if you have many in-flight on a reasonably complex codebase (lets say 500k-1M loc). If you’re a saas you’re probably not getting many of the benefits either
You can save some time by getting rid of them. It forces a team quite strongly to a method of working that is a LOT faster but many devs find the relentless pace quite challenging. There’s an easy way to tell the approaches apart - if you have 5 devs does your team have 4-10 items in flight usually? if so that’s a team on the slow and steady path. if you have a team of 5 and you all work on the same thing at the same time then the pace can be really quite impressive.
> if you have 5 devs does your team have 4-10 items in flight usually? if so that’s a team on the slow and steady path. if you have a team of 5 and you all work on the same thing at the same time then the pace can be really quite impressive.
This sounds like a good heuristic. Can you expand on that?
Fundamentally when you dig deep enough in this line of reasoning it’s calling out hubris. It’s recognising that developers can be pretty adept at blaming everything else but their own actions.
Ever worked in a “spinning plates” kinda team? The kinda team who can tell you “Our release process takes 3 hours, but it’s not our fault, we’ve learned to be helpless because we feed into a dept level build and is for a good reason and and and …”. Faced with this the spinning plates mentality uses the downtime gifted by the broken process to go start up some more work in progress. Gotta keep everyone busy after all! What are you gonna do on morning stand up if you can’t rhyme off 3 or 4 inconsequential updates that none of your colleagues are paying attention to because the truth is what you worked on wasn’t important to them, just as most of their tasks weren’t important to you. Maybe there’s one dev carrying the whole team but everyone already knows what that person’s working on so stand up becomes something just like listening to the news - it can be entertaining but it doesn’t mean anything to the rest of your morning. If an asteroid decided to crash down and block the I-123 to work this morning you’d already know before you turned on the TV and so it is for standup in this kind of team.
Contrast with a team working on one thing together - they’re not accepting a 3 hour release process. They’re certainly not picking up another task just because they’re blocked. They’re swarming on resolving that messed up release process that they don’t control. You can bet that what they see as their top priority, the release process, is not management or any other responsible team’s top priority. This is really where the two approaches differ, the coherent team are now focused on figuring out how to move forward. Not picking up more work to stuff into a release pipeline that’s unduly restricted a little further downstream towards prod.
Release branches have a place where you are releasing software and supporting multiple different release versions for different clients, because you need to be able to bug-fix older versions and merge fixes forward rather than just fix current and re-release into your own system.
If you only ever give a shit about ‘latest’ then you don’t need to bother with them. IMHO.
