5 ms·
> Those have release branches. Some Trunk Based Development teams do "branch for release" https://trunkbaseddevelopment.com/branch-for-release/ https://trunkba
by paul_h 10y ago
> Those have release branches.
Some Trunk Based Development teams do "branch for release" https://trunkbaseddevelopment.com/branch-for-release/ https://trunkbaseddevelopment.com/branch-for-release/ and some do "release from trunk" https://trunkbaseddevelopment.com/release-from-trunk/ https://trunkbaseddevelopment.com/release-from-trunk/
Google gave numbers themselves - 95% of their devs are in one big trunk (formerly perforce, but re-written in-house in 2012). It's true that the open source facing teams are outside that, and have processes that are less lock-step than what they do in-house.
Android - Samsung, on each release (maybe not anymore), used to check all the composite parts of Android into one big trunk for themselves. Back into their Perforce.
> If you're making Google Chrome, you don't.
There's nothing stopping the Chrome team from doing Trunk Based Development on Github, and accepting unsolicited pull requests like any other team.
- paulddraper 10y agoYou can have long lived release branches in "trunk-based development"?!? In that case, I guess I haven't ever seen a branching strategy that wasn't "trunk-based." What would that even be?
- qwer 10y agoAnything involving long-lived feature branches especially ones with multiple collaborators, eg git-flow.
- paulddraper 10y agoIf I understand git-flow correctly, it's a trunk (develop) with a release branch (master).
- paul_h 10y agoWe wrote about that: https://trunkbaseddevelopment.com/alternative-branching-models/#gitflow-and-similar https://trunkbaseddevelopment.com/alternative-branching-mode...
- paulddraper 10y agoGuess I should have RTFM. Well written.
- paul_h 10y agoIt depends on whether the branch ever merges back to the trunk or not.