Theory

Theory: Rebase Copies Commits; It Does Not Slide Them

A rebase walks a range of commits, takes each patch against its parent, and applies it onto a new base. Each successful apply writes a new commit (new hash, usually same author, you as committer).

Invariants

1. Original commits remain in the object store until GC; the branch name moves to the copied tip.
2. Conflicts happen once per copied commit, not once at a join.
3. Interactive rebase is the same machine plus a todo list (pick, squash, fixup, reword, edit, drop).
4. pull --rebase = fetch + rebase local-only commits onto @{u}.
5. --onto is “take this range and replay it on that commit,” the general form of rebase.

 before                         after git rebase main

 A ← B ← C ← G     main         A ← B ← C ← G          main
      ↑                                     ↖
      D ← E        feat                       D' ← E'  feat

Why teams fight about it

Merge preserves hashes and adds a node. Rebase rewrites hashes and can keep main linear. Unpublished feature branches are the safe audience. Published main is not.

What can break

• Rebasing commits other people have based work on (force-push incident).
• --ours/--theirs confusion vs merge.
• Empty commits after rebase (--skip vs keep).

How to read this chapter

Why, interactive, conflicts, pull –rebase, vs merge, lab; then --onto, autosquash, --exec, --update-refs.