Worked examples — Git operations — branch, merge, rebase, cherry-pick, stash, bisect

---

The scenario matrix

Every worked example below is tagged with the cell it covers. Think of each row as a "quadrant" of Git behaviour — just like signs of $A_x,A_y$ pick a quadrant for an angle.

#	Case class	The deciding question	Degenerate / limiting edge
A	Fast-forward merge	Is the target a direct ancestor? (no divergence)	zero commits between = "already up to date"
B	Three-way merge, clean	Diverged, but different files/lines touched	both sides identical edit → auto-resolved
C	Three-way merge, CONFLICT	Diverged AND same region changed differently	one side deletes, other edits
D	Rebase (linearise)	Replay my commits on a new base	rebasing shared commits (forbidden)
E	Cherry-pick	Copy one commit's diff elsewhere	context differs → conflict
F	Stash	Shelve dirty tree to switch context	nothing to stash (clean tree)
G	Bisect	Binary search for first bad commit	$N=1$, and the $\lceil {\log }_{2}N\rceil$ count
H	Word problem + exam twist	Combine several cells under time pressure	duplicate-change trap (pick then merge)

Let me build the vocabulary once, then never assume it again.

---

Cell A — Fast-forward merge (no divergence)

1. Locate the merge base $B$. Since feature grew directly out of $M_2$ and main never moved, $B=M_2$ = the current tip of main. Why this step? Merge always starts by finding the last shared commit — that decides FF vs three-way.
2. Check ancestry. Is main's tip an ancestor of feature's tip? Yes — look at the figure: $M_2\to F_1\to F_2$ is one straight chain. Why this step? If the target is a direct ancestor there is nothing to reconcile — no divergence means no new information to combine.
3. Slide the pointer. Git just moves main from $M_2$ forward to $F_2$. No new commit is made. Why this step? Creating a merge commit would add a redundant node with only one meaningful parent — pointless.

Verify: commits on main after = commits before ($M_0,M_1,M_2$) plus $F_1,F_2$ = 5 commits, 0 merge commits. Number of new commits created by the merge = $0$. ✓ (checked in VERIFY)

---

Cell B — Three-way merge, clean (diverged, no overlap)

1. Find $B$. The last commit both share (the fork point in the figure). Why this step? The Three-way merge algorithm compares $B\to O$ and $B\to T$; we need $B$ first.
2. Apply the per-line rule for style.css. Here $O\ne B$ (we changed it) but $T=B$ (they did not). $\text{result}=O\text{since }T=B$ Why this step? If only one side moved away from the base, that side's version is the unique answer.
3. Apply the rule for app.js. Now $O=B$, $T\ne B$ → result $=T$. Why this step? Symmetric to step 2 — the other side is the only one that changed.
4. Write the merge commit with two parents $O$ and $T$. Why this step? Divergence really happened, so history records the join (unlike cell A).

Verify: each file falls in a single-changer branch of the piecewise rule, so CONFLICT is never reached. Files auto-merged = 2, conflicts = 0, merge commit parents = 2. ✓

---

Cell C — Three-way merge, CONFLICT (same region, both differ)

1. Evaluate the rule. $B$ = 1, $O$ = 2, $T$ = 3. Test the CONFLICT clause: $O\ne B(2\ne 1),T\ne B(3\ne 1),O\ne T(2\ne 3)\Rightarrow \text{CONFLICT}$ Why this step? A conflict is not random — it is exactly the cell where both sides moved the same region to different values. Git refuses to guess.
2. Read the markers. Git writes both versions between <<<<<<</=======/>>>>>>>. Why this step? It hands you the raw data (Conflict resolution) so a human decides intent.
3. Resolve, then git add app.js && git commit. Why this step? Staging tells Git "this region is settled"; the commit becomes the two-parent merge.

Verify: plug $B=1,O=2,T=3$ into the piecewise function → CONFLICT branch is the only true one. ✓

---

Cell D — Rebase to linearise (and the forbidden edge)

1. Find merge base $M$ of feature and main (the fork commit). Why this step? Rebase only replays commits after the base — everything before is already shared.
2. Save the diffs of $F_1,F_2$ (patches relative to their parents). Why this step? Rebase re-applies changes, not whole snapshots — same idea as diffs.
3. Move feature to main's tip $N_1$, replay: $F_1\to F_1^{\prime }$, $F_2\to F_2^{\prime }$ on top of $N_1$. Why this step? This produces a linear history $M\to N_1\to F_1^{\prime }\to F_2^{\prime }$ with new SHAs (new parents = new content-address, see Immutability and content-addressable storage).

Verify: commit count on feature stays $2$ (replayed 1-for-1); SHAs change because parent changed. New tip's ancestor count = base + main gain + feature commits = $\text{(commits}\le M)+1+2$. If $M$ had 3 commits behind it (incl. itself), total = $3+1+2=6$. ✓

---

Cell E — Cherry-pick one commit (and its context edge)

1. Compute the patch $\text{parent}(C)\to C$. Why this step? Cherry-pick copies the diff of a single commit, nothing before it.
2. Apply the patch on main's tip, creating a new commit $C^{\prime }$ (new SHA). Why this step? Same change, different history location → content-address differs.
3. If surrounding code differs → conflict, resolve exactly like cell C. Why this step? The patch's context lines may not match main; then a human must place it.

Verify: commits copied = exactly $1$; main's commit count rises by $1$. ✓

---

Cell F — Stash, including the empty (degenerate) case

1. git stash saves dirty tree + index as a hidden commit on a stack, reverts to clean HEAD. Why this step? Git blocks branch switches that would overwrite changes; stash = safe shelf.
2. Switch, fix, switch back, then git stash pop = apply + drop. Why this step? pop reapplies your work and removes the entry — one clean round-trip.
3. Degenerate case: if the tree was clean, git stash reports "No local changes to save" and creates 0 stash entries. Why this step? There is literally nothing to shelve — the stack is untouched.

Verify: clean pop → stack goes $1\to 0$ entries. Empty-tree stash → stack stays at $0$. ✓

---

Cell G — Bisect: binary search and the ${\log }_2$ count

1. Mark endpoints: git bisect bad (now), git bisect good v1.0 (known good). Why this step? Binary Search needs a range with a known-good low end and known-bad high end.
2. Git checks out the midpoint; you test and answer good/bad. Each answer discards half the range. Why this step? Halving is why the cost is logarithmic, not linear.
3. Count the tests. Each test does $N\to N/2$. Halvings to reach 1: $\text{tests}\approx \lceil {\log }_{2}N\rceil =\lceil {\log }_{2}1000\rceil =\lceil 9.97\rceil =10$ Why this step? $2^{10}=1024\ge 1000$, so 10 halvings cover 1000 commits.
4. Degenerate $N=1$: $\lceil {\log }_{2}1\rceil =\lceil 0\rceil =0$ extra tests — the single suspect is the answer.

Verify: $\lceil {\log }_{2}1000\rceil =10$; linear search would need up to $1000$. And $\lceil {\log }_{2}1\rceil =0$. ✓

---

Cell H — Word problem + exam twist (combines cells)

1. Cherry-pick $P$ → $P^{\prime }$ on main (cell E). Ships only the fix, not the 40 commits. Why this step? You need the patch live without releasing unfinished work.
2. Later, main and dev have diverged ($P^{\prime }$ on main; $P$ + 40 on dev) → three-way merge (cell B/C). Why this step? Both branches moved past their base → divergence → merge commit with 2 parents.
3. Twist resolved: the change from $P$ now exists as both $P$ and $P^{\prime }$. Modern Git often patch-IDs them equal and skips a redraw, but if surrounding lines shifted you get a cell-C conflict on that region. Why this step? This is the duplicate-change trap — the reason cherry-pick + later merge is delicate.

Recall Which cell was each command?

cherry-pick $P$ ::: Cell E (copy one commit) merge dev into main ::: Cell B or C (three-way, divergence) the "appears twice" risk ::: the duplicate-change trap of Cell E

Verify: merge in step 2 has parents = $2$; patches carrying the same change = $2$ ($P$ and $P^{\prime }$). ✓

---