Git Internals

Rebase internals and the sequencer

Understand rebase as commit replay managed by the sequencer, making conflict handling and recovery decisions more predictable.

Who This Is For
  • Readers building a durable Git mental model
  • Developers who keep running into history, ref, or recovery confusion
Prerequisites
  • Comfort reading basic Git output
  • A rough idea of commits, branches, and HEAD
Common Risks
  • Learning low-level terms without connecting them to commands
  • Collapsing objects, refs, and working state into one concept

Rebase is ordered commit replay. The sequencer coordinates replay state and pause/resume behavior.

What the sequencer does

  1. computes replay set
  2. applies commits onto new base in order
  3. pauses on conflict
  4. resumes until queue is complete
Rebase InternalsRebase essentially replays a commit sequence onto a new base, giving each commit a new ID.
Before rebase
main
ABCD
feature
BEF
After rebase
main
ABCD
feature
DE'F'

Why commit IDs change

Replayed commits are new objects with potentially different parents and metadata.

Meaning of --continue, --skip, --abort

  • continue: proceed with replay queue
  • skip: drop current queued commit
  • abort: discard replay and return to start point

Recovery-first pattern

Before experimenting further:

git reflog
git switch -c rescue/pre-rebase HEAD@{n}
Avoid repeated skip without explicit intent

Skipping blindly can silently lose meaningful patches. Decide commit-by-commit why skip is safe.

Good follow-up reads

  1. recover after rebase
  2. commit graph
  3. git-rebase