Kelly Mears

Rebase

Replaying a branch's commits onto a new base, producing new commits with the same changes.

Version Control & Delivery2 min read230 words15 out · 15 in
also calledRebasingrerere

Rebasing replays a branch's commits onto a different base commit, one at a time. The result is a linear history, as if the work had been done starting from the new base. The commits are new objects with new hashes — the originals still exist but are no longer referenced by the branch.

The practical argument for rebasing over merging is readable history: a linear sequence with no merge commits is easier to read, bisect, and revert. The argument against is that it rewrites history, so rebasing a branch other people have based work on causes them real pain.

Several things about rebasing are worth knowing concretely.

Conflicts are resolved per commit, not once, which is why a long branch across a busy base can mean resolving the same conflict repeatedly. Git's rerere feature records resolutions and replays them automatically, which saves enormous time — and will faithfully replay a wrong resolution after you change strategy, so it needs clearing when you do.

Textual success is not semantic success. A clean rebase can leave a branch that no longer type-checks, because the new base added readers of something the branch changed. The type checker, not the conflict list, is the real detector.

A stacked branch rebases onto its parent, not onto the main line; rebasing it onto main instead diverges the shared commits and manufactures conflicts. See Stacked Pull Requests.

See also14

Three-Way Merge

Combining two lines of work by comparing both against their common ancestor.

Version Control & Delivery17 connections

Semantic Conflict

Two changes that merge cleanly and are incompatible in meaning.

Version Control & Delivery15 connections

Merge Train

Validating changes against the state they will actually merge into, in order, rather than in isolation.

Version Control & Delivery14 connections

Regression

A previously working behavior that a change has broken.

Method23 connections

Merge Conflict

Overlapping changes that a merge cannot combine automatically, requiring a decision.

Version Control & Delivery17 connections

Commit

A recorded snapshot of a project with a message explaining it.

Version Control & Delivery23 connections

Version Control

A system recording the history of a project's files, enabling branching, merging, and recovery.

Version Control & Delivery26 connections

Continuous Integration

Automatically building and testing every change, so integration problems surface immediately.

Version Control & Delivery38 connections

Trunk-Based Development

Everyone integrating into one shared branch continuously, with short-lived feature branches.

Version Control & Delivery20 connections

Feature Branch

A branch created to develop one change in isolation before merging it back, a workflow that keeps the main line stable but grows riskier the longer the branch lives, since its divergence from everyone else's work compounds.

Version Control & Delivery16 connections

Detached HEAD

The Git state in which the current checkout points directly at a commit rather than a branch, harmless for looking around but a trap for new work, since commits made there belong to no branch and can quietly disappear.

Version Control & Delivery11 connections

Cherry-Pick

Copying the change from one commit onto another branch as a new commit, the standard way to backport a fix without merging everything else that came with it.

Version Control & Delivery15 connections

Reflog

Git's private record of everywhere HEAD and each branch has pointed, the safety net that makes a botched reset, rebase, or deleted branch recoverable for weeks.

Version Control & Delivery13 connections

Fast-Forward Merge

The two basic ways Git joins branches, by sliding a branch pointer forward or by recording a new commit with two parents, and how the choice shapes a project's history.

Version Control & Delivery14 connections

Linked from15