|
I use git rebase all of the time.
We rebase all features onto develop.
Develop is then merged --ff-only into stage/release, etc.
Which is then merged --ff-only into main/master, and then tagged. I use squash less, as it can be helpful for blame of course, so rebase with minimal squash (like, squash that typo fix). The article makes it sound like a 'rebase' workflow is so complex, and time consuming. Poppycock. it's easy, and force pushing a branch cause practically zero issues for developers. If I have to rebase develop, for example, and then force push it, then remote users only have to do this:
git checkout develop
git reset --hard origin/develop Since a user would never have any local changes in develop, it would never be an issue. The "fanaticism" about and against rebasing is overblown in my opinion.
Oh, and the "time wasted" dealing with merge issues.. same, exactly the same in fact. Granted, I don't go around rebasing everything all of the time, but a developer working on a feature just rebases to develop before they submit a PR. Sure, if there are multiple PR's then they also need a rebase merge, but since nobody would "continue" working on a feature once it is submitted, this isn't an issue. Oh, and IF they did, well, again, they can just pull develop and rebase their feature. Now, what I don't do is have multiple developers on a single feature branch. If my team was much larger, and that was a "normal process" then, it may well make rebasing more of an issue.. |
Luckily, now our worse communicator is also our most competent dev, but I've been in teams where learning basic git would be a month long challenge for half the people, and for half of those (two people, really, we were 9) communicating their difficulties, or worse, their mistakes was impossible.