2 ms·
I'm fine with both, I've seen both trunk-based (with SVN) and branch-based (with Git) models work. Due to git's 'multiple histories' it's quickly becoming a me
by flohofwoe 3y ago
I'm fine with both, I've seen both trunk-based (with SVN) and branch-based (with Git) models work.
Due to git's 'multiple histories' it's quickly becoming a mess when many people are on the same branch, that's why I prefer to use a branch-model in git where only one person is on a short-lived branch, and a team uses PRs/MRs into a common target branch to create a clean, shared, linear history. This target branch doesn't have to be the main branch, but can itself be a (bigger) feature branch which then is eventually merged into the main branch (key is to not diverge too much from the main branch though, so that merging back doesn't become a hassle).
- barrkel 3y agoSubversion sucked for a lot of reasons. It had no good integration with code review (though there are some tools that can do it now). It didn't have a good way of doing a three-way merge, necessary for rebasing a change or porting it across branches (e.g. release branches for shrinkwrap patch updates, which was the style at the time), without additional tooling. I wouldn't model how trunk-based development works based on experience with SVN.
- flohofwoe 3y agoTortoiseSVN+WinDiff took a lot of pain out of SVN merging, but in general with the trunk-based approach you'd usually only create 'dead-end' branches off the trunk which would not be merged back (for instance one maintenance branch per feature release to enable further patch-releases without holding up work on the next feature release already happening on trunk), in this case, only bugfixes would be cherry-picked in either direction (e.g. the most important rule for SVN was: avoid complex merge scenarios in the first place).