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 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