Git rebase -I is not that scary

jauntywundrkind

rebase interactive is so great, such a powerful tool. it's the one clear tool that i used all the time. moving to jj, it has lots of amazing tools starting with `jj edit` to go change the past safely & conveniently, with much less pain. but i miss the direct powerful data-driven experience of seeing the timeline in a text file, and picking what to do with it. sometimes. imo every dev should work to get some competency with git rebase! it's an amazing tool. there's few other systems that give such direct control. it's top layer is, perhaps, the excel of version control?

TazeTSchnitzel

I wish there were a shorthand for x git commit --amend --reset-author --no-edit I use that one very frequently (after a fixup, of course) because I want the author date on amended commits to reflect the last time I edited them, not the first time I committed them.

code_lettuce

Big rebase fan here. I find myself using squash the most.

nixpulvis

I feel like if you're scared of rebasing, you don't actually understand git.

BobbyTables2

I also thought rebase was scary long ago. It is scary in the sense if one messes something up without realizing and then pushes to master… Besides interactive rebase, my other favorite command is “git log —-oneline origin/master..HEAD” It shows me exactly where I am…

flyingcircus3

After more than a decade of using git, I know that my comfort with rebase, and confidence that I wont make an error I can't undo, comes from knowing that I can always abort. And assuming it wasn't garbage collected, I can always get back to orphaned commits, or the commit before I rebased, as long as I keep their hashes. I can definitely look back on my less confident days as times when I wrongly assumed I was walking a tightrope where screwing up was painful and expensive, and easy to take the wrong path, and abort is the universal solvent to all of that. I do still find myself tripping up on whether the next appropriate step is to make a commit or continue the rebase, as that is dependent on if you're in a merge conflict or just editing a commit. But even when I get that wrong, and collapse two commits together, abort saves the day.

cmrdporcupine

I really love the emacs interactive rebase mode, which comes up by default when you have EDITOR=emacs and do rebase -i. I know you can do this from within magit as well but I've never gotten into that workflow.

trescenzi

Another git command I love using is `git add -p`. I always want to commit in chunks as I go but sometimes I wait to long or realize later I could have broken it up. Being able to select only pieces of a file to add to a specific commit is so great. Editing the chunks manually can be a bit intimidating but since it only stages the change you can always restore the file and try again if the diff doesn't look right after the add.

koolba

That “-I” really needs to be lowercase.

newsicanuse

I use rebase so much but it only feels comfortable because I follow a workflow while rebasing.

dionian

sometimes i wish mercurial won, if nothing else for the fact that i found its ux to be more enjoyable. I respect and use git, but never got comfortable with merging. im thankful AI can automate it for me now

maxloh

I found the VS Code GitLens extension to be a good abstraction for interactive rebase. It provides a drag-and-drop UI with a dropdown to select actions applied to each commit. That is much easier than editing a text file. Here's a GIF I found with Google: https://yogwang.site/2025/cursor-vscode-gitlens-rebase-edito...

KoleSeise1277

I still make a throwaway branch before a complicated rebase. It costs nothing and turns the whole operation into a low-stakes edit instead of a leap of faith.

jordanboxer

git commit —fixup=<commit-id> git rebase -i —autosquash This is my best friend

ed_mercer

I cannot recall the last time I committed manually, let alone rebase manually. An agent can do it for you faster and without making mistakes.

fleventynine

I typically work with commit chains of at least 5 commits in various states of code review, so I spend at least 60% of my development time editing an old commit in the middle of a rebase -i.

vivzkestrel

- i often go back like 5 commits and make changes like this - git rebase -i <commit-hash>^ - select edit - git reset --soft HEAD~ - make some changes - git add . && git commit -m "changes" - git rebase --continue - Am I using git rebase wrong?

pajko

Why isn't the 'edit' command mentioned? It's one of the most useful features. It can be used for splitting commits, for example. Mark the commit you want to split to be edited. The commit replay is going to stop after that commit. Now: git reset HEAD^1 (NO --hard!) git commit --patch ... git rebase --continue You want to add some pending changes to the previous commit? No problem: git commit --patch --amend ... You want to move the pending changes to future commits? git stash git rebase --continue git stash pop

bob1029

Rebase is scary if you are conflicting on many items. I have a simple rule where if the rebase cannot be solved within a few commit rewrites that I will restart the branch from latest master. If you are suffering from really difficult rebase scenarios, it's likely that the senior developers are more at fault than the junior developers. The way you organize work over the codebase has the biggest impact on how things would conflict. If nothing ever does, rebasing is a trivial operation.

conradludgate

I should publish it at some point (it's just a simple bash script), but I made a convenient alias `git bisect-rebase` which helps catch up very old branches. It isn't particularly fast, but it uses bisect to find the first commit on the target branch that conflicts with your branch, then let's you rebase to that commit. You then repeat the process until you are caught up. The idea is that solving one conflict many times is usually quite easy, especially if you know the conflicting commit messages, but solving many conflicts in one go is not so easy. This was inspired by me rebasing a 6 month old branch which refactored a file that happened to have many edits in between.