3 ms·
"Here’s the thing: the worst case scenario for a rebase gone wrong is that you delete your local clone and start over. That’s it. Your remote fork still exists.
by just6979 9mo ago
"Here’s the thing: the worst case scenario for a rebase gone wrong is that you delete your local clone and start over. That’s it. Your remote fork still exists. The main repository still exists."
You forgot "your backup local branch still exists". Branching in git is effectively free, just duplicate the one you're worried about rebasing: if the rebase goes wonky enough that you can't cleanly abort it, you just start over on the backup branch, making another duplicate and trying again.
It also gives you a nice reference to compare the results of the rebase with your original intentions for the code.
- just6979 9mo agoOh, I guess you kinda did address is, with pushing to your remote fork. But why push? Rebasing a branch doesn't affect any other branches, so a local backup branch is just as safe as a branch on the remote fork. You shouldn't ever need to nuke your clone unless you're trying something silly like rebasing main (without a local backup branch!), or doing more than just rebasing, like messing with the reflog. Also, I don't think it's rebasing that scares people, it's the force push that scares people. There is so much out there saying "never force push or all the trees in a 500 mile radius will spontaneously combust" without explaining the nuances of concurrent work on shared branches vs a personal fork used for making contributions upstream, nor the "safety" of force-with-lease. For the latter (fork for contrib), just yolo it: you're the only one working on your fork!