Git Internals

Three-way merge mechanics

Understand how Git computes merges from base, ours, and theirs so conflicts and merge outcomes are easier to reason about.

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

Git merge is a three-input computation: base, ours, and theirs.

Inputs

  • base: common ancestor from merge-base
  • ours: current branch tip
  • theirs: merged branch tip

Git compares base→ours and base→theirs, then synthesizes result.

Three-way Merge MechanicsThree-way merge uses the tips of two branches and their common ancestor, attempting to automatically merge non-conflicting parts.
Before merge
main
ABC
feature
BDE
After merge
main
ABCM
feature
BDEM

Why conflicts appear

Conflicts occur when both sides changed overlapping regions and Git cannot choose semantics safely.

Practical takeaway

To resolve conflicts well, inspect base context instead of only choosing ours/theirs blindly.

Conflict markers are a decision point, not a parser failure

A conflict means Git needs human intent where automatic reconciliation is ambiguous.

Good follow-up reads

  1. merge-base and ancestry
  2. git-merge
  3. rerere for recurring conflicts