4 ms·
One big benefit to fetch+rebase over pull is that you can create a backup branch before you rebase so that if you mess up the rebase too much, you can undo easi
by nordsieck 3y ago
One big benefit to fetch+rebase over pull is that you can create a backup branch before you rebase so that if you mess up the rebase too much, you can undo easily.
Another situation I've run into is that sometimes I've made a small change that's stacked on top of a lot of other branches. And if those other branches get squashed and merged, regular rebasing can be really annoying - it is often easier to cherry-pick (I use rebase --onto, but same idea) your changes onto main/master instead.
- masklinn 3y agoIf you mess up a rebase you can always rebase -—abort (/ use the reflog) to restore the pre-rebase state.
- nordsieck 3y ago> If you mess up a rebase you can always rebase -—abort (/ use the reflog) to restore the pre-rebase state. That is true. But a few times, I've finished rebasing and regretted how I handled conflicts. And once the rebase is complete, you can't abort any more. And I haven't put in the time to learn how to use reflog. Maybe this is my sign to do so.
- Jochim 3y agowhy create a backup branch instead of just pointing the rebased branch back at the original commit?
- nordsieck 3y ago> why create a backup branch instead of just pointing the rebased branch back at the original commit? I mean, isn't that what a backup branch is? How are you going to get the hash of the original commit if you don't create a branch? I suppose you could use git log or something to print the hash to the terminal, but that's just way more fragile than using git to keep track.
- seba_dos1 3y agogit already keeps track of refs for you.