3 ms·
I don't get why people like rebasing as an alternative to merging. It works kind of OK for small histories, but if you do something slightly complex or your his
by noamsml 13y ago
I don't get why people like rebasing as an alternative to merging. It works kind of OK for small histories, but if you do something slightly complex or your history is not meticulous, rebasing becomes extremly tedious. The worse example is a conflict in a reverted commit. A merge will flatten the diff and skip the reverted commit entirely, while a rebase will require you to fix the conflict twice. And while a merge is tedious to revert, it is possible. Good luck saving a branch ravaged by a bad rebase.
- lotyrin 13y ago> Good luck saving a branch ravaged by a bad rebase. Git rebase --abort before you've finished screwing up, or if it's too late, use the reflog and reset back to before you started.
- __--__ 13y agoIf you're working on a large team, this becomes a more pernicious problem. I've seen rebases change histories to the point that whole branches become incompatible with master. When you have 15 people all merging branches into master, complete with binary files, conflicts are frequent and often involve files you personally didn't change. People resolve the conflicts to the best of their ability, but they have no idea why certain things conflict and bugging your co-workers every time you merge a branch is unrealistic. So we guess and whole features get wiped off the face of the repository. My team now has a merge only policy and it's reduced the number of conflicts and borked merges.