Rebasing is not dangerous. You can always go back if something is not to your liking.
You don’t rebase shared history, you use rebases to craft a clean, quality commit history for your own branches before merging. If everyone does this, then squashing is unnecessary, because garbage commits don’t exist. It is the far superior way of doing things if you actually care about having good commits.
Keeping a quality history rather than squashing also makes many other git tools much better, such as git blame, git revert, git bisect, and so on.
That doesn’t make sense. There’s a world between “garbage commit” and “fancy new feature” and most of it is irrelevant to anything.
I don’t want git bisect to make me check if “run clang-format” broke anything. I don’t want to revert a feature but leave in unit tests that will fail (or worse, the opposite). I don’t care when git blame tells me “rename X to Y”, I want to see the context that motivated this change.
Squashed commits are atomic, built and tested. Anything in between is whatever reviewers let slip in. It’s easier to check a MR description is well written than 5 commit messages (that might get rebased without you noticing)
You’re right that there is a risk, that rebasing introduces compile errors or even subtle breakages. The thing is, version control works best, if you keep the number of different versions to a minimum. That means merging back as soon as possible. And rebases simultaneously help with that, but also definitely work best when doing that.
There may be reasons why you cannot merge back quickly, typically organizational reasons why your devs can’t establish close-knit communication to avoid conflicts that way, or just not enough automation in testing. In that case, merges may be the right choice.
But I will always encourage folks to merge back as soon as possible, and if you can bring down the lifetime of feature branches (or ideally eliminate them entirely), then rebases are unlikely to introduces unintended changes and speed you up quite a bit.
Rebasing is dangerous if you rebase shared history. If you rebase a local branch, you have to be aware of how much of that local branch you may already have shared.
On top of that, if you’ve got a lot of commits you’re rebasing in a merge conflict that can become extremely repetitive.
So ideally, you only rebase single commits that you haven’t pushed yet. As long as you do that: always pull main and rebase on top of that before you push single commits, rebasing is fine. But the more you deviate from that, the riskier it becomes.
You don’t share feature branches. So you always know precisely what is shared history: the commit you branched from.
The workflow is branch from shared history, rebase your branch as many times as necessary during development to craft a quality history, then merge back.
I rebase dozens of times a day and have never had a single issue with it.
If you’re bothered by repetitive merge conflicts (which, in my experience, are quite rare if you’re doing things correctly), that’s what git rerere is for.
Rebasing is for crafting a quality history of your own commits (or getting your branch up to date with the trunk). Merging is for integrating your commits with the shared history.
Rebasing is not dangerous. You can always go back if something is not to your liking.
You don’t rebase shared history, you use rebases to craft a clean, quality commit history for your own branches before merging. If everyone does this, then squashing is unnecessary, because garbage commits don’t exist. It is the far superior way of doing things if you actually care about having good commits.
Keeping a quality history rather than squashing also makes many other git tools much better, such as
git blame,git revert,git bisect, and so on.That doesn’t make sense. There’s a world between “garbage commit” and “fancy new feature” and most of it is irrelevant to anything.
I don’t want git bisect to make me check if “run clang-format” broke anything. I don’t want to revert a feature but leave in unit tests that will fail (or worse, the opposite). I don’t care when git blame tells me “rename X to Y”, I want to see the context that motivated this change.
Squashed commits are atomic, built and tested. Anything in between is whatever reviewers let slip in. It’s easier to check a MR description is well written than 5 commit messages (that might get rebased without you noticing)
You’re right that there is a risk, that rebasing introduces compile errors or even subtle breakages. The thing is, version control works best, if you keep the number of different versions to a minimum. That means merging back as soon as possible. And rebases simultaneously help with that, but also definitely work best when doing that.
There may be reasons why you cannot merge back quickly, typically organizational reasons why your devs can’t establish close-knit communication to avoid conflicts that way, or just not enough automation in testing. In that case, merges may be the right choice.
But I will always encourage folks to merge back as soon as possible, and if you can bring down the lifetime of feature branches (or ideally eliminate them entirely), then rebases are unlikely to introduces unintended changes and speed you up quite a bit.
Rebasing is dangerous if you rebase shared history. If you rebase a local branch, you have to be aware of how much of that local branch you may already have shared.
On top of that, if you’ve got a lot of commits you’re rebasing in a merge conflict that can become extremely repetitive.
So ideally, you only rebase single commits that you haven’t pushed yet. As long as you do that: always pull main and rebase on top of that before you push single commits, rebasing is fine. But the more you deviate from that, the riskier it becomes.
You don’t share feature branches. So you always know precisely what is shared history: the commit you branched from.
The workflow is branch from shared history, rebase your branch as many times as necessary during development to craft a quality history, then merge back.
I rebase dozens of times a day and have never had a single issue with it.
If you’re bothered by repetitive merge conflicts (which, in my experience, are quite rare if you’re doing things correctly), that’s what git rerere is for.
Rebasing is for crafting a quality history of your own commits (or getting your branch up to date with the trunk). Merging is for integrating your commits with the shared history.
I often end up squashing all my changes into a single commit, rebase it, and then reset HEAD^ to rewrite some commit history.
Brute force, but better than resolving 10 conflicts in the same file over and over