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.

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

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 feel like if you're scared of rebasing, you don't actually understand git.

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

That “-I” really needs to be lowercase.

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.

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

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

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…

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

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

This is my best friend

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

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.

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.

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

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 cannot recall the last time I committed manually, let alone rebase manually. An agent can do it for you faster and without making mistakes.