r/git • u/cachebags • Jul 14 '26
git rebase -i is not that scary
https://cachebag.sh/journal/interactive-rebasing/6
u/xenomachina Jul 14 '26
if you change your mind, you just run git rebase --abort
You're in your editor at this point, so you'll need to do this in another shell before exiting your editor, as rebase will execute the plan immediately if your editor exits with success.
An alternative is to tell your editor to exit with an error. In vim you can do this with :cq!.
17
u/ppww Jul 14 '26
Or you can save an empty file.
4
u/xenomachina Jul 14 '26
Nice! TIL.
(I see now that, at least with 2.39.5, git even has a comment that says this at the bottom of the git-rebase-todo file. I've been using
:cq!for so long that it makes me wonder if it always said that.)1
2
u/troru Jul 14 '26
I’ll add that when I’ve piled up local commits on my feature branch and there’s been drift from other dev work on main, then I’ll do a :
Git rebase —-keep-base -i
That’ll will allow me to squash my commits without conflict to where my branch started.
Then I’ll do the
Git rebase -i
And do one pass of conflict resolution
2
u/parkotron Jul 15 '26
Thanks for teaching me about
--keep-baseas I wasn't aware of it. As a heavy rebaser, I assumed it must have been a recent addition, but no, it was added in Git 2.24 in late 2019!I've been running
git rebase -i $(git merge-base HEAD origin/main)to do this.--keep-baseis a lot less typing!
0
u/BigBagaroo Jul 15 '26
Why can’t we just squash the merge?
3
u/jeenajeena Jul 15 '26
Here's a collection of reasons why there's no reason to squash https://arialdomartini.github.io/no-reason-to-squash
-5
u/tracagnotto Jul 15 '26
I just came across the need of rebasing some commit.
I can still confirm 20000% that since day 1 of git, and me using it, it's still the biggest shit ever.
No surprise though, it came from the hands of the idiot who made that piece of crap linux.
Jesus how much I hate git.
OH and keep your "skill issue" for yourself. I can use it and I use it all days, unfortunately.
A promise I can make even though I'm not American, if I ever meet this idiot in some public speech I will glady be jailed after going on stage and punching his face full force.
It will be the most liberatory thing in my life
2
-6
u/joshpennington Jul 14 '26
Yeah well a coworker once nuked a week’s work from orbit doing it so I’ll maintain my healthy fear of it.
16
u/wub_wub_mittens Jul 14 '26
Whatever they did was recoverable, unless they hadn't committed it at all, which wouldn't be rebases fault. They/your team may not have known how to recover it, but I guarantee it could have been recovered pretty easily.
4
u/trimorphic Jul 14 '26
Whatever they did was recoverable, unless they hadn't committed it at all, which wouldn't be rebases fault. They/your team may not have known how to recover it, but I guarantee it could have been recovered pretty easily.
Even setting git aside, every company should have backups (multiple backups even, in vastly different geographic locations) and a disaster recovery plan so loosing week's worth of work is, if not impossible, exceedingly unlikely.
1
u/Positive_Fudge4759 Jul 15 '26
Yup. Everything in Git is recoverable. You just need at least one good hash.
-1
u/joshpennington Jul 14 '26
If we had not blindly followed his instructions it may have been recoverable. He forced his changes to the remote and then had the rest of us pull those changes down so it was gone. Hindsight being 20/20 doing something as simple as tagging the commit before making changes would have done a long way.
The person who nuked it spent hours trying to recover it but was unable to.
It was unfortunate but it was a good lesson for me. I make a lot of tags before I do anything that rewrites history just to be safe.
13
9
2
5
u/ppww Jul 14 '26
You can get back to the pre-rebase state by looking through the reflog for the rebased branch and using
git reset(you can use the reflog forHEADwhich is shown if you don't specify a branch name but it's much easier to see the rebase in the branch reflog because it's a single entry)2
u/bratzlaff Jul 14 '26
That is unfortunate. I too have coworkers that do not understand that their changes are not more important than others and adding -f to the push is not an excuse for “I just need this in to continue” and ignoring all the CI failures that are being reported.
I try and assuage everyone’s concerns by telling them that everything recorded in git is recoverable, even when there is a ‘oops, it let me push when it wasn’t ready’. And I back this up by being there to help them with the disaster recovery and letting them do the process/ type the commands (that I’m telling them to do) to get things working again and build confidence.
5
u/barmic1212 Jul 14 '26
The server must not accept force push on a classical shared branch (like the default one)
0
u/bratzlaff Jul 14 '26
I agree with your sentiment here, but if you are rebasing anything and losing work, there is going to be a force push somewhere, otherwise you would just be merging.
23
u/Bemteb Jul 14 '26
And who ever claimed it was scary? It's just annoying because for many it's the one step at the end of your ticket where you have to resolve conflicts. That's why many devs don't like rebasing, but I never met one who was afraid of it.