Interactive rebase

Why this matters

A branch after a real afternoon contains "wip", "fix typo" and "actually fix typo". Interactive rebase turns that into the two or three commits you would have made if you had known where you were going, which makes review easier and history readable.

It also rewrites history, so the rule from lesson 12.3 applies without exception: only on commits nobody else has.

The todo list

$ git rebase -i main

Git opens an editor containing one line per commit, oldest first:

pick 68c4a9d feat: add the difficulty filter
pick a41d0c2 wip
pick 12ae4d1 fix typo
pick 9c8987f docs: document the filter

# Rebase d3b92ec..9c8987f onto d3b92ec (4 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
#                    commit's log message

You edit the first word of each line, save, and close. Git then replays the commits according to your instructions.

The words

Two behaviours beyond the words: reordering the lines reorders the commits, and deleting a line is the same as drop, which is why an accidental deletion is worth knowing about.

Squashing, in practice

Change the second and third lines to fixup:

pick   68c4a9d feat: add the difficulty filter
fixup  a41d0c2 wip
fixup  12ae4d1 fix typo
pick   9c8987f docs: document the filter

Successfully rebased and updated refs/heads/feature/21-difficulty-filter.

$ git log --oneline -3

5a1c15c docs: document the filter
a8b40cb feat: add the difficulty filter
d3b92ec chore: add CI configuration and contributing guide

Four commits became two, with the same files. Both remaining commits have new hashes, because their content or their parent changed (lesson 18.1).

Autosquash: the version worth learning

Editing the todo by hand is fine for four commits and tedious for fifteen. Autosquash automates the common case: you notice a mistake in an earlier commit and want the fix folded into it.

$ git commit --fixup 68c4a9d

That makes an ordinary commit whose message is fixup! feat: add the difficulty filter. Then:

$ git rebase -i --autosquash main

Git pre-arranges the todo for you:

pick   68c4a9d feat: add the difficulty filter
fixup  12ae4d1 fixup! feat: add the difficulty filter
pick   9c8987f docs: document the filter

Save and close without editing anything, and the fix is absorbed into the commit it belongs to. Set git config --global rebase.autosquash true and --autosquash becomes the default.

This is the workflow to adopt: as you work, --fixup the commit each fix belongs to, then one autosquash rebase before opening the merge request.

Splitting a commit

The one that needs edit:

1. Mark the commit edit and save. Git stops there.
2. git reset HEAD~1 — the commit is undone, its changes back in your files (lesson 12.4).
3. Stage and commit the first part, then the second.
4. git rebase --continue.

Getting out

Nothing here is lost: the original commits are unreferenced but present, and the reflog names them.

Publishing afterwards

Rewriting a pushed branch means the next push is rejected, and the answer is a lease-checked force (lesson 12.8):

$ git push --force-with-lease

Your own feature branch: routine. A branch someone else has checked out: agree it first. A shared branch: no.

How to do it

$ git rebase -i main
$ git commit --fixup <hash>
$ git rebase -i --autosquash main
$ git rebase --continue | --skip | --abort

Common mistakes

• Rebasing a shared branch. The rule has no exceptions.
• Deleting a line by accident, which drops the commit. Abort and start again.
• Squashing everything into one commit when the branch genuinely did three things.
• Forgetting the branch is pushed, then being surprised by the rejection.
• Editing the todo's comment lines, which do nothing.
• Using --skip to make a conflict disappear, which drops that commit's change (lesson 12.6).