Rebase, deeper

What this lesson covers

L12 is the deep treatment of rebase. It builds on the plain-rebase mechanics covered in L5 and the workflow-tradeoffs framing from L9, and goes into the practical patterns developers use daily: interactive rebase for history cleanup, the fixup-and-autosquash flow for keeping history clean as you work, and the recovery moves when a rebase goes sideways.

The lesson also covers the one hard rule of rebase: don’t rewrite published history. The discussion includes the social and technical cost of breaking the rule, how to defend with branch protection and --force-with-lease, and how to recover when the rule gets broken anyway.

L12 closes Phase 3. After L12, the track crosses into Phase 4 (multi-agent territory): worktrees, integration patterns, AI-authored commits, and the future of git in an AI world.

By the end of L12, the reader will be able to

Distinguish plain rebase from interactive rebase and use each for the right job
Apply git rebase -i HEAD~N with the action keywords (pick, reword, squash, fixup, drop, exec, break)
Reorder, squash, and drop commits to turn messy WIP history into clean reviewable units
Use git commit --fixup=<sha> during work and git rebase -i --autosquash at cleanup time
Resolve conflicts during rebase using the same process as merge conflicts
Recover from a rebase gone wrong using git rebase --abort or the reflog
Apply the “don’t rewrite published history” rule and use --force-with-lease for safe force-pushes
Choose rebase vs merge using the team-policy framing from L9, now with deeper command-level understanding

Prerequisites

L1-L11 of T7. Specifically: snapshot model (L3), branches (L5), the plain-rebase introduction in L5, merge conflict resolution (L7), the workflow tradeoffs in L9, and the cherry-pick mechanics in L11. Rebase reuses cherry-pick under the hood, so L11 is useful priming.

Reading map

1: motivation scenario (messy feature branch, twelve WIP commits, the cleanup choice)
2: quick recap of plain rebase
3: what interactive rebase adds (the todo list, the action keywords)
4: the action keywords explained (pick, reword, edit, squash, fixup, drop, exec, break)
5: a concrete worked example of cleaning up a messy feature branch
6: the fixup-and-autosquash workflow (proactive cleanup as you work)
7: rebase conflict handling
8: the hard rule, don’t rebase published commits
9: the --force-with-lease safety net
10: recovery from rebase gone wrong (—abort, reflog, reset)
11: rebase vs merge choice (revisited with deeper command-level understanding)
12: four worked examples (PR cleanup, fixup flow, rebase conflict during long feature, “I rebased main by mistake” recovery)
13: SVN/Mercurial/Perforce comparisons for experienced devs
14: a useful frame for managers and TPMs
15: Phase 4 foreshadowing
16: four team-scale scenarios
17: stay-calm psychology (reflog safety, published-history as only inviolable rule)
18: closers and voice anchor

What this lesson deliberately does not cover

Filter-branch and git-filter-repo for bulk history rewriting (e.g. removing a leaked secret from all history): out of scope for T7; appropriate for a dedicated security/admin track
Rebase preserving merge structure (--rebase-merges): mentioned briefly; deep coverage out of scope as most teams either don’t need it or rely on tooling
Git hooks that enforce commit-history policies: adjacent to L12 but out of scope
The implementation details of how reflog works internally: covered conceptually; mechanical details out of scope

Estimated reading + practice time

60-80 minutes for the lesson body, plus 30-45 minutes for the practice drills. Most learners spend the most time on the fixup-and-autosquash drill: it’s the highest-leverage proactive habit the lesson introduces.