Skip to content

Review a branch after rebasing

≈ 30 minutesIntermediate5 steps · 27 min estimated

Outcome. Clean up a branch with interactive rebase, keep a reference to its old state, and use `git range-diff` to prove the rewrite changed history but not code.

Before you start: Interactive rebase · Resolve and verify a merge conflict

The duration is an estimate of engaged work, not a timer — nothing here waits. Steps marked "Check" and "Practice" are verified in the browser; "Read" and "Lab" steps are yours to confirm.

  1. Read

    squash versus fixup

    ≈ 4 min

    Read through "Verifying". The verification section is the habit this session builds.

  2. Predict

    Predict: which line do you mark?

    ≈ 1 min

    From the todo list rules.

    In an interactive-rebase todo list, you want the commit "fix typo" folded into the commit above it, "Add parser". Which line gets `fixup`?
    Why

    `squash` and `fixup` fold the marked commit into the one *above* it in the list. Mark the commit to be absorbed.

  3. Do the lab. Before the rebase, create the backup reference it tells you to — the next step depends on it.

  4. Read from "The comparison" to the end, then run `git range-diff` between your backup and the cleaned branch in the lab repository. The article has a deliberate accidental change to find.

  5. Check

    Knowledge check: squashing

    ≈ 2 min

    Includes the `--force-with-lease` question — the last step of any rewrite.

    Completes when the knowledge check on that page has been attempted.

When you are done: Lab: Recover from a force push. You have just learned to rewrite safely; this lab is what happens when someone does not, and how to repair it.

How did this go?