PB158 — Git and Source Code Version Control

<h1>Git and Source Code Version Control</h1>

<p class="lede">A content-addressed object graph, and a way to move pointers into it. Branching strategy, review and delivery practice are your team's policy.</p>

<div class="author-block">
  <span class="name">Ondrej (Ondra) Krajicek</span>
  <a href="mailto:me@ondrejkrajicek.com">me@ondrejkrajicek.com</a> ·
  <a href="https://www.linkedin.com/in/OndrejKrajicek">www.linkedin.com/in/OndrejKrajicek</a>
  <span class="built">v1 · 4e9f6b455 · built 2026-10-08</span>
  <span class="attribution">Generated by the agentic vault — an autonomous research and authoring harness. Every factual claim was gated against a cited source registry before this document was produced.</span>
</div>

Note:

<ul>
  <li>Git is a content-addressable filesystem with a version-control interface on top [V1] [S2].</li>
  <li>Branching strategy, pull requests, review and delivery practice are policy layered on the data model [V10].</li>
</ul>

Title slide.

---

<p class="kicker">Where this starts</p>

<h2>Three messages you have already seen</h2>

<p class="lede">Each one is an exact statement about a small data structure. None of them is an opinion.</p>

<div class="rows">
<div class="row">
<div class="num">1</div>
<div class="term">Push refused</div>
<div class="desc"><code>! [rejected] main -> main (non-fast-forward)</code></div>
</div>
<div class="row">
<div class="num">2</div>
<div class="term">Pull refused</div>
<div class="desc"><code>fatal: Need to specify how to reconcile divergent branches.</code></div>
</div>
<div class="row">
<div class="num">3</div>
<div class="term">A warning after checkout</div>
<div class="desc"><code>You are in 'detached HEAD' state.</code></div>
</div>
</div>

Today these read as obstacles. By the end they read as reports about pointers.

Note:

<ul>
  <li>Teachers at one university report that learners do not think about the commands and just try them out [S20].</li>
  <li>The three messages above are documented behaviour, not defects [S6] [S12] [V4].</li>
  <li>Each message becomes predictable once objects and refs are on screen.</li>
</ul>

Ask which one they met.

---

<h2>Roadmap</h2>

<p class="lede">Eight parts. The model first, team practice second, a decision at each end.</p>

<div class="kv">
<div class="pair">
<div class="k">I · What a commit is</div>
<div class="v">Four object types, by hand.</div>
</div>
<div class="pair">
<div class="k">II · Pointers and the graph</div>
<div class="v">Three ways to combine two branches.</div>
</div>
<div class="pair">
<div class="k">III · Centralisation moves</div>
<div class="v">Out of the data model.</div>
</div>
<div class="pair">
<div class="k">IV · What Git costs</div>
<div class="v">Rival designs.</div>
</div>
<div class="pair">
<div class="k">V · Branching strategy</div>
<div class="v">One variable.</div>
</div>
<div class="pair">
<div class="k">VI · Review</div>
<div class="v">What measurements show.</div>
</div>
<div class="pair">
<div class="k">VII · Delivery practice</div>
<div class="v">Three things, one name.</div>
</div>
<div class="pair">
<div class="k">VIII · What stays open</div>
<div class="v">What is not reached.</div>
</div>
</div>

Note:

<ul>
  <li>Parts one to four build the model. Parts five to seven are the policy layer built on it.</li>
  <li>Parts three to seven each end with a decision rule the room can apply to a real team.</li>
</ul>

The payoff is stated early.

---

<h2>Takeaways</h2>

<div class="rows">
<div class="row">
<div class="num">1</div>
<div class="term">Objects and pointers</div>
<div class="desc">A commit is a snapshot. A branch is a pointer.</div>
</div>
<div class="row">
<div class="num">2</div>
<div class="term">One merge function</div>
<div class="desc">Three ways to combine two branches, three graphs.</div>
</div>
<div class="row">
<div class="num">3</div>
<div class="term">Trade-offs, not laws</div>
<div class="desc">Every Git design choice had an alternative, and some system took it.</div>
</div>
<div class="row">
<div class="num">4</div>
<div class="term">Branch lifetime</div>
<div class="desc">A contract about how long work stays unmerged.</div>
</div>
<div class="row">
<div class="num">5</div>
<div class="term">What review produces</div>
<div class="desc">Understanding first, defects second, none found after 90 minutes.</div>
</div>
<div class="row">
<div class="num">6</div>
<div class="term">Three practices, one name</div>
<div class="desc">Each one needs a different branching strategy.</div>
</div>
</div>

Note:

<ul>
  <li>The six claims this topic exists to leave behind [T1] [T2] [T3] [T4] [T5] [T6].</li>
</ul>

Read all six aloud.

---

<p class="kicker">Scope</p>

<div class="compare">
<div>
<p class="kicker">Covered</p>
<ul>
<li>The object model, rebuilt with low-level commands.</li>
<li>Three ways to combine two branches, and one remote.</li>
<li>Branching strategy, review and delivery practice.</li>
<li>Two systems that made the opposite design choice.</li>
</ul>
</div>
<div class="side-b">
<p class="kicker">Not covered</p>
<ul>
<li>Any graphical client. The command line only.</li>
<li>Any hosting service's wider interface.</li>
<li>Interactive rebase corner cases, submodules, <code>git worktree</code>.</li>
<li>Multiple remotes and forks.</li>
</ul>
</div>
</div>

Note:

<ul>
  <li>Scope statement. The command line is the only interface used, per the course constraint.</li>
  <li>Part VIII returns to the excluded items and names them as open.</li>
</ul>

Scope stated before Part I.

---

<h1>What a commit actually is</h1>

Four object types, one kind of pointer, and a repository rebuilt by hand.

Note:

<ul>
  <li>Part divider. Part I establishes the object model that every later part reads from.</li>
</ul>

---

<p class="kicker">Part I · The object model</p>

<h2>Git is a filesystem with a version-control interface on top</h2>

<p class="lede">Content addressing: store bytes, get back a name derived from those bytes.</p>

Give Git a file. It writes the bytes into `.git/objects/` under a name that is the hash of a short header plus the content. Ask for that name later and the same bytes come back.

Identical content always produces the same name. Two files with the same bytes are stored once, in every repository that holds them.

Note:

<ul>
  <li>Git is a content-addressable filesystem with a version-control interface written on top [V1] [S2].</li>
  <li>An object is written under a name derived from a header plus its content [S1].</li>
  <li>Identical content yields one object, so deduplication is automatic rather than an optimisation [S1].</li>
</ul>

The interface came later.

---

<p class="kicker">Part I · The object model</p>

<h2>Four object types, and nothing else</h2>

| Type | What it holds |
|---|---|
| `blob` | File content. No filename and no path. |
| `tree` | Directory entries. A mode, a type, a name and a hash each. |
| `commit` | One tree hash, zero or more parent hashes, an author and a message. |
| `tag` | A target hash, a tagger and a message. |

A commit hash covers its tree hash and its parent hashes. A tree hash covers the hashes below it. So one commit hash names the whole project state and all history behind it.

Note:

<ul>
  <li>The object universe is four types, and the list is complete [S1].</li>
  <li>A blob holds content and carries no name [S1].</li>
  <li>Because each hash covers the hashes below it, one commit hash names the whole history [S4].</li>
  <li>The same hash-tree structure appears in the container image layers the room has already met.</li>
</ul>

Name the earlier topic.

---

<p class="kicker">Part I · The object model</p>

<p class="lede">A fresh repository is one line of text, a directory of small files, and an empty object store.</p>

```console
$ git init demo && cd demo
$ ls .git
HEAD  config  description  hooks  info  objects  refs
$ cat .git/HEAD
ref: refs/heads/main
$ find .git/objects -type f
```

`HEAD` names the commit you have checked out. Here it does so indirectly, by naming a branch. `refs` is a directory of small files, and `objects` is empty, because nothing has been stored yet.

Note:

<ul>
  <li>The four entries that matter are <code>HEAD</code>, <code>index</code>, <code>objects</code> and <code>refs</code> [S2].</li>
  <li><code>HEAD</code> holds a symbolic ref, normally the text <code>ref: refs/heads/main</code> [S3].</li>
  <li>The object store starts empty, so every object appearing later was written by a command run in the room.</li>
</ul>

Run this live.

---

<p class="kicker">Part I · The object model</p>

<h2>A blob is content without a name</h2>

<p class="lede">Two low-level commands write one object and read it back.</p>

```console
$ printf 'test content\n' | git hash-object -w --stdin
d670460b4b4aece5915caf5c68d12f560a9fe3e4
$ find .git/objects -type f
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4
$ git cat-file -t d670460
blob
$ git cat-file -p d670460
test content
```

The first two characters of the hash are the directory. The remaining thirty-eight are the filename. Nowhere in that object is a filename recorded.

Low-level commands like these two are called plumbing. The everyday commands you already type are called porcelain.

Note:

<ul>
  <li><code>hash-object -w</code> writes a blob and prints its name [S1].</li>
  <li>The object path splits the hash into a two-character directory and a thirty-eight-character filename [S1].</li>
  <li>A blob stores content only, so filenames must come from somewhere else [S1].</li>
  <li>The low-level commands are called plumbing, and the user-facing ones are called porcelain [S2].</li>
</ul>

Say plumbing and porcelain once.

---

<p class="kicker">Part I · The object model</p>

<h2>The index is the third state</h2>

<p class="lede">Between the files on disk and a commit sits one file that maps every tracked path to a hash.</p>

The working tree is the checked-out files you can edit. The index is `.git/index`, a list of paths with the hash of the content staged for each.

`git add` computes a blob and writes the path and hash into the index. Nothing is committed yet.

Note:

<ul>
  <li><code>.git/index</code> is the third state, between working tree and commit [V7].</li>
  <li>The index maps every tracked path to the hash of its staged content [V7].</li>
  <li><code>git add</code> stages an existing file, and it does not create the file [S20].</li>
</ul>

Say it plainly.

---

<p class="kicker">Part I · The object model</p>

<h2>A tree gives content its names</h2>

<p class="lede">Write an entry into the index, then turn the index into a tree object.</p>

```console
$ git update-index --add --cacheinfo 100644 \
    d670460b4b4aece5915caf5c68d12f560a9fe3e4 test.txt
$ git write-tree
80865964295ae2f11d27383e5f9c0b58a8ef21da
$ git cat-file -p 8086596
100644 blob d670460b4b4aece5915caf5c68d12f560a9fe3e4    test.txt
```

`--cacheinfo` writes an index entry directly, from a mode, a hash and a path, with no file on disk. `100644` is the mode: Git records only normal file, executable file and symbolic link, and no owner, group or permission bits.

Note:

<ul>
  <li><code>write-tree</code> turns the current index into a tree object [S1].</li>
  <li>A tree entry is a mode, a type, a filename and a hash [S1].</li>
  <li>The only valid blob modes are <code>100644</code>, <code>100755</code> and <code>120000</code> [S1].</li>
</ul>

Do not skip `update-index`.

---

<p class="kicker">Part I · The object model</p>

<h2>A commit is a tree, its parents and a message</h2>

<p class="lede">One more command wraps the tree. The result is a snapshot with provenance.</p>

```console
$ echo 'First commit' | git commit-tree 8086596
e0437810144e64a708a6441a7094db56fe376eda
$ git cat-file -p e043781
tree 80865964295ae2f11d27383e5f9c0b58a8ef21da
author Student <s@example.org> 1774000000 +0100
First commit
```

A first commit has no parent line. Every later commit records the hash of the commit it was built on. That single link is what makes history a graph.

Your own commit hash will differ. The author name and the timestamp are hashed too.

Note:

<ul>
  <li>A commit holds one tree hash, zero or more parent hashes, identity and a message [S1].</li>
  <li>The parent link is recorded in the child, so history is built backwards [S1].</li>
  <li>A root commit has no parent line at all.</li>
  <li>A commit hashes identity and timestamps, so two people committing one tree get two hashes [S1].</li>
</ul>

Compare the two hashes.

---

<p class="kicker">Part I · The object model</p>

<p class="lede">Objects are immutable. The only mutable thing in a repository is a pointer.</p>

```console
$ git update-ref refs/heads/main e043781
$ cat .git/refs/heads/main
e0437810144e64a708a6441a7094db56fe376eda
$ cat .git/HEAD
ref: refs/heads/main
```

A branch is that file. Creating one writes forty-one bytes. Deleting one removes a file. Nothing is copied, at any repository size.

Note:

<ul>
  <li>A branch is a file under <code>.git/refs/heads/</code> containing one hash [V3] [S3].</li>
  <li>Refs are mutable and objects are immutable [S17].</li>
  <li><code>HEAD</code> names a branch, so committing rewrites the branch file that <code>HEAD</code> points at [S3].</li>
</ul>

Show the file.

---

<p class="kicker">Part I · Demonstration</p>

<h2>Predict: what did those five commands build?</h2>

<p class="lede">Write your answer down before anything else runs. Answer with equalities, not with hex.</p>

<div class="rows">
<div class="row">
<div class="num">1</div>
<div class="term">Object count</div>
<div class="desc">How many files are under <code>.git/objects</code> now?</div>
</div>
<div class="row">
<div class="num">2</div>
<div class="term">Porcelain equivalent</div>
<div class="desc">Which everyday command does each of the five replace?</div>
</div>
<div class="row">
<div class="num">3</div>
<div class="term">Second commit</div>
<div class="desc">Commit again with nothing changed, using <code>git commit --allow-empty</code>. Which hashes change?</div>
</div>
</div>

Note:

<ul>
  <li>Prediction is written before observation, because the method depends on committing to an answer first [S43].</li>
  <li>Asking for equalities rather than hash values keeps the prediction answerable.</li>
</ul>

Collect three answers first.

---

<p class="kicker">Part I · Demonstration</p>

<h2>Observe</h2>

```console
$ find .git/objects -type f | wc -l
3
$ git log --oneline
e043781 First commit
$ git cat-file -p HEAD | head -1
tree 80865964295ae2f11d27383e5f9c0b58a8ef21da

$ git commit --allow-empty -qm 'Second commit'
$ git cat-file -p HEAD | head -2
tree 80865964295ae2f11d27383e5f9c0b58a8ef21da
parent e0437810144e64a708a6441a7094db56fe376eda
```

Three objects: one blob, one tree, one commit. The second commit carries the same tree hash and a new commit hash.

Note:

<ul>
  <li>Five plumbing commands produce exactly three objects and one ref [S1] [V63].</li>
  <li>An empty commit reuses the tree object and creates one commit object [S1].</li>
  <li>The tree hash is unchanged because the content is unchanged [V5].</li>
</ul>

Run it live.

---

<p class="kicker">Part I · Demonstration</p>

<h2>Explain: <code>add</code>, <code>commit</code> and <code>branch</code> were these all along</h2>

<div class="kv">
<div class="pair"><div class="k">git add</div><div class="v"><code>hash-object -w</code> plus an index entry.</div></div>
<div class="pair"><div class="k">git commit</div><div class="v"><code>write-tree</code>, then <code>commit-tree</code>, then move the branch file.</div></div>
<div class="pair"><div class="k">git branch</div><div class="v"><code>update-ref</code>. One small file, one hash.</div></div>
</div>

The five commands added objects and moved one pointer. None of them edited an object in place. That is the whole vocabulary of the tool.

Note:

<ul>
  <li><code>git commit</code> is write-tree plus commit-tree plus update-ref [V62].</li>
  <li>A Git repository is objects plus refs, and every command adds objects or moves refs [V2] [T1].</li>
  <li>No command edits an object in place, so recovery later is a question about reachability [V2].</li>
</ul>

Say the takeaway aloud.

---

<p class="kicker">Part I · Storage</p>

<h2>Why <code>.git</code> is not enormous</h2>

<p class="lede">Every commit holds the whole project, and the cost tracks only what changed.</p>

A file that did not change hashes to the same blob, so the new tree points at the object that already exists. A directory that did not change also hashes to the same tree. Git therefore shares everything below it instead of copying it.

This is the mechanism behind container image layers. Each party sees what looks like a private copy. Both parties point at one physical original.

Note:

<ul>
  <li>An unchanged file yields an unchanged blob hash, so the new tree points at the existing blob [V5] [S4].</li>
  <li>Storage cost tracks changed content rather than project size per commit [V5].</li>
  <li>The same structural sharing is copy-on-write, reached by content identity rather than page tables [V50].</li>
</ul>

Name the earlier topic again.

---

<p class="kicker">Part I · Storage</p>

<h2>Snapshots are the model, packfiles are the storage</h2>

<p class="lede">Both halves are true. A delta is a recipe for rebuilding one object from another plus the difference.</p>

<div class="boxes">
<div class="box">
<p class="kicker">The model</p>
A commit names a whole tree. There is no delta anywhere in the object graph.
</div>
<div class="box filled">
<p class="kicker">The storage layer</p>
Git compresses each object on its own as it writes it. Git also packs many objects into one file from time to time. Only inside a packfile does Git store objects as deltas against one another.
</div>
</div>

Note:

<ul>
  <li>Snapshots are the model and deltas are an implementation detail of the storage layer [V6].</li>
  <li>Git packs loose objects periodically, and only packed objects are delta-compressed [S5].</li>
  <li>Students who learned Subversion carry the delta model across, and readers of the packfile format decide the snapshot story was a lie [V6].</li>
</ul>

Say both halves.

---

<p class="kicker">Part I · Storage</p>

<h2>The same two lines can hash to two values</h2>

<p class="lede">Content addressing hashes bytes. Line endings are bytes.</p>

A file saved with carriage-return and line-feed endings is not byte-identical to the same text saved with line-feed endings. The hashes differ.

Git normalises line endings to line feed in the index when a file is checked in. The default on Windows checks files out with carriage returns. So two laptops agree on the hash only when the file reaches the index with the same bytes.

Note:

<ul>
  <li>Line endings are normalised to line feed in the index every time a file is checked in [S13].</li>
  <li>The default for the <code>eol</code> attribute is carriage-return-line-feed on Windows [S13].</li>
  <li>A hash printed on a Windows laptop can therefore differ from the one on the slide.</li>
</ul>

Say this before comparing.

---

<p class="kicker">Part I · Integrity</p>

<h2>The hash detects accidents</h2>

<p class="lede">Tamper-evidence is structural. Adversary resistance is a property of the hash function.</p>

Change one byte below a commit and the commit hash changes. Two people who agree on a hash agree on the whole history behind it. An attack finds a collision: two inputs, one hash.

Git's own breaking-changes document names four attacks on the SHA-1 default. They are the SHAppening in 2015, SHAttered in 2017, a birthday-near-collision in 2019, and Shambles in 2020.

The default moves to SHA-256 for new repositories at version 3.0. News reporting of a maintainer summit gives April 2027 for that release. The project's own document carries no date.

Note:

<ul>
  <li>Everything is checksummed before it is stored and is referred to by that checksum [S4].</li>
  <li>Git's own document names the SHAppening, SHAttered, Birthday-Near-Collision and Shambles as the reason to move to SHA-256 [S15].</li>
  <li>One news report of a maintainer summit dates the release to April 2027, and the project page carries no date [S16].</li>
</ul>

Do not overstate this.

---

<p class="kicker">Part I · The invariant</p>

<h2>Add objects, or move refs</h2>

<p class="lede">Two operations. Every command in the tool is one of them, or both.</p>

<div class="boxes">
<div class="box">
<p class="kicker">Adds objects</p>
<code>add</code>, <code>commit</code>, <code>fetch</code>, <code>merge</code>. Additive, and safe on shared work.
</div>
<div class="box filled">
<p class="kicker">Moves refs</p>
<code>branch</code>, <code>reset</code>, <code>checkout</code>, <code>push</code>. A ref that moves backwards unnames work.
</div>
</div>

`commit --amend`, `rebase` and `cherry-pick` do both. Cherry-pick copies one commit onto another branch. All three build new objects and move a pointer, and none of them modifies the commit you started from.

Note:

<ul>
  <li>Every command is either add objects or move refs, or both [V2].</li>
  <li>Amend, rebase and cherry-pick build replacement objects rather than editing existing ones [V2].</li>
  <li>Classifying a command this way predicts whether it is safe after publishing.</li>
</ul>

Repeat the invariant here.

---

<h1>Pointers, the graph, and one remote</h1>

Merge, rebase and squash are one function. A remote adds one more namespace of pointers.

Note:

<ul>
  <li>Part divider. Part II applies the Part I invariant to every operation the room runs daily.</li>
</ul>

---

<h2>A branch is a pointer, not a container</h2>

<p class="lede">Nothing is inside a branch. A branch names one commit, and that commit names its parents.</p>

Switching branches rewrites `HEAD` and replaces the files in the working tree. It does not move you into anything.

A branch owns no commits. A commit is reachable from a branch, or it is not. Git computes reachability by walking parent links.

Note:

<ul>
  <li>A branch is a file under <code>.git/refs/heads/</code> containing one hash [V3].</li>
  <li>Learners commonly regard branches as folders in the file system, and might try to move into one with <code>cd</code> [S20].</li>
  <li>Membership is reachability through parent links, not containment.</li>
</ul>

Keep saying reachable.

---

<p class="kicker">Part II · The graph</p>

<h2>Ancestor, and the merge base</h2>

<p class="lede">Two words carry every rule in this part. Both are defined by walking parent links.</p>

| Word | Definition |
|---|---|
| ancestor | Commit A is an ancestor of B when A is reached by following B's parent links. |
| merge base | A common ancestor of two commits with no better common ancestor below it. |

A merge base is not "where the branches split". The ancestry ordering defines it. Git states plainly that a pair of commits can have more than one.

Note:

<ul>
  <li>The merge base is a best common ancestor under the ancestry ordering [S7].</li>
  <li>Git states that there can be more than one best common ancestor for two commits [S7].</li>
  <li>Teaching the base as the split point cannot predict the plural case.</li>
</ul>

Ancestry arrives before merge.

---

<p class="kicker">Part II · The graph</p>

<h2>A fast-forward creates nothing</h2>

<p class="lede">When one side is an ancestor of the other there is nothing to reconcile.</p>

If your branch tip is an ancestor of the other branch tip, Git moves your branch file forward to that commit. Git writes no new object and computes no merge.

This is the one integration that adds nothing to history. It is available only when the branch never diverged.

Note:

<ul>
  <li>In a fast-forward <code>HEAD</code> is updated to point at the named commit without creating an extra merge commit [S8].</li>
  <li>Git's glossary defines a fast-forward as a merge with a descendant, which is why the word governs the push rule too [S6].</li>
  <li>A fast-forward is a pure ref move under the Part I invariant [V2].</li>
</ul>

Name it now.

---

<p class="kicker">Part II · The graph</p>

<h2>Detached HEAD is one file holding a hash</h2>

<p class="lede">It is not a mode, a state machine or an error. It is the contents of <code>.git/HEAD</code>.</p>

```console
$ cat .git/HEAD
ref: refs/heads/main
$ git checkout e043781
You are in 'detached HEAD' state.
$ cat .git/HEAD
e0437810144e64a708a6441a7094db56fe376eda
```

Commit now and Git writes a commit object, but no branch file moves. Switch away and nothing points at that commit any more.

The warning Git prints here is a description of that one file. It is not a diagnosis.

Note:

<ul>
  <li>Detached HEAD is simply <code>HEAD</code> containing a raw hash instead of a symbolic ref [V4].</li>
  <li>Committing in this state writes an object that no ref names.</li>
  <li>The commit is abandoned rather than deleted, and the reflog still records the hash [V9].</li>
  <li>The warning names the contents of <code>.git/HEAD</code>, which the transcript prints on the next line.</li>
</ul>

The third opening message.

---

<p class="kicker">Part II · Merging</p>

<h2>A merge is a function of three trees</h2>

<p class="lede">A base, and two sides. Two versions are not enough to decide what happened.</p>

With only two versions, "this line is in A and not in B" is ambiguous. It could be an addition on one side or a deletion on the other. The base resolves it.

Git compares each side against the base. Where one side changed a region, that side wins. Where both changed the same region, the function has no rule and emits a conflict.

Note:

<ul>
  <li>A three-way merge takes a base and two sides, and the third input is what resolves the ambiguity [S7] [S8].</li>
  <li>A conflict occurs if both sides have changes in a common segment of lines [V12].</li>
  <li>Overlap of changed line ranges, not meaning, is the entire conflict criterion [V12].</li>
</ul>

Draw three inputs once.

---

<p class="kicker">Part II · Merging</p>

<h2>A conflict is a line-range overlap</h2>

<p class="lede">The criterion is textual. A merge that succeeds is not a merge that is correct.</p>

Two people can edit different lines of the same function and produce a clean merge that does not compile. The comparison is over line ranges, and nothing in it depends on what the lines do.

The reverse also holds. Two people can edit the same line with the same intent, and the function still refuses, because the ranges overlap.

Note:

<ul>
  <li>A conflict occurs if both sides have changes in a common segment of lines [V12].</li>
  <li>Only the heads and the merge base are considered, and the individual commits between them are not [S8].</li>
  <li>A clean merge is therefore a statement about text, not about behaviour.</li>
</ul>

Tests decide, not merges.

---

<p class="kicker">Part II · Merging</p>

<h2>The base can be plural, and then one side is discarded</h2>

<p class="lede">Two people resolve the same conflict in opposite directions. Now two commits qualify as the base.</p>

Git names this a criss-cross. Both candidates are best common ancestors, and neither is better. `git merge-base` prints one of them and does not say which, while `git merge-base --all` prints both.

Picking either candidate makes the merge succeed cleanly and silently drops the other person's decision. The default merge strategy avoids that: it merges the two candidates into one synthesised base, and uses that as the third input.

Note:

<ul>
  <li>Git states that under criss-cross merges there can be more than one best common ancestor [S7].</li>
  <li>Without <code>--all</code> it is unspecified which best base is output [S7].</li>
  <li>Using either candidate as the base will give an incorrectly clean merge [V13].</li>
  <li>When more than one common ancestor can be used, the default strategy merges the ancestors into one tree and merges against that tree [S8].</li>
</ul>

Read `merge-base --all` aloud.

---

<p class="kicker">Part II · Merging</p>

<h2>Three ways to call the same function</h2>

<p class="lede">The function is fixed. What changes is which inputs it gets and where its result is written.</p>

```bash
printf 'base\n' > f.txt && git add f.txt && git commit -m base
git checkout -b claire && printf 'claire\n' >> f.txt && git commit -am claire
git checkout main && printf 'main\n' > g.txt && git add g.txt && git commit -m main
```

Both branches moved after `base`, so neither tip is an ancestor of the other. Nothing here can fast-forward.

<div class="kv">
<div class="pair"><div class="k"><code>git merge claire</code></div><div class="v">One new commit with two parents.</div></div>
<div class="pair"><div class="k"><code>git rebase main</code></div><div class="v">Replay claire's commits onto main, one by one.</div></div>
<div class="pair"><div class="k"><code>git merge --squash claire</code></div><div class="v">One new commit with one parent.</div></div>
</div>

Note:

<ul>
  <li>A merge commit is tied to both branches by recording both tips as its parents [S8].</li>
  <li>Rebase replays the commits one by one, and each replay is similar to a cherry-pick [S9].</li>
  <li><code>--squash</code> produces the merge result without recording the second parent [S8].</li>
  <li>None of these are different algorithms, and their differences are entirely in the object graph they leave behind [V11].</li>
</ul>

Three names for one function.

---

<p class="kicker">Part II · Demonstration</p>

<h2>Predict: which of the three leaves <code>claire</code> behind?</h2>

<p class="lede">Three integrations of the same two branches. Write your answers down before anything runs.</p>

<div class="rows">
<div class="row">
<div class="num">1</div>
<div class="term">Content</div>
<div class="desc">Do all three put the same file content on <code>main</code>?</div>
</div>
<div class="row">
<div class="num">2</div>
<div class="term">Parents</div>
<div class="desc">How many parents does the new commit on <code>main</code> have, in each case?</div>
</div>
<div class="row">
<div class="num">3</div>
<div class="term">Ancestry</div>
<div class="desc">Afterwards, is <code>claire</code> an ancestor of <code>main</code>?</div>
</div>
</div>

Note:

<ul>
  <li>The prediction is written before the observation, and the questions ask for equalities rather than hash values [S43].</li>
  <li>Question three separates content from ancestry, which is the distinction the demonstration exists to teach.</li>
</ul>

Take a show of hands.

---

<p class="kicker">Part II · Demonstration</p>

<h2>Observe</h2>

```console
$ git merge claire -m "merge claire"
Merge made by the 'ort' strategy.
$ git log -1 --format="parents=[%p]  tree=%T"
parents=[bbd61c3 989d0bc]  tree=ee2bb78e8e0f7f27012968f23574f2db7a95ef3b
$ git merge-base --is-ancestor claire HEAD && echo yes || echo no
yes

$ git checkout claire && git rebase main         # same branches, fresh repository
Successfully rebased and updated refs/heads/claire.
$ git log --oneline -2
a46813c claire                                   # was 989d0bc
bbd61c3 main

$ git merge --squash claire && git commit -m "squashed claire"
$ git log -1 --format="parents=[%p]  tree=%T"
parents=[bbd61c3]  tree=ee2bb78e8e0f7f27012968f23574f2db7a95ef3b
$ git merge-base --is-ancestor claire HEAD && echo yes || echo no
no
$ git merge-base main claire
b0f7638
```

Note:

<ul>
  <li>The merge commit records both tips as parents, so the side branch is an ancestor afterwards [S8].</li>
  <li>The squash commit produces the same tree as the merge, because <code>--squash</code> produces the merge result [S8].</li>
  <li>The squash commit records one parent, so the side branch is not an ancestor and the merge base is still the root [V14].</li>
  <li>Rebase left the same commit message under a new hash, because a commit hashes its parents as well as its tree [V15].</li>
</ul>

One fresh repository each time.

---

<p class="kicker">Part II · Demonstration</p>

<h2>Explain: one function, three placements</h2>

| Operation | What it leaves in the graph | Part I invariant |
|---|---|---|
| Merge commit | Both tips become parents, so ancestry is preserved. | Adds objects |
| Rebase | One new commit per replayed commit, then the branch pointer moves. | Adds and moves |
| Squash | One new commit with one parent. The side branch is not an ancestor. | Adds objects |

All three put the same content on `main`. Git's own merge and rebase manuals describe all three. They differ in what the graph then says about where that content came from.

Note:

<ul>
  <li>All three leave the same file content, and they differ in the object graph they leave behind [V11] [T2].</li>
  <li>Only the merge commit makes the side branch an ancestor of <code>main</code> [S8].</li>
  <li>Ancestry is what the next merge base is computed from [S7].</li>
</ul>

Say ancestry once more.

---

<p class="kicker">Part II · Merging</p>

<h2>Why a squash-merged branch keeps re-conflicting</h2>

<p class="lede">The content arrived. The ancestry did not.</p>

Merge-base discovery walks parent links. A squash commit has one parent, so the side branch's commits are not ancestors of anything on `main`.

Merge the same branch again and the base is computed from a graph in which that work never landed. Git re-offers changes that are already present, and they conflict with themselves.

A branch lands when its content reaches `main`. The fix is one line. Delete the branch once its content has landed. Start the next change from `main`.

Note:

<ul>
  <li>The squash commit has the same tree, but the side branch is not its ancestor and the merge base is still the root [V14].</li>
  <li>The vendor documents the same hazard, warning that later pull requests can include commits already squashed into the base branch [S36].</li>
  <li>Deleting the branch after landing removes the situation rather than repairing it.</li>
</ul>

State the cure too.

---

<p class="kicker">Part II · Rewriting</p>

<h2>Rebase keeps the tree and replaces the commit</h2>

<p class="lede">A commit hashes its parents as well as its tree. Change the parent and you have a different object.</p>

Replaying a commit onto a new base can produce exactly the same file content. The commit hash is still different, because the parent hash is part of what was hashed.

That is why every hash changes after a rebase. Rebasing work that other people already fetched forces them to reconcile two histories of the same changes.

Note:

<ul>
  <li>A replayed commit can have the same tree and still be a different object, because a commit hashes its parents [V15].</li>
  <li>The rebase manual renames the replayed results in its own diagram, rather than reusing the original names [S9].</li>
  <li>Rebase adds objects and moves a ref, which is safe locally and hazardous after publishing [V2].</li>
</ul>

Recovery comes next.

---

<p class="kicker">Part II · Rewriting</p>

<h2>Garbage collection deletes what no ref reaches</h2>

<p class="lede">A rewrite abandons objects. Garbage collection is the later pass that removes them.</p>

```console
$ git reflog main
e043781 main@{1}: commit: First commit
9a1c4e0 main@{0}: rebase (finish): refs/heads/main onto origin/main
$ git branch rescue main@{1}
```

The reflog records every position a ref has held in this repository, and `main@{1}` names the position before the last one. Pointing a new branch at an old position makes the abandoned commits reachable again, so collection leaves them alone.

Note:

<ul>
  <li>Rewritten commits are abandoned rather than deleted until garbage collection, and the reflog recovers a lost hash [V9].</li>
  <li>A ref that points at an abandoned commit makes it reachable again.</li>
  <li>The reflog is local, so it does not recover work that was never in this repository.</li>
</ul>

Teach recovery immediately.

---

<p class="kicker">Part II · Remotes</p>

<h2>A remote is a name and a refspec</h2>

<p class="lede">Not a connection and not a session. Two lines of configuration that <code>clone</code> writes for you.</p>

```console
$ git config --get remote.origin.url
/tmp/demo.git
$ git config --get remote.origin.fetch
+refs/heads/*:refs/remotes/origin/*
```

The left side of the refspec names refs on the other repository, and the right side names refs in yours. The leading `+` allows the destination to be replaced even when that loses history, which is safe here because nothing of yours lives there. `origin` is simply the name `clone` chooses.

A bare repository is the usual other end. It holds the object store and the refs with no checked-out files.

Note:

<ul>
  <li>The refspec <code>+refs/heads/<em>:refs/remotes/origin/</em></code> fetches every branch on the remote into the remote-tracking hierarchy [S11].</li>
  <li>A bare repository does not have a locally checked-out copy of any of the files under revision control [S6].</li>
  <li>The refspec is a rename rule applied silently on every fetch [S11].</li>
</ul>

No network is needed.

---

<p class="kicker">Part II · Remotes</p>

<h2><code>origin/main</code> is a local file</h2>

<p class="lede">A third namespace of refs, stored on your disk, describing somebody else's repository.</p>

```console
$ cat .git/refs/remotes/origin/main
93164b00faf155d30a8bced8bc235f07f8e1bdc4
```

This is a remote-tracking ref. It records where the remote's branch was at your last fetch. It is not the remote, and it is not your branch.

Note:

<ul>
  <li>The remote-tracking ref is stored locally and describes the remote [V16].</li>
  <li>Almost every practical confusion in team use is a confusion about that namespace [V16].</li>
  <li>Git's glossary defines it as a ref used to follow changes from another repository [S6].</li>
</ul>

Write three namespaces down.

---

<p class="kicker">Part II · Remotes</p>

<h2>"Up to date" is a claim about your last fetch</h2>

<p class="lede">Nothing in <code>git status</code> reads the other repository.</p>

```console
$ git rev-parse origin/main               # reads a local file
93164b00faf155d30a8bced8bc235f07f8e1bdc4
$ git ls-remote origin refs/heads/main    # reads the other repository
b31235e5902584aa5cea6f8f621cc41296e76406  refs/heads/main
$ git status -sb | head -1
## main...origin/main
```

The two commands disagree, and `status` follows the local file. It reported neither ahead nor behind while the other repository was one commit ahead.

Note:

<ul>
  <li>The count is not approximately true, and its accuracy is exactly the freshness of the last fetch [V18].</li>
  <li><code>git ls-remote</code> is the live query, and <code>git status</code> compares two local refs [V18].</li>
  <li>The transcript above was produced against a local bare repository, so no network was involved.</li>
</ul>

Read both hashes aloud.

---

<p class="kicker">Part II · Remotes</p>

<h2><code>fetch</code> moves remote-tracking refs and nothing else</h2>

<p class="lede">One command. One visible effect, and it is smaller than the name suggests.</p>

```console
=== BEFORE ===
local main:    93164b0
origin/main:   93164b0
worktree:       M f.txt
               ?? g.txt
## main...origin/main

=== AFTER git fetch origin ===
local main:    93164b0
origin/main:   b31235e
worktree:       M f.txt
               ?? g.txt
## main...origin/main [behind 1]
```

Exactly one line changed. The uncommitted edit survived, the untracked file survived, `main` did not budge. The count is right now because `fetch` refreshed the local ref that `status` reads.

Note:

<ul>
  <li><code>fetch</code> adds objects and moves the remote-tracking refs, and touches neither local branches nor the working tree [V17].</li>
  <li>The fetch manual scopes itself to refs and the objects needed to complete their histories [S11].</li>
  <li>The behind count became correct because its input was refreshed, not because a live query was made [V18].</li>
</ul>

One ref moved.

---

<p class="kicker">Part II · Remotes</p>

<h2><code>pull</code> refuses when the branches have diverged</h2>

<p class="lede">Not a silent merge. With nothing configured, current Git stops and asks you to choose.</p>

```console
$ git config --get pull.rebase          # no output: unset
$ git config --get pull.ff              # no output: unset
$ git pull
hint: You have divergent branches and need to specify how to reconcile them.
hint:   git config pull.rebase false  # merge
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only
fatal: Need to specify how to reconcile divergent branches.
```

`pull` is a fetch followed by an integration step, and you choose the step. When the branches have not diverged, all three configured answers produce the same fast-forward.

Run the two `git config` queries first. A laptop where either setting already holds a value does not refuse.

Note:

<ul>
  <li>The refusal and the three configured answers are what to teach, and <code>pull = fetch + merge</code> is not [V19].</li>
  <li>The manual names fast-forward-only as the default, and the reproduction at version 2.55.0 shows the unset default refusing instead [S12] [V19].</li>
  <li>When the branches have not diverged, every configured answer produces the same fast-forward.</li>
  <li>A repository with <code>pull.rebase</code> or <code>pull.ff</code> already set integrates instead of refusing [S12].</li>
</ul>

The second opening message.

---

<p class="kicker">Part II · Remotes</p>

<h2><code>push</code> asks, and the remote applies one rule</h2>

<p class="lede">The destination must be an ancestor of the commit you are sending.</p>

The remote checks whether its current branch tip is an ancestor of your tip. If it is, moving the pointer forward loses no history. The remote then accepts the update.

If it is not, somebody else's commits are in the way. Moving the pointer would leave those commits unnamed, so the remote refuses.

Note:

<ul>
  <li>Only fast-forward updates are allowed, and the destination must be an ancestor of the source commit [S10].</li>
  <li>A non-fast-forward update will lose history, which is the manual's own stated reason [S10].</li>
  <li>The rule is applied by the receiving repository, which is also where an update hook would run [S6] [S14].</li>
</ul>

The first opening message.

---

<p class="kicker">Part II · Demonstration</p>

<h2>Predict: a colleague pushed while you worked</h2>

<p class="lede">One bare repository, two clones, one shared branch. Write down what each command changes.</p>

```bash
git clone /tmp/demo.git a && git clone /tmp/demo.git b
# in b: commit and push one change
# in a: commit a different change on main, then:
```

<div class="rows">
<div class="row">
<div class="num">1</div>
<div class="term">After <code>git fetch</code></div>
<div class="desc">Which of <code>main</code>, <code>origin/main</code> and the working tree changes?</div>
</div>
<div class="row">
<div class="num">2</div>
<div class="term">After <code>git pull</code></div>
<div class="desc">Does it complete, and what does it ask you?</div>
</div>
<div class="row">
<div class="num">3</div>
<div class="term">After <code>git push</code></div>
<div class="desc">Accepted or refused, and by which rule?</div>
</div>
</div>

Note:

<ul>
  <li>The demonstration runs against a local bare repository standing in for a remote, so no network is needed.</li>
  <li>The prediction is committed to paper before the commands run [S43].</li>
</ul>

A second person appears.

---

<p class="kicker">Part II · Demonstration</p>

<h2>Observe</h2>

```console
$ git fetch
From /tmp/demo
   a210208..29aa22b  main       -> origin/main
$ git status -sb | head -1
## main...origin/main [ahead 1, behind 1]
$ git pull
fatal: Need to specify how to reconcile divergent branches.
$ git push
 ! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to '/tmp/demo.git'
hint: Updates were rejected because the tip of your current branch is behind
```

Fetch changed one ref. Pull asked a question. Push refused, and the message names the rule.

Note:

<ul>
  <li>Fetch moved only the remote-tracking ref [V17].</li>
  <li>Pull refused because the branches had diverged and nothing was configured [V19].</li>
  <li>Push was refused because the remote tip was not an ancestor of the local tip [S10].</li>
</ul>

Predict before each command.

---

<p class="kicker">Part II · Demonstration</p>

<h2>Explain: the refusal is a report</h2>

<p class="lede">The remedy is to integrate and send a descendant, not to reach for a flag.</p>

<div class="rows">
<div class="row">
<div class="num">1</div>
<div class="term">Read it</div>
<div class="desc">Somebody else's commits are between your base and the remote tip.</div>
</div>
<div class="row">
<div class="num">2</div>
<div class="term">Integrate</div>
<div class="desc">Fetch, look at what arrived, then merge or rebase onto it.</div>
</div>
<div class="row">
<div class="num">3</div>
<div class="term">Push again</div>
<div class="desc">Your new tip now has the remote tip as an ancestor.</div>
</div>
</div>

`--force-with-lease` sends the update only when the remote ref still holds the value your remote-tracking ref records. Fetching immediately before it weakens the check, because you then lease against a value you have not looked at.

Note:

<ul>
  <li>A rejected push is a report, not an error [V20].</li>
  <li><code>--force-with-lease</code> requires the remote ref's current value to match the local remote-tracking ref [S10].</li>
  <li>Fetching immediately before a lease push weakens it, so the order is fetch, inspect, then lease [V21].</li>
</ul>

Fetch, inspect, lease.

---

<h1>Where centralisation went</h1>

Distribution removed a fact from the data model. It did not remove the need for it.

Note:

<ul>
  <li>Part divider. Part III separates what the tool cannot do from what a team's policy does not do.</li>
</ul>

---

<p class="kicker">Part III · Before</p>

<h2>What a central server used to provide</h2>

<p class="lede">One repository, on one server, and committing is the same act as publishing.</p>

In a centralised system such as Subversion there is one repository, on one server. Committing sends the change to that server, so committing and publishing are the same act. Working offline is not possible for anything that needs history.

The server saw every operation, so it could also enforce two things. One was an exclusive lock on a file. The other was a rule about which paths a user may read.

Note:

<ul>
  <li>Committing a change implicitly publishes it, and the distributed tools decouple the two [V22].</li>
  <li>A single authoritative server is a structural fact of the centralised data model [V22].</li>
  <li>Subversion offers access controls down to the level of individual files, and Git does not [V25].</li>
</ul>

Thirty seconds is enough.

---

<p class="kicker">Part III · The relocation</p>

<h2>Distribution removed the fact, not the need</h2>

<p class="lede">Every clone is a complete repository. None of them is authoritative by construction.</p>

Nothing in the object model marks one copy as the real one. Authority becomes a claim that people agree to honour, and the agreement is enforced somewhere outside the data model.

That somewhere is a forge: a hosting service that stores one repository and applies rules to it. Branch protection on a forge is doing the job the central server used to do structurally.

Note:

<ul>
  <li>Git relocated centralisation from the data model into policy, where forges now implement it [V22].</li>
  <li>Branch protection rules define whether collaborators can delete or force-push, and set requirements for any push [S44].</li>
  <li>The dominant practice is a hosted authoritative repository, which is a social convention on a peer-to-peer model [V10].</li>
</ul>

Define forge here.

---

<p class="kicker">Part III · The residue</p>

<h2>Locking needs a single arbiter</h2>

<p class="lede">A lock is a claim over a resource, and a claim is only meaningful if one party decides it.</p>

Two clones can each record that the lock is held, and nothing in a peer-to-peer model settles which record is right. A peer-to-peer data model therefore cannot provide locking. A team either relies on a social norm, or puts a single server back in the path.

The implication runs one way only. Locking requires centralisation. Centralisation does not require locking, which is why some centralised systems make locks optional.

Note:

<ul>
  <li>Locking requires centralisation, and centralisation does not require locking [V24].</li>
  <li>A lock needs a single arbiter to be meaningful, so distributed systems rely on social norms instead [V24].</li>
  <li>Merge-by-default assumes a useful three-way merge exists for the file type, and locking assumes it does not.</li>
</ul>

The file type decides.

---

<p class="kicker">Part III · The residue</p>

<h2>Per-path read access has no Git equivalent</h2>

<p class="lede">The unit of transfer is a reachable object graph, so there is no point at which a per-path rule applies.</p>

A centralised server answers each command by consulting a table of paths and users. Git answers a fetch by sending the objects needed to complete a history.

To hide one directory you would have to rewrite the history being served. The workarounds therefore change the unit instead: split the tree into separate repositories, or enforce at the forge.

Note:

<ul>
  <li>Subversion offers access controls down to the level of individual files, and Mercurial and Git do not [V25].</li>
  <li>The workarounds change the unit of transfer rather than adding a rule [V25].</li>
  <li>Forge enforcement covers the shared copy and nothing else [V23].</li>
</ul>

Not an omission.

---

<p class="kicker">Part III · The limit</p>

<h2>Git does ship enforcement, and it binds one repository</h2>

<p class="lede">"Git has no access control" is too strong. Git ships hooks, and a hook can refuse a push.</p>

Git ships hooks. A receiving repository can run an update hook that refuses any non-fast-forward push, or that consults a table before accepting a ref. Those are core Git, not forge features.

What Git does not do is choose the policy. And a hook binds the repository it lives in. Anyone who clones from you can bypass it entirely, and two peers who exchange commits directly are bound by nothing.

Note:

<ul>
  <li>The update hook can enforce a fast-forward-only policy and can implement access control without filesystem ownership [S14].</li>
  <li>Policy above a peer-to-peer model can approximate a central server for the shared remote, and cannot bind two peers talking directly [V23].</li>
  <li>The defensible claim is that Git supplies the mechanism and sets no policy [T3].</li>
</ul>

The counterexample is stated first.

---

<p class="kicker">Part III · Decision</p>

<h2>Can Git plus forge policy meet the requirement?</h2>

<div class="matrix">
<div class="m-row">
<div class="src">One authoritative history</div>
<div class="ref">GitHub branch protection</div>
<div class="claim">Yes. Protect the branch, and require every landing to be a fast-forward.</div>
<div class="kind">Policy</div>
</div>
<div class="m-row">
<div class="src">Exclusive lock on a binary asset</div>
<div class="ref">—</div>
<div class="claim">No. A lock needs one arbiter that peers cannot provide.</div>
<div class="kind">Structural</div>
</div>
<div class="m-row">
<div class="src">Read access restricted per path</div>
<div class="ref">—</div>
<div class="claim">No. Split the repository, or use a centralised system.</div>
<div class="kind">Structural</div>
</div>
</div>

Note:

<ul>
  <li>Branch protection sets requirements for pushes, including passing checks and a linear history [S44].</li>
  <li>Locking requires centralisation, so no forge rule recovers it [V24].</li>
  <li>A peer-to-peer model cannot supply the single arbiter a lock needs, and no source states this of Git directly.</li>
  <li>Per-path access control exists in Subversion and not in Git or Mercurial [V25].</li>
  <li>Splitting the repository or moving to a centralised system is therefore the only remedy left.</li>
</ul>

Ask for one requirement.

---

<h1>What Git costs, and who avoids paying it</h1>

Each limitation, paired with the system that made the opposite choice and what that choice cost.

Note:

<ul>
  <li>Part divider. Part IV supplies the comparative evidence that Git's design is choices rather than laws.</li>
</ul>

---

<p class="kicker">Part IV · The comparison</p>

<h2>Nothing in Git's design was the only option</h2>

<p class="lede">Content addressing already existed, and a rival project began two weeks after Git.</p>

Monotone stored objects by content hash before Git did. Torvalds tried it for a day and gave up on it, because its performance was so bad.

Mercurial's announcement is dated 20 April 2005. It states two aims: to be as simple as possible, and to be as scalable as possible.

So content addressing was not Git's invention. Git's properties are choices, and other projects took several of the alternatives.

Note:

<ul>
  <li>Monotone had interesting ideas and performance so bad that its evaluator abandoned it in a day [S19].</li>
  <li>The Mercurial announcement is dated 20 April 2005 and states the aims of simplicity and scalability [S42].</li>
  <li>Git's rename design was already being defended on its mailing list on 14 April 2005, so the two projects are contemporaries [S18].</li>
  <li>Content addressing predates Git, and a contemporary project made different choices, so these properties are not laws.</li>
</ul>

Name both systems once.

---

<p class="kicker">Part IV · The index</p>

<h2>The index has two roles, and only one needs to be visible</h2>

<p class="lede">A cache of filesystem information, and a staging buffer the user operates.</p>

The first role is uncontroversial. It is what makes `git status` fast enough to run constantly.

The second role is a design choice. Git exposes it, and exposes it under three different names across its own documentation: index, cache and staging area.

Note:

<ul>
  <li>The index is a cache of filesystem information and also a user-visible staging buffer [S22].</li>
  <li>Git exposes the index to the user, and Jujutsu names it as a concept it deliberately drops [S22].</li>
  <li>An analysis of Git's concepts finds that the staged and the working versions are not orthogonal [S21].</li>
  <li>The index is the third state between the working tree and a commit [V7].</li>
</ul>

Refer back to Part I.

---

<p class="kicker">Part IV · A system that chose differently</p>

<h2>Keep the object graph, replace the layer above it</h2>

<p class="lede">Jujutsu stores its data in a Git repository and discards Git's user model.</p>

The working copy is itself a commit, snapshotted automatically. Because of that there is no index, and no stash either. A stash is Git's side pocket for unfinished edits, and an ordinary commit already does that job.

Everything the system changes sits strictly above the object graph, and it still interoperates with the same repositories. That is what makes it evidence about Git rather than a rival product.

It is pre-1.0, at release v0.45.1 of September 2026, and the project calls itself experimental. This is not migration advice.

Note:

<ul>
  <li>Everything Jujutsu changes sits above the object graph, which separates what Git is from what Git merely does [V26].</li>
  <li>There is no index, because an automatically committed working copy makes an index-like concept unnecessary [S22].</li>
  <li>The same analysis reads stashing as a patch for flaws in Git's design rather than a requirement of version control [V31].</li>
  <li>As of release v0.45.1 it remains pre-1.0 [V27].</li>
</ul>

Interface replaced, format kept.

---

<p class="kicker">Part IV · A different model</p>

<h2><code>cherry-pick</code> writes a new object with no link to the original</h2>

<p class="lede">Git derives changes by comparing snapshots. A change has no identity of its own.</p>

Copying a commit to another branch builds a new commit object. Its content may be identical and its hash is different, because the parent differs. Nothing records that the two are the same change.

So Git cannot tell you that a fix is already present somewhere else, and a later merge can offer the same change again.

Note:

<ul>
  <li>A replayed or copied commit has a different hash, because a commit hashes its parents as well as its tree [V15].</li>
  <li>Rebase replays commits one by one, and each replay is similar to a cherry-pick [S9].</li>
  <li>Nothing in the object model links a copy to its original.</li>
</ul>

The pairing comes next.

---

<p class="kicker">Part IV · A different model</p>

<h2>Darcs and Pijul make the change the object</h2>

<p class="lede">Store patches with durable identities, and derive the tree by applying a set of them.</p>

Once a change is a first-class object you can ask whether two changes commute. If A then B reaches the same state as B then A, the two are independent.

A change keeps its identity wherever it is applied, so cherry-picking is not a re-creation. A later merge recognises the patch rather than re-offering it.

The model is a real trade. Darcs still records its own exponential merge problem as unfixed, and Pijul has no stable release. No independent benchmark found in this research compares Pijul's merge speed with Git's.

Note:

<ul>
  <li>Darcs and Pijul store the change itself, give it a durable identity, and derive the tree state by applying a set of them [V28].</li>
  <li>A change carries the same identity wherever it is applied, so cherry-picking is not a re-creation [V29].</li>
  <li>Commutation is what lets a merge work by set difference over identities rather than by comparing endpoint trees [V28].</li>
  <li>The Darcs conflict representation can make merges exponential, and its own page records the answer as no, dated 2012-08-02 [V30] [S41].</li>
  <li>No independent benchmark of Pijul's merge performance against Git on a large repository was found for this topic.</li>
</ul>

Define commute out loud.

---

<p class="kicker">Part IV · Unpaired</p>

<h2>Git stores no fact that one file became another</h2>

<p class="lede">The rename is reconstructed at comparison time, from content similarity alone.</p>

The design position was stated in 2005 and defended since. Git is about tracking data, and not about tracking what happened to create that data.

At comparison time Git scores each deleted path against each created path for content similarity. It merges the pair into a rename when the score passes a threshold. The default threshold is 50 percent.

Note:

<ul>
  <li>Git is about tracking data, not about tracking what happened to create that data [S18].</li>
  <li>Rename detection merges a deleted and a created filepair when the contents are similar enough [S46].</li>
  <li>The algorithm that measures the extent of the changes decides what counts as similar enough [S46].</li>
  <li>The default similarity score is 50 percent, and no object records the result [S46].</li>
</ul>

State the design position first.

---

<p class="kicker">Part IV · Unpaired</p>

<h2>A rename plus a large edit scores below the threshold</h2>

<p class="lede">Put both in one commit and the trail of the file ends there.</p>

```console
$ git mv parser.c lexer.c
$ # ...then rewrite most of lexer.c in the same commit
$ git commit -qam 'rename and rewrite'
$ git log --follow --oneline lexer.c
9f2a1c8 rename and rewrite
```

The similarity score falls below 50 percent. Git reports a delete and an add, so `--follow` has nothing to cross.

The remedy is one commit per action. Commit the rename on its own. Commit the edit afterwards. No alternative system surveyed here removes the underlying cost.

Note:

<ul>
  <li>Rename detection runs while two commits are compared, so a large edit in the same commit defeats it [S46].</li>
  <li>A commit holding only the rename keeps the similarity score high, so <code>--follow</code> crosses it.</li>
  <li>No alternative surveyed for this topic pairs with this limitation, so it is named as unresolved.</li>
</ul>

Show the two-commit remedy.

---

<p class="kicker">Part IV · Scale</p>

<h2>Scale breaks one assumption, not the model</h2>

<p class="lede">A commit is a whole-tree snapshot whether the tree holds fifty files or five million.</p>

What breaks is an assumption layered on top of the model. The assumption is that one client can do three things cheaply:

<ul>
  <li>hold the whole tree</li>
  <li>transfer it on clone</li>
  <li>walk it on every status check</li>
</ul>

The production fixes split into two families. One fetches less, so the repository is genuinely incomplete. The other presents a complete working tree over an incomplete one. It fetches each file on demand.

A partial clone therefore gives up offline operation, because a missing object has to be fetched.

Note:

<ul>
  <li>What breaks at monorepo scale is an assumption layered on top of the model [V32].</li>
  <li>The symptoms do not share one axis, so a single fix does not exist [V32].</li>
  <li>A partial clone defers blobs to a promisor remote, so the client has to be online.</li>
</ul>

The work moved.

---

<p class="kicker">Part IV · Decision</p>

<h2>Trace one surprise to the choice that produced it</h2>

<div class="rows">
<div class="row">
<div class="num">1</div>
<div class="term">Detached HEAD</div>
<div class="desc"><code>HEAD</code> may hold a raw hash, so a commit advances no branch. Jujutsu's working copy is itself a commit.</div>
</div>
<div class="row">
<div class="num">2</div>
<div class="term">A stash you lost</div>
<div class="desc">The stash is a side pocket outside history. Jujutsu keeps no index and no stash.</div>
</div>
<div class="row">
<div class="num">3</div>
<div class="term">A cherry-pick that conflicted again</div>
<div class="desc">A change carries no identity. Darcs and Pijul hash the change itself.</div>
</div>
</div>

Name one Git behaviour that has cost you an hour. Then name the design choice that produces it, and the system that chose otherwise.

Note:

<ul>
  <li>Detached HEAD is <code>HEAD</code> holding a raw hash instead of a symbolic ref [V4].</li>
  <li>Jujutsu snapshots the working copy as a commit, so that design needs no index and no stash [S22] [V26].</li>
  <li>A copied commit gets a new hash, and nothing in the object model links it to the original [V15].</li>
  <li>Darcs and Pijul give the change a durable identity, so a patch survives being moved [V28] [V29] [T3].</li>
</ul>

Take three answers.

---

<h1>Branching strategy</h1>

Five named models, one variable underneath them, and the evidence for setting it low.

Note:

<ul>
  <li>Part divider. Part V is the first part in which nothing new happens to the object graph.</li>
</ul>

---

<p class="kicker">Part V · The variable</p>

<h2>A branching strategy is a contract about branch lifetime</h2>

<p class="lede">Git enforces none of this. A branch can sit unmerged for two years and no command refuses.</p>

In these repositories the single shared branch is called `main`. The literature calls that branch the trunk.

A strategy says which branches exist and who may move them. It says how long a change may stay outside the trunk, and what it must pass on the way back. The team imposes every one of those constraints from outside the tool.

The named models differ mainly in that one variable, and almost every documented cost and benefit follows from it.

Note:

<ul>
  <li>A branching strategy is a social contract expressed in refs [V33].</li>
  <li>Almost every documented cost and benefit follows from that one variable [V34].</li>
  <li>Trunk is the literature's word for the single shared branch, also known as main or master [S26].</li>
</ul>

Name trunk here.

---

<p class="kicker">Part V · The models</p>

<h2>The five models you will meet</h2>

| Model | Long-lived branches | Built for |
|---|---|---|
| Trunk-based | `main` only, plus short release branches | Frequent delivery, high throughput |
| GitHub Flow | `main` only | Web applications that deploy on merge |
| GitLab Flow | `main` plus one branch per environment or version | Explicit promotion gates, several versions |
| Release Flow | `main` plus one branch per release | Several supported versions at large scale |
| Gitflow | `main` and `develop`, plus release and hotfix | Scheduled, explicitly versioned releases |

Read the middle column. The difference between the five is which branches are allowed to live a long time, and that is the whole disagreement.

Note:

<ul>
  <li>Trunk-based development resists any pressure to create other long-lived development branches [S26].</li>
  <li>Gitflow keeps two long-lived lines, <code>main</code> and <code>develop</code>, plus supporting release and hotfix branches [S29].</li>
  <li>Release Flow keeps <code>main</code> as the single integration branch and cuts a release branch per iteration [S35].</li>
  <li>Almost every documented cost and benefit follows from that one variable [V34].</li>
</ul>

Five names, one axis.

---

<p class="kicker">Part V · Mechanics</p>

<h2>Three merge methods, three shapes of history</h2>

| Merge method | What lands on the trunk | Available when |
|---|---|---|
| Fast-forward | The branch commits, unchanged. No new object at all. | The branch never diverged |
| Merge commit | All branch commits, plus one commit with two parents. | Always |
| Squash | One new commit. Intermediate commits do not survive. | Always |

A forge offers these as three buttons, and all three are ordinary Git operations.

Note:

<ul>
  <li>A fast-forward updates <code>HEAD</code> without creating an extra merge commit [S8].</li>
  <li>Squash merging does not preserve intermediate commits as separate commits on the base branch [S36].</li>
  <li>Rebase merging always updates committer information and creates new commit hashes [S36].</li>
</ul>

Tie back to Part II.

---

<p class="kicker">Part V · The model</p>

<h2>Trunk-based development is a cadence, not a topology</h2>

<p class="lede">The definition is stated in merges per day, not in the shape of the graph.</p>

Each developer divides their work into small batches and merges into the trunk at least once a day, and potentially several times.

trunkbaseddevelopment.com defines it by what it forbids: collaborating in a single branch and resisting pressure to create other long-lived development branches. Short-lived branches for review and build checks are inside the model, not outside it.

Note:

<ul>
  <li>Each developer divides work into small batches and merges into trunk at least once a day [S28].</li>
  <li>The model forbids other long-lived development branches rather than all branches [S26].</li>
  <li>A pull-request branch that lives four hours is trunk-based, and one that lives four weeks is not [V34].</li>
</ul>

A number follows.

---

<p class="kicker">Part V · The model</p>

<h2>Two variants, split by team size</h2>

<div class="kv">
<div class="pair"><div class="k">Direct to trunk</div><div class="v">Commit straight to the trunk. Checks run after the commit lands. Up to 15 people.</div></div>
<div class="pair"><div class="k">Short-lived branches</div><div class="v">One branch per change, reviewed and checked before landing. Sixteen or more developers.</div></div>
</div>

trunkbaseddevelopment.com puts the boundary at sixteen developers. It says the cut-off was 100 people before lightweight branching and the pull request, and is 15 now. Below the boundary a branch and a review for every change buy little, because few people commit. Above it, unverified commits land on the trunk and break it for everyone else.

Note:

<ul>
  <li>With sixteen or more developers the team is more productive with short-lived branches verified before landing [S27].</li>
  <li>The site says the cut-off moved lower with lightweight branching and the pull request, from 100 people to 15 [S27].</li>
  <li>Both variants are the same model, differing in when the check runs.</li>
</ul>

Ask the group size.

---

<p class="kicker">Part V · Preconditions</p>

<h2>Two preconditions that summaries leave out</h2>

<div class="stats">
<div><div class="stat">2 days</div><div class="stat-cap">the site's own risk threshold for becoming a long-lived branch</div></div>
<div><div class="stat">1 author</div><div class="stat-cap">per branch, or two when pair programming</div></div>
</div>

A branch that three people push to for a week is not a short-lived feature branch. It is a long-lived branch carrying a short-lived branch's name.

The trunk must also stay shippable, which is a testing property rather than a branching one. This is the healthy-branch rule: automated checks on each commit, so that the branch has no known defects.

Note:

<ul>
  <li>The branch should only last a couple of days, and longer than two days risks a long-lived feature branch [S27].</li>
  <li>The developer count should stay at one, or two if pair programming [S27].</li>
  <li>A healthy branch means automated checks on each commit to ensure there are no defects on the branch [S30] [T4].</li>
</ul>

Say the takeaway aloud.

---

<p class="kicker">Part V · Evidence</p>

<h2>Conflicts rise with divergence, and size predicts better than time</h2>

<p class="lede">The largest mining study of merge conflicts, with the effect size that qualifies it.</p>

One study covers 182,273 merge scenarios in 80 projects. The comparison is against the study's own average conflict rate. Branches integrated in under a day produced about 40% fewer conflicts. Branches older than 30 days produced about 161% more.

The same paper reports the effect size for branch duration as small, at minus 0.3 on its own scale. It finds the number of changed files, commits and authors to predict conflicts more strongly. So size is the stronger predictor, and duration is largely standing in for it.

Note:

<ul>
  <li>The study covers 182,273 merge scenarios across 80 projects, with 40% fewer conflicts under a day and 161% more beyond 30 days [S38].</li>
  <li>The same paper reports a small effect size of minus 0.3 for branching duration [S38].</li>
  <li>Size is the stronger predictor and duration is largely a proxy for size [V35].</li>
</ul>

Put both figures up.

---

<p class="kicker">Part V · Evidence</p>

<h2>The resolutions themselves ship defects</h2>

<p class="lede">A conflict is not merely annoying. The code that comes out of one is measurably worse.</p>

Across 143 open-source projects and 36,122 merge commits, 19.32% produced conflicts that a person had to resolve.

Lines involved in a conflict were about twice as likely to be buggy as lines that were not. Lines involved in a conflict of entangled syntax-tree changes were about 26 times more likely to need a bug-fixing commit than lines from trivial conflicts.

Note:

<ul>
  <li>19.32% of 36,122 merge commits produced conflicts requiring human intervention [S39].</li>
  <li>Conflicted lines were about twice as likely to be buggy [S39].</li>
  <li>Semantically entangled resolutions were about 26 times more likely to need a bug-fixing commit than trivial ones [S39].</li>
</ul>

Open-source repositories only.

---

<p class="kicker">Part V · Evidence</p>

<h2>The delivery evidence points the same way, and is weaker</h2>

<p class="lede">Two lines of evidence with different weaknesses. One objection does not remove both.</p>

The survey research associates higher delivery performance with teams that keep three or fewer active branches and merge to the trunk at least daily.

It is self-reported and correlational. Nothing in the data establishes that adopting the practice causes the performance rather than accompanying the test automation that makes it survivable.

Note:

<ul>
  <li>The association is with three or fewer active branches and merging to trunk at least daily [S28].</li>
  <li>The methodology relies on self-reported data, which introduces documented biases in accuracy and social desirability [V46].</li>
  <li>The conflict studies and the survey fail in different ways, which is why the pair is stronger than either.</li>
</ul>

Caveat beside the number.

---

<p class="kicker">Part V · The real dispute</p>

<h2>Nobody defends long-lived feature branches</h2>

<p class="lede">The argument that survives is about release branches, and whether your product needs them.</p>

Vincent Driessen published the best-known model in 2010, and it is usually called Gitflow. He narrowed it himself in 2020. For a team that ships on demand he suggests a much simpler workflow. For software that is explicitly versioned, or that supports multiple versions in the wild, he says his model may still fit.

Microsoft's documented practice does both at once. Short-lived branches come off `main`. The team cuts a release branch for each three-week iteration. That branch never merges back, and fixes reach it by copying a commit forward from `main`.

Note:

<ul>
  <li>Nobody defends long-lived feature branches, and the dispute is entirely about long-lived release branches [V36].</li>
  <li>Driessen suggests a simpler workflow for continuous delivery, and says his model may still fit explicitly versioned software [S29].</li>
  <li>Release branches never merge back, and a fix goes to the trunk first so that it does not recur at the next deployment [S35].</li>
</ul>

Fix trunk, then forward.

---

<p class="kicker">Part V · The substitution</p>

<h2>Flags replace branches, and the debt is measured</h2>

<p class="lede">Unfinished work has to be isolated somewhere. A branch isolates it in history, a flag isolates it at run time.</p>

An unmerged branch is listed by `git branch` until somebody deals with it. A feature flag is a switch in the code that hides unfinished work from the user. A flag left in place after a release is listed nowhere.

Across 100 projects holding 7,593 flags, half were removed within fifteen months, and a quarter remained for more than eight years. Accumulation is the default path, not an occasional lapse.

Note:

<ul>
  <li>Every unmerged branch announces itself, and a flag that was supposed to be removed does not [V37].</li>
  <li>Half of the flags are removed within 15 months, and 25% remain for a very long time or forever [S40].</li>
  <li>Cheap integration is what makes small changes possible at all, and the setup cost is what moved [V49].</li>
</ul>

Part VII decides this.

---

<p class="kicker">Part V · Decision</p>

<h2>Which branching strategy does your project earn?</h2>

<div class="rows">
<div class="row">
<div class="num">1</div>
<div class="term">Can checks run in minutes?</div>
<div class="desc">If not, short-lived branches deliver instability rather than speed.</div>
</div>
<div class="row">
<div class="num">2</div>
<div class="term">One author per branch?</div>
<div class="desc">A shared branch is a long-lived branch with a short name.</div>
</div>
<div class="row">
<div class="num">3</div>
<div class="term">Versions live in the field?</div>
<div class="desc">A customer on an old version needs a patch. That earns a release branch.</div>
</div>
<div class="row">
<div class="num">4</div>
<div class="term">How big is the change?</div>
<div class="desc">Duration is largely a proxy for size. Ask the size too.</div>
</div>
</div>

Answer these four about your own group project. Two answers of no mean short-lived branches will not work yet.

Note:

<ul>
  <li>The healthy-branch precondition is automated checks on every commit [S30].</li>
  <li>One author per branch, or two when pair programming [S27].</li>
  <li>Supporting multiple versions in the wild is what earns a long-lived release branch [S29] [V36].</li>
  <li>Changed files, commits and authors predict conflicts more strongly than branch duration does [S38] [V35].</li>
</ul>

Run it on one project.

---

<h1>Pull requests and review</h1>

Not Git. A convention roughly eighteen years old, and what the measurements actually say about it.

Note:

<ul>
  <li>Part divider. Part VI is about what people do, and the only Git fact in it is a limitation.</li>
</ul>

---

<p class="kicker">Part VI · Origins</p>

<h2>The name is from 2005, the button is from 2011</h2>

<p class="lede">A pull request was originally a request that somebody else perform a pull.</p>

A maintainer with work ready mailed a message naming a repository and a list of commits, and asked the recipient to fetch it. Git shipped a command to generate exactly that message in July 2005.

In February 2008 GitHub wrapped that message in a web page. Inline comments on the difference arrived in February 2011, three years later. The button that performs the merge arrived in April 2011, two months after that. Until then every pull request was merged by hand.

Note:

<ul>
  <li>A pull request was originally a request that someone perform a pull, which is why the name does not describe what it does today [V39].</li>
  <li><code>git request-pull</code>, the command that generates exactly that message, was written in July 2005 [V60].</li>
  <li>GitHub's February 2008 pull request was essentially a graphical wrapper over that command [V61].</li>
  <li>Inline comments in the diff view arrived in February 2011, and the merge button in April 2011 [V51].</li>
  <li>Before the merge button, every pull request was merged by hand [V52].</li>
  <li>Git ships approval, reviewer and comment thread nowhere, because those are forge inventions [V38].</li>
  <li>The data model was fixed in 2005 and the policy layer accreted between 2008 and 2011.</li>
</ul>

Chronology is the thesis.

---

<p class="kicker">Part VI · Evidence</p>

<h2>What reviewers write about is mostly not defects</h2>

<p class="lede">One study classified 570 comments from 200 review threads at a large software company.</p>

Finding defects was the top-ranked motivation the participants gave. In the classified comments, defect was the fourth most frequent category of nine, at 14%. Code improvements was the most frequent, at 29%.

The study's own summary says review comments about defects are few, at roughly one eighth of the sample. It adds that they mostly address superficial concerns rather than design-level ones.

That does not make review idle. A separate study still estimates up to two and five extra defects after release where review coverage and participation are low.

Note:

<ul>
  <li>Finding defects was the top-ranked motivation the participants gave [S23].</li>
  <li>In the classified comments, defect was the fourth most frequent category of nine, at 14% [S23].</li>
  <li>Code improvements was the most frequent category, at 29% [S23].</li>
  <li>Review comments about defects are few, comprising one-eighth of the total in that sample [S23].</li>
  <li>Those defect comments mostly address superficial concerns rather than conceptual or design-level ones [S23].</li>
  <li>The study observed 17 developers, classified 570 comments and surveyed 873 programmers [S23].</li>
  <li>What the study finds review delivering instead is knowledge transfer, team awareness and shared code ownership [S23].</li>
  <li>Low review coverage and participation are estimated to produce up to two and five additional post-release defects [S24].</li>
</ul>

Outcomes come next.

---

<p class="kicker">Part VI · Evidence</p>

<h2>The outcome evidence cuts the other way</h2>

<p class="lede">Counting what reviewers write is not the same as measuring what review prevents.</p>

The two-and-five estimate came from measuring components rather than comments. It set how much review each component received against how many defects that component showed after release.

So the honest claim is narrower than either headline. Review spreads understanding of the change: afterwards a second person can alter that code without asking the author. It also catches some defects, and only up to a size limit.

Note:

<ul>
  <li>Low review coverage and participation are estimated to produce up to two and five additional post-release defects respectively [S24].</li>
  <li>Review is a bounded-capacity comprehension activity whose dominant output is shared understanding [V40] [T5].</li>
  <li>Its measured defect yield degrades sharply once a change exceeds what one person holds in one sitting [V40].</li>
</ul>

Say the takeaway aloud.

---

<p class="kicker">Part VI · Mechanism</p>

<h2>Review is comprehension, and comprehension is the bottleneck</h2>

<p class="lede">A reviewer does not fail to find a defect through carelessness. Finding one requires understanding the change.</p>

The same study found that code and change understanding is the key aspect of reviewing. It also found that 798 of 873 surveyed programmers confirmed that unfamiliar files take longer.

This is the mechanism underneath every rule about small changes. Small changes are not tidier. They are comprehensible.

Note:

<ul>
  <li>Code and change understanding is the key aspect of code reviewing [S23].</li>
  <li>91% of the surveyed programmers confirmed that unfamiliar files take longer to review [S23].</li>
  <li>Every size rule in this part follows from the comprehension limit rather than from taste.</li>
</ul>

Mechanism before numbers.

---

<p class="kicker">Part VI · Limits</p>

<h2>Two numbers, one source, and they are not in conflict</h2>

<div class="stats">
<div><div class="stat">100–300</div><div class="stat-cap">lines in 30 to 60 minutes, the authors' own advice</div></div>
<div><div class="stat">400</div><div class="stat-cap">lines, the ceiling, because more overwhelms a reviewer</div></div>
</div>

A ten-month study of 2,500 reviews covering 3.2 million lines produced both figures. The first pairs a size with a time. The second is a size limit on its own.

Time carries a separate finding in the same study. Reviewers found defects at a roughly constant rate through the first 60 minutes, after which the rate levelled off. No reviewer found a defect after 90 minutes.

Note:

<ul>
  <li>The advice is to review between 100 and 300 lines at a time and spend 30 to 60 minutes on it [S25].</li>
  <li>Lines under review should be under 200 and not exceed 400, because larger changes overwhelm reviewers [S25].</li>
  <li>The study ran for ten months and covered 2,500 reviews of 3.2 million lines of code [S25].</li>
  <li>Defects appeared at relatively constant rates through the first 60 minutes, after which the rate levelled off [S25].</li>
  <li>In no case is a defect discovered after 90 minutes, which is a finding separate from the line ceiling [S25].</li>
</ul>

One source, two figures.

---

<p class="kicker">Part VI · Queues</p>

<h2>A branch is old because it is waiting</h2>

<p class="lede">Review latency does not merely delay a change. It grows the change it then fails to review.</p>

A change sits waiting for a reviewer. The author has more work that depends on it, so the commits go onto the same branch rather than a new one.

The change that eventually reaches a reviewer is therefore larger than the one that was submitted. Past 400 lines the review measurement found no further defects, so the waiting produces the size that review can no longer absorb.

Note:

<ul>
  <li>What developers usually do is add more commits to the waiting change, which turns it into a giant code change [V41].</li>
  <li>The size ceiling means the enlarged change is past the point where defects are found [S25].</li>
  <li>Branch duration is largely a proxy for size, which connects this directly to the Part V evidence [V35].</li>
</ul>

Parts V and VI meet.

---

<p class="kicker">Part VI · The Git limitation</p>

<h2>Git cannot record that one branch depends on another</h2>

<p class="lede">A commit records its parents. Nothing records its children.</p>

A stack is one change split into a chain of branches, each built on the branch below it. There is no object that says branch B is stacked on branch A. Nothing in the repository records that editing the bottom of a chain invalidates every layer above it.

Every tool that offers stacked review closes that gap the same way: by keeping each branch's intended parent outside the commit graph. Every such tool therefore has a state that can disagree with the repository.

Note:

<ul>
  <li>A commit records its parents and records no child [V8].</li>
  <li>No Git object says that one branch is stacked on another [V42].</li>
  <li>Each stacking tool keeps the dependency outside the graph, so its state can drift [V42].</li>
</ul>

The only Git claim here.

---

<p class="kicker">Part VI · Stacking</p>

<h2>Two operations, under many names</h2>

<div class="kv">
<div class="pair"><div class="k">Retarget</div><div class="v">Point each change's comparison base at the change below it, so its difference shows only its own layer.</div></div>
<div class="pair"><div class="k">Restack</div><div class="v">After any edit to a lower layer, replay every layer above it and move the intermediate branch tips.</div></div>
</div>

Interactive rebase has carried the second operation since Git 2.38, as `git rebase -i --update-refs`. On 30 July 2026 GitHub put stacked pull requests into public preview, which is a trial release rather than the finished feature.

Note:

<ul>
  <li>A stack is a chain of changes, each targeting the branch of the one below it [S37].</li>
  <li>The feature is rolling out in public preview to all repositories rather than generally available [S37].</li>
  <li>Git 2.38 taught <code>git rebase -i</code> to update branches whose tip appears in the rebased range, with <code>--update-refs</code> [S47].</li>
  <li>No source consulted here documents how a stack behaves inside a merge queue.</li>
  <li>Landing part of a stack merges lower layers while the ones above stay open and rebase automatically [S37].</li>
</ul>

State the preview status.

---

<p class="kicker">Part VI · Stacking</p>

<h2>Squash-merging one layer strands the layers above it</h2>

<p class="lede">The Part II squash result, applied to a chain.</p>

Squash the bottom layer and the trunk gains one commit with one parent. The original branch is not an ancestor of it.

The layer above still sits on the old version of the layer below. Its merge base falls back to the root, and it re-presents content that is already integrated.

Note:

<ul>
  <li>The layer above a squash-merged layer finds its merge base back at the root and re-presents integrated content [V43].</li>
  <li>The squash commit carries the same tree, and the side branch is not its ancestor [V14].</li>
  <li>The vendor documents the same hazard for ordinary sequential pull requests [S36].</li>
</ul>

Ask them first.

---

<p class="kicker">Part VI · What changes next</p>

<h2>Review when nobody wrote the code</h2>

<p class="lede">The measured output of review assumes a person wrote the change and a person absorbs the comment.</p>

If a language model produced the change, nobody on the team ever held the reasoning behind it, so there is no understanding to transfer. Catching defects is then the only function review has left, and the measured size and time limits bound that function.

The measurement to watch is where the effort goes. In one 2026 developer survey the work moved from writing code to verifying it, rather than disappearing. That is an open question, not a settled result.

Note:

<ul>
  <li>The work moved from writing to verifying rather than disappearing [V48].</li>
  <li>The knowledge-transfer output assumes a human author and a human reader, and neither premise is guaranteed.</li>
  <li>No source consulted here measures review effectiveness on generated code specifically.</li>
</ul>

Leave it open.

---

<p class="kicker">Part VI · Decision</p>

<h2>One pull request, or a stack?</h2>

<div class="rows">
<div class="row">
<div class="num">1</div>
<div class="term">Under 300 lines</div>
<div class="desc">One change. A stack costs coordination it does not need.</div>
</div>
<div class="row">
<div class="num">2</div>
<div class="term">Separable layers</div>
<div class="desc">Stack it, so each layer is reviewed against the one below.</div>
</div>
<div class="row">
<div class="num">3</div>
<div class="term">Landing a stack</div>
<div class="desc">Merge bottom upwards. Squash an intermediate layer and the rest re-conflicts.</div>
</div>
</div>

Note:

<ul>
  <li>The recommendation is 100 to 300 lines at a time, and the ceiling is 400 [S25].</li>
  <li>Landing part of a stack merges lower layers first, and the layers above rebase and retarget [S37].</li>
  <li>Squash-merging an intermediate layer strands the layers above it [V43].</li>
</ul>

Apply it to one change.

---

<h1>Integration, delivery, deployment</h1>

Three different practices, one abbreviation, and a branching strategy that depends on which one you do.

Note:

<ul>
  <li>Part divider. Part VII closes the loop, because the branching choice in Part V is bought by this practice.</li>
</ul>

---

<p class="kicker">Part VII · Separation</p>

<h2>Three practices wearing one abbreviation</h2>

<div class="kv">
<div class="pair"><div class="k">Continuous integration</div><div class="v">A property of how a team uses version control.</div></div>
<div class="pair"><div class="k">Continuous delivery</div><div class="v">A property of the artefact the pipeline produces.</div></div>
<div class="pair"><div class="k">Continuous deployment</div><div class="v">A policy about what happens to an artefact that passes.</div></div>
</div>

The pipeline is the automated sequence of builds and tests that every change goes through.

Each one requires the one before it. A team can integrate continuously and release twice a year. A team cannot deploy continuously without first being able to deliver continuously.

Note:

<ul>
  <li>Integration is a property of version-control use, delivery a property of the artefact, deployment a policy [V44].</li>
  <li>Continuous deployment requires continuous delivery first [S32].</li>
  <li>The other link in the chain is not stated by any source consulted here, and follows from the definitions.</li>
  <li>The three are routinely collapsed into one abbreviation, which hides the dependency order.</li>
</ul>

Leave three on the board.

---

<p class="kicker">Part VII · Integration</p>

<h2>Continuous integration is a frequency claim</h2>

<p class="lede">It is about how often people merge, not about which server runs the build.</p>

Each member merges their changes into the shared codebase together with their colleagues' changes at least daily. Each of those integrations is verified by an automated build that includes tests.

Two clauses, both routinely dropped. At least daily makes it a claim about cadence. Verified by an automated build including tests makes it a claim about a self-testing build.

Note:

<ul>
  <li>Each member merges into the codebase with colleagues at least daily [S31].</li>
  <li>Each integration is verified by an automated build including tests [S31].</li>
  <li>Running a build server does not establish the practice, because the cadence clause is separate [S31].</li>
</ul>

Say it plainly.

---

<p class="kicker">Part VII · Integration</p>

<h2>Three questions that settle it</h2>

<div class="rows">
<div class="row">
<div class="num">1</div>
<div class="term">Daily</div>
<div class="desc">Is everyone pushing to the trunk every day, rather than to feature branches?</div>
</div>
<div class="row">
<div class="num">2</div>
<div class="term">Every commit</div>
<div class="desc">Does every commit trigger a run of the unit tests?</div>
</div>
<div class="row">
<div class="num">3</div>
<div class="term">Ten minutes</div>
<div class="desc">When the build breaks, is it typically fixed within ten minutes?</div>
</div>
</div>

The author of the test reports that in his experience fewer than 20% of teams who believe they are doing this can pass it. That figure is one practitioner's recollection, not a measurement.

Note:

<ul>
  <li>The three questions cover daily trunk pushes, unit tests on every commit and a ten-minute fix [S34].</li>
  <li>Less than 20% of teams that think they are doing CI can actually pass the test, in the author's stated experience [S34].</li>
  <li>Using a tool does not mean doing the practice [S34].</li>
</ul>

One anecdote, labelled.

---

<h2>The same practice under two names</h2>

<p class="lede">The branching choice in Part V and the integration practice here are one decision.</p>

The author of the canonical definition writes that this practice is called continuous integration, or in some circles trunk-based development.

That is why the preconditions match. Merging daily requires a trunk that stays shippable, which requires automated checks on every commit, which is the healthy-branch rule from Part V.

Note:

<ul>
  <li>The practice is called continuous integration, or in some circles trunk-based development [S31].</li>
  <li>A healthy branch means automated checks on each commit so that there are no defects on the branch [S30].</li>
  <li>Branching strategy therefore functions as a diagnostic for test maturity rather than an independent choice.</li>
</ul>

Answer question one first.

---

<p class="kicker">Part VII · Delivery</p>

<h2>Continuous delivery is a property of the artefact</h2>

<p class="lede">The team builds the software so that it can go to production at any time. Production is the running system users depend on, and nobody has to release to it.</p>

The ThoughtWorks continuous delivery working group reduced it to four observable indicators.

<ul>
  <li>The software is deployable throughout its life.</li>
  <li>The team prioritises keeping it deployable over new features.</li>
  <li>Anyone can get fast automated feedback on production readiness.</li>
  <li>Any version deploys to any environment on demand.</li>
</ul>

The acceptance test is social. A sponsor could ask for the current development version to go to production at a moment's notice, and nobody would panic.

Note:

<ul>
  <li>Continuous delivery means the software can be released to production at any time [S32].</li>
  <li>The four indicators include prioritising deployability over new features [S32].</li>
  <li>The acceptance test is that a deployment request at a moment's notice would not cause alarm [S32].</li>
</ul>

Indicator two is expensive.

---

<p class="kicker">Part VII · Deployment</p>

<h2>Continuous deployment is a policy</h2>

<p class="lede">Every change that passes the pipeline goes to production automatically.</p>

Nothing about the artefact changes. What changes is who decides to release it, and the answer becomes nobody.

That is why it sits last in the dependency order. Releasing an artefact the team does not trust automatically reaches an outage faster than it reaches delivery performance.

Note:

<ul>
  <li>Continuous deployment means every change goes through the pipeline and is automatically put into production [S32].</li>
  <li>It requires continuous delivery first [S32].</li>
  <li>The distinction is the release decision, not the artefact [V44].</li>
</ul>

Ask about their project.

---

<p class="kicker">Part VII · The precondition question</p>

<h2>Feature flags follow from the release policy</h2>

<p class="lede">Two sources disagree about whether flags are required. The disagreement dissolves along the delivery and deployment line.</p>

The goal is to separate the technical decision to deploy from the business decision to launch a feature. Where releasing is automatic, the team must hide unfinished work at run time. That needs a feature flag, or a dark launch, which ships the code with nothing calling it yet.

Where a person still picks the release moment, that person is the gate, and the flag is optional. The author of the pattern says exactly this: flags are only really necessary when practising continuous deployment.

Note:

<ul>
  <li>Flags are needed when the release policy is automatic, and optional when a human still picks the release moment [V45].</li>
  <li>The goal is to separate the technical deployment decision from the business launch decision [S33].</li>
  <li>The author states that a feature flag is only really necessary when practising continuous deployment [S34].</li>
</ul>

Chosen on the release axis.

---

<p class="kicker">Part VII · The measurement</p>

<h2>Deployment frequency stands in for batch size</h2>

<p class="lede">Batch size is how much change ships at once. It cannot be counted directly, so the number of releases stands in for it.</p>

A smaller change fits inside the 400-line review limit from Part VI, and reverting it removes less than reverting a large one. Reducing the cost of a deployment is what makes smaller batches affordable at all.

The proxy is under strain. The 2024 survey report states that it is possible, even likely, that change sizes are growing, and it did not measure change size. Treat the proxy as a proxy.

Note:

<ul>
  <li>Reducing setup and deployment cost enables smaller release batches [V49].</li>
  <li>The report states that it is possible, even likely, that changelists are growing in size [V47].</li>
  <li>The report reasoned from a prior finding rather than measuring change size [V47] [T6].</li>
</ul>

Say the takeaway aloud.

---

<p class="kicker">Part VII · Decision</p>

<h2>Diagnose what a team actually practises</h2>

| What to look at | The question | Which practice |
|---|---|---|
| Merge cadence | Daily to the trunk, or branches that live for weeks? | Integration |
| The artefact | Could any commit that passed the pipeline ship now? | Delivery |
| The trigger | Does passing the pipeline release, or does a person decide? | Deployment |

Fowler's definitions supply all three questions. A team that answers no to the first is not doing any of the three, whatever its pipeline is called.

Note:

<ul>
  <li>The cadence question is the definition of continuous integration [S31].</li>
  <li>The artefact question is the definition of continuous delivery [S32].</li>
  <li>The trigger question separates deployment from delivery [S32].</li>
  <li>A team failing the cadence question is doing none of the three, because each practice builds on the one before.</li>
</ul>

Diagnose one public project.

---

<h2>Takeaways, restated</h2>

<div class="rows">
<div class="row">
<div class="num">1</div>
<div class="term">Objects and pointers</div>
<div class="desc">A commit, rebuilt by hand. A branch is a file holding a hash.</div>
</div>
<div class="row">
<div class="num">2</div>
<div class="term">One merge function</div>
<div class="desc">A squash kept the tree and lost the ancestry.</div>
</div>
<div class="row">
<div class="num">3</div>
<div class="term">Trade-offs, not laws</div>
<div class="desc">Locking, per-path access, patch identity. Each has a rival design.</div>
</div>
<div class="row">
<div class="num">4</div>
<div class="term">Branch lifetime</div>
<div class="desc">Two days, one author, checks on every commit.</div>
</div>
<div class="row">
<div class="num">5</div>
<div class="term">What review produces</div>
<div class="desc">Understanding first, defects second, none found after 90 minutes.</div>
</div>
<div class="row">
<div class="num">6</div>
<div class="term">Three practices, one name</div>
<div class="desc">Cadence, artefact, trigger. Ask all three.</div>
</div>
</div>

Note:

<ul>
  <li>The same six claims, now paid for by the demonstrations and the evidence [T1] [T2] [T3] [T4] [T5] [T6].</li>
</ul>

Name the earning slide.

---

<p class="kicker">Closing</p>

<h2>What follows from the object graph</h2>

<p class="lede">The thesis, stated again now that every part of it has been shown.</p>

Git gives you a content-addressed object graph and a way to move pointers into it. The object model has been stable since 2005.

Branching strategy, pull requests, code review and delivery practice are policy your team layered on top. They are choices, they are contested, and the evidence for them is weaker than the evidence for the graph. The honest limit: Git does ship hooks, so it supplies the enforcement mechanism and sets no policy.

Note:

<ul>
  <li>A Git repository is objects plus refs, and every command adds objects or moves refs [V2].</li>
  <li>Pull requests, code review and continuous integration are not Git concepts [V10].</li>
  <li>Git ships hooks that can enforce a fast-forward-only policy, so the mechanism is Git and the policy is yours [S14].</li>
</ul>

Two sentences only.

---

<p class="kicker">Closing</p>

<h2>What this course leaves open</h2>

<div class="gaps">
<div class="gap">
<div class="dot">•</div>
<div class="gap-term">Forge-specific work</div>
<div class="ref">Part VI</div>
<div class="gap-desc">The mechanism and the research, not one vendor's interface or its merge queue.</div>
</div>
<div class="gap">
<div class="dot">•</div>
<div class="gap-term">The wider remote surface</div>
<div class="ref">Part II</div>
<div class="gap-desc">Multiple remotes, forks, custom refspecs, and configuring the integration step.</div>
</div>
<div class="gap">
<div class="dot">•</div>
<div class="gap-term">History rewriting</div>
<div class="ref">Part II</div>
<div class="gap-desc">Interactive rebase corner cases, filtering a repository, submodules, work trees.</div>
</div>
<div class="gap">
<div class="dot">•</div>
<div class="gap-term">Spending the graph</div>
<div class="ref">Part II</div>
<div class="gap-desc"><code>git bisect</code> searches the ancestry you now understand. It was not covered here.</div>
</div>
</div>

Note:

<ul>
  <li>Each item is named rather than deferred, because no later topic in this course covers it.</li>
  <li>The reflog was covered and bisect was not, and both read the same ancestry relation.</li>
</ul>

Gaps named, not hidden.

---

<p class="kicker">Closing</p>

<h2>Where to read next</h2>

<div class="rows">
<div class="row">
<div class="num">1</div>
<div class="term">The object model</div>
<div class="desc">Pro Git, chapter 10. The plumbing sequence from Part I, in full.</div>
</div>
<div class="row">
<div class="num">2</div>
<div class="term">The short version</div>
<div class="desc">The MIT Missing Semester lecture. One hour, and it states the model as type declarations.</div>
</div>
<div class="row">
<div class="num">3</div>
<div class="term">The graph, visually</div>
<div class="desc">Learn Git Branching. A browser sandbox that draws the commit graph.</div>
</div>
<div class="row">
<div class="num">4</div>
<div class="term">Why it is awkward</div>
<div class="desc">A conceptual-design analysis of Git's interface. Read it once the object model is in place.</div>
</div>
</div>

Voluntary homework comes in three steps. Rebuild a commit by hand. Write all three predictions down. Then run the Part II demonstration.

Note:

<ul>
  <li>Chapter 10 of Pro Git carries the plumbing sequence used in Part I [S1] [S2].</li>
  <li>The Missing Semester lecture gives the data model as type declarations [S17].</li>
  <li>Learn Git Branching is a browser sandbox with paced exercises that draws the commit graph [S45].</li>
  <li>The conceptual-design paper is best read after the object model is in place [S21].</li>
</ul>

Set the voluntary homework.

---