Birbla

Comments

Hacker News

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.

by LunicLynx

That “-I” really needs to be lowercase.

by koolba

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

by pajko

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

by nixpulvis

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.

by xg15

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

by mikemcquaid

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.

by flyingcircus3

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • 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...

    by maxloh
  • 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.
    by LunicLynx
  • That “-I” really needs to be lowercase.
    by koolba
  • 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
    by pajko
  • I feel like if you're scared of rebasing, you don't actually understand git.
    by nixpulvis
  • 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.

    by xg15
  • 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).

    by mikemcquaid
  • 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.

    by flyingcircus3