Git rebase -i is not that scary (cachebag.sh)

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?

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.

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

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

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…

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.

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.

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.

That “-I” really needs to be lowercase.

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

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

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

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.

  git commit —fixup=<commit-id> 
  git rebase -i —autosquash

This is my best friend

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.

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.

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

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

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.

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.

I’ve used Git for 20 years now and wrote a book about it.

The biggest mistake most sources make when teaching about history rewriting is omitting these two lessons first:

- it’s easy to lose uncommitted data in Git and hard to lose committed data

- given this, learn how to use ‘git reflog’ to see what you’ve done and how to undo/redo it (as this post recommends but, even then, a little too late)

If you just get in the habit of constant committing and checking reflog: you’ll never lose data.

(Related lesson from my 10 years employed by GitHub: they almost never do the git gc you’d expect to remove commits so once you push a commit: it’s likely there forever and identifiable by that same hash from anywhere in the fork network. This can be bad/scary so be aware).

Adopting interactive rebasing along with curating my commits for the benefit of the reviewer has been the best upgrade I've made to my git usage in probably the last five years.

I used to always have deep dread when having to use git but then I found [0]

[0] https://ohshitgit.com/

A young dev who's still ambitious, gotta love it.

One additional thing I would mention ist that: When resolving conflicts never try to solve them for the final result. Consider each conflict without considering how the code will change in a later commit. I’ve seen people die a painful rebase death because of this.