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

I use interactive rebases frequently, but even then, I think conflicts happening during a rebase are often somewhat cryptic.

I think I know what happens in principle (each step of a rebase does a merge of the commit from the list with the last rebased commit) but it's still often hard to understand which side of the conflict represents what, and what would be the desired outcome for that step in the history. So I tend to abort the rebase when I get a conflict and see if I can plan it differently so I can get it through without conflicts.

What I found good to know is that only actions that modify the actual changes in the history - reordering, deleting or editing commits - can cause conflicts. The other actions - reword, fixup or squash - only modify how the changes are grouped into commits and cannot cause conflicts.

So I usually do an interactive rebase in several passes: First a rebase that only reorders commits (or rarely does deletes or edits) and where I deal with the resulting conflicts, then a second pass for fixup or squash operations that can then use the reordered history from the first pass.

Rewords are both harmless and don't require any particular ordering, so can be done in any pass.

I tend to use this quite a bit to squash working branch commits before a rebase... though I'll also tend to use commit --amend locally as well. I try not to have long-lived branches, but when I do, I squash and rebase against the upstream main/master pretty often to reduce drift.

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

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

  git commit --patch --amend ...

  git stash
  git rebase --continue
  git stash pop

That “-I” really needs to be lowercase.

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.

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

The HN title is "Git rebase -I etc" but the post title is "Git rebase -i"

I guess a keyboard auto corrected i into I.

I wish there were a shorthand for

  x git commit --amend --reset-author --no-edit

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.

A workflow I was introduced to and have worked with a lot in my teams is,

1. Everyone uses feature branches

2. Everyone cleans up their branch using interactive rebase on top of main before review

3. All merges have been freshly rebase on main

I think it works very well and keeps the history clean while preserving "each commit does one thing".

Git rebase isn't scary at all, what's scary is the git rebase cult. I'll probably die never really seeing the tangible benefit a meticulously curated git history provides but at least I saw a few hundred blog posts and hn comments declaring the moral failure that is not having the cleanest commit history. The cynic in me would say that people are over-identifying too much with their recent bikeshedding addiction (just like 10-page vim configs, custom built keyboards or whatever else promises them immense but immeasurable performance gains) but in reality I guess it's just completely different mental models about code. I have yet to look at any code or it's however dirty history and needed to consult a commit message to understand what it's there for but I'm looking forward to the day where one of my rebase colleagues fixes a bug with git bisect that wasn't efficiently fixable any other way.

You dont need to open the reflog you can just

    git reset --hard @{1}

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.

If you do a rebase -i because you want to squash or fix some commits, then there's git commit --squash and git commit --fixup commands which will mark commits as intending to squash or fixup another commit, and then you can use git rebase --autosquash <base> to automatically do what you want in one go. Of course, often you forget to use the --squash/--fixup options or you can't be bothered to lookup the hash of the commit you want to fix, so you'll end up using git rebase -i anyway.

Yeah it's not scary but it can be frustrating...

Imagine bushwhacking your way through a bunch of conflicts while rebasing on main... Now you realized that you needed to do some other work before your pr is ready for review... Now you need to rebase on main again and get to relive conflict hell again.

Maybe I'm one of the stupid incompetent people referred to in this post but I haven't figured out a way to deal with the having to solve the same merge conflicts when I rebase again :(

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 found the following config to bring a great QoL improvement:

    FILE: .gitconfig
    ----------------
    [alias]
        ci = commit
        fix = commit --fixup
    [rebase]
        autosquash = true

    git tag last-good
    git ci -am 'WIP'
    git fix HEAD -a
    git fix HEAD -a
    …
    git rebase -i last-good

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.

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

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

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.

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

For stacked commit workflows which merge into main with squashing I tend to:

- create an empty commit with the branch name, type, ticket number etc. (with a small git script, `git issue 321 fix some things` -> `git switch -c 321-fix-some-things && git commit -m "fix(321): some things" --allow-empty`)

- `rebase -i` then shines when you have stacked commits where previous one have been merged _in a changed form (e.g. squashed)_. In such cases git often duplicates the already merged commits thinking they are part of your branch leading to endless dump conflicts, with a "marker" commit you can easily spot it in the `rebase -i` view and then also easily stripp them out by removing their lines

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…

Nice balance of practical examples and mental models. One question though, how do you decide when to use interactive rebase versus relying on squash merges in platforms like GitHub.

> it is very hard to actually lose work here, for three reasons.

The opposite is true, of course, for example: you move commits arround, start to resolve conflicts, and after a few steps you realize you can't, so when you

> you can bail out at any time. as aforementioned with git rebase --abort

Yep, except for all the work you've done resolving the conflict, that's "aborted"

> the old commits still exist in git’s object database, unreferenced but intact,

The best UI there is - some hidded data store you're, of course, intimately familiar with, so won't have any trouble getting data out of. Oh, wait, you didn't even know it existed? Tough luck, git gud to avoid data loss!

> botched rebase is a few minutes of you perusing through the reflog.

Unless, of course, your not that sharp to remember all the commits from their names and would also like to see the diff contents to connect to your code work. But that's just more minutes extra, not that big of a loss.

> there’s of course, the low-tech insurance policy: git branch backup-before-rebase

Finally some sensible advice, one that should be the default backup plan to save userst he trouble of wasting "few minutes" perusing the logs

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.

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

[0] https://ohshitgit.com/

After two decades of using git I'm either telling LLMs to do rebases for me or use jj (or both). Life's too short.

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

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

Most developers just have a linear view of git, which is fine. Should I really care that origins are just named nodes on combined graphs? Like, I just want to check in my code before I have to merge someone else's.

Zero rebases since Fable 5.

please people, stop teaching newcomers short aliases. please teach them proper long terms --interactive is not much harder to type than -i. Why do we keep doing this? It isn't the 1970s anymore. even if we do this all day it will take what maybe 5 KiB more of ram or storage? if that? why teach people some Harry Potter incantations when we can teach them proper words?

Sure, if they want to they can later use `npm -g i` or whatever abomination they want but when we teach them, we should use full arguments, not aliases. please, people :(

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

[dead]

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.