3 ms·
My belief is that it's long-lived branches that are the problem, since trying to keep diverging code-bases in synch is a huge source of pain. Switching to bran
by jes5199 9y ago
My belief is that it's long-lived branches that are the problem, since trying to keep diverging code-bases in synch is a huge source of pain. Switching to branchless development is probably an overreaction, though.
- bonesss 9y agoI'm no proponent of long-lived branches, as such, but isn't holding branches like that in synch that exactly what `git rebase` is for? It's all product specific, naturally, but I've had occasions where isolated multi-month branches made sense... They got rebased before merging, though, so all refactoring and merging pain was taken on the side of the divergent branch and the post-squash post-merge history was really clean. Even major code-base wide refactorings should be trivial to incorporate as long as you're not working at distinct cross-purposes with other people (which is a planning issue). It sounds like encouraging regular rebasing of diverging branches would be the solution here.
- jes5199 9y agoYeah, but that's work that people have to remember to keep doing, and if they fall behind, the pain gets worse and worse when they do finally have to merge. Some teams seem to do fine with this, but I've seen it go pretty badly, too.