Visual walkthrough — Git workflows — Gitflow, trunk-based development

This is the visual companion to Git workflows — Gitflow, trunk-based development. It leans on Branching and Merging (what a merge even is) and connects to Continuous Integration and Feature Flags (the tools that let you keep branches short).

---

Step 1 — What is a "shared branch" and what is "drift"?

WHAT. Picture one long horizontal line: the trunk — the shared branch everyone builds on (call it main). Time runs left to right. Every time someone else on the team lands a change, a dot appears on that line.

WHY. Before any formula, we need the one physical quantity that causes conflicts: other people's changes accumulating while you are away. If nothing ever changed on the trunk, your merge could never conflict. So the story starts by watching the trunk move.

PICTURE. In the figure, the blue line is the trunk. You branch off at the point marked "you start" (orange). While you work, three grey dots land on the trunk — teammates' commits. The gap between where you left and where the trunk now sits is the drift: how far the world moved without you.

---

Step 2 — Turn "how long you were away" into a count of changes

WHAT. We introduce two plain-language quantities:

• $\lambda$ (the Greek letter "lambda") = the arrival rate: how many conflict-causing changes land on the trunk per day. If teammates merge 5 changes a day, $\lambda =5$.
• $T$ = the lifetime of your branch, measured in days. Branch you kill in 2 hours ⇒ $T\approx 0.08$; branch you keep for a week ⇒ $T=7$.

Multiply them:

$n=\underset{\text{changes per day}}{\underbrace{\lambda }}\times \underset{\text{days alive}}{\underbrace{T}}=\underset{\text{total changes you must integrate}}{\underbrace{\lambda T}}$

WHY this multiplication and not something else? Rate times time is just counting. If cars pass at 5 per minute and you wait 3 minutes, $5\times 3=15$ cars passed. Same logic: changes per day times days gives total changes. We need a count $n$ because probability, coming next, works on discrete "trials" — each change is one trial that might or might not collide with you.

PICTURE. The figure shows two branches of different lifetimes on the same trunk. The short orange branch ($T$ small) only overlaps 1 grey dot. The long red branch ($T$ large) overlaps 6 grey dots. Same rate $\lambda$, longer $T$, more dots to reconcile.

---

Step 3 — One change, one coin flip: the probability $p$

WHAT. Take a single teammate change. Either it touched lines of code that you also edited (collision → conflict) or it didn't (miss → no problem). Call the probability of a collision $p$. A number between 0 and 1: $p=0$ means "we never touch the same files", $p=1$ means "every change of theirs hits mine".

Then the probability that this one change misses you is:

$\underset{\text{miss}}{\underbrace{1-p}}=1-\underset{\text{hit}}{\underbrace{p}}$

WHY subtract from 1? A single change has only two outcomes — hit or miss — and their probabilities must add to the whole, which is $1$ (certainty). So $P(\text{miss})=1-P(\text{hit})$. This "complement" trick is the workhorse of the whole derivation: it's far easier to compute "everything missed" than "at least one hit".

PICTURE. A single coin: orange face = "hit your lines" (weight $p$), green face = "misses" (weight $1-p$). The two slices of the bar fill the whole width because together they are certain.

---

Step 4 — Independence lets us multiply the misses

WHAT. For your merge to be fully clean, every one of the $n$ changes must miss you. Change 1 misses AND change 2 misses AND … AND change $n$ misses. When events are independent — one change missing tells you nothing about whether the next misses — the probability of "all of them happen" is the product of their individual probabilities:

$P_{\text{clean}}=\underset{\text{change 1 misses}}{\underbrace{(1-p)}}\times \underset{\text{change 2 misses}}{\underbrace{(1-p)}}\times \cdots \times \underset{\text{change }n\text{ misses}}{\underbrace{(1-p)}}$

WHY multiply, and why "independent"? "AND" of independent events multiplies — this is the fundamental rule of probability. Think of two fair coins: chance of two heads is $\frac{1}{2}\times \frac{1}{2}=\frac{1}{4}$, not $\frac{1}{2}+\frac{1}{2}$. We assume independence because different teammates editing different features usually don't coordinate their collisions with you. (Where that assumption breaks — a shared hotspot file — $p$ itself climbs, which we handle in Step 7.)

PICTURE. A row of $n$ green boxes, each labelled $(1-p)$, chained by "×" signs — a probability "gauntlet" your branch must run. Every box you add shrinks the surviving green area.

---

Step 5 — Collapse the product into an exponent

WHAT. Multiplying the same number $(1-p)$ by itself $n$ times is raising it to the power $n$. That's the definition of an exponent:

$\underset{n\text{ copies}}{\underbrace{(1-p)\times (1-p)\times \cdots \times (1-p)}}=(1-p{)}^n$

Now substitute the count from Step 2, $n=\lambda T$:

$\boxed{P_{\text{clean}}(T)=(1-p{)}^{\lambda T}}$

WHY exponent notation? Because "the same factor, many times" is exactly what an exponent means — it's shorthand, nothing more mysterious. But that shorthand reveals the shape: $T$ now sits up in the exponent. A quantity in the exponent doesn't grow or shrink slowly — it does so exponentially. That single placement is the punchline of the whole page.

PICTURE. The chain of green boxes from Step 4 folds up into one tower $(1-p{)}^{\lambda T}$, and beside it the curve of $(1-p{)}^{\lambda T}$ against $T$ — a smooth cliff diving toward zero.

---

Step 6 — Flip it: the conflict probability

WHAT. "Clean" and "at least one conflict" are the only two outcomes for the whole merge, so again they sum to 1. Subtract:

$P_{\text{conflict}}(T)=1-P_{\text{clean}}(T)=1-(1-p{)}^{\lambda T}$

WHY the complement again? Computing "at least one of the $n$ changes hits me" directly is a nightmare (it could be exactly one, or two, or all $n$ — many cases). Computing "none hit me" is a single product. So we get the hard quantity for free by subtracting the easy one from 1. This is the same complement move from Step 3, now applied to the whole branch.

PICTURE. Two mirror curves on the same axes: green $P_{\text{clean}}$ sliding down from 1, red $P_{\text{conflict}}$ climbing from 0 — they always add to the dashed line at height 1.

---

Step 7 — Every edge and degenerate case

A formula you can't stress-test is a formula you don't understand. Walk the boundaries:

Case $T\to 0$ (kill the branch instantly — trunk-based ideal). $(1-p{)}^{\lambda \cdot 0}=(1-p{)}^0=1$, since anything to the power 0 is 1. So $P_{\text{conflict}}=1-1=0$. No time away ⇒ no drift ⇒ zero conflict. This is why TBD merges hours-old branches.

Case $T\to \infty$ (never merge — the Gitflow long-branch nightmare). Since $0<1-p<1$, raising it to a bigger and bigger power drives it toward 0. So $P_{\text{clean}}\to 0$ and $P_{\text{conflict}}\to 1$. Wait forever and a conflict is guaranteed.

Case $p=0$ (you never touch the same lines as anyone). $(1-0{)}^{\lambda T}=1^{\lambda T}=1$. $P_{\text{conflict}}=0$ regardless of $T$. Truly disjoint work never conflicts — a purely mathematical restatement of "modular code merges cleanly."

Case $p=1$ (every teammate change hits your lines — one shared hotspot file). $(1-1{)}^{\lambda T}=0^{\lambda T}=0$ (for any $\lambda T>0$). $P_{\text{conflict}}=1$. A guaranteed conflict the instant one other change lands. This is the pathological hotspot: no workflow saves you; you must split the file.

Case $\lambda =0$ (nobody else commits — you work alone). $(1-p{)}^{0\cdot T}=(1-p{)}^0=1$. $P_{\text{conflict}}=0$. Solo work never conflicts, no matter how long the branch lives — because there is no one to drift away from.

PICTURE. One chart, four curves for $p=0.02,0.05,0.1,0.3$, plus the flat $p=0$ line hugging the axis. All start at 0 when $T=0$ and rise toward 1 — steeper for larger $p$.

---

The one-picture summary

WHAT it compresses. One landscape: the trunk with drifting dots (Steps 1–2), the coin of miss-probability (Step 3), the chain-to-tower fold (Steps 4–5), and the rising red conflict curve with its $T\to 0$ and $T\to \infty$ anchors labelled (Steps 6–7). Read it left to right and you have re-derived the whole result.

Recall Feynman: explain the whole walkthrough to a 12-year-old

Imagine you and your friends are all decorating one big banner. You take a corner off to your desk to work on it. Every minute your friends stick new things onto the banner where you're not looking. Each new sticker has a small chance of landing exactly where you were going to draw — that's a clash. If you come back after one minute, only a sticker or two went up, so you probably clash with none: easy. But every extra minute is another sticker, another roll of the dice against you. The chance of "clashing with nobody" is like flipping a slightly-unfair coin once per sticker and needing every flip to say "safe" — and needing many flips to all say "safe" gets hopeless fast. So: come back quickly (short branch) and you almost never clash; stay away for a week and a clash is basically guaranteed. That's the whole formula.

Recall Forecast-then-verify

Q: In $P_{\text{clean}}=(1-p{)}^{\lambda T}$, which symbol sits in the exponent and why does that matter? A: $\lambda T$ (the change count) — being in the exponent means clean-merge probability decays exponentially in branch lifetime.

Q: What does $P_{\text{conflict}}$ equal when $T\to 0$, and what real practice does that justify? A: $0$; it justifies trunk-based development's hours-long branches.

Q: If $\lambda =0$ (you code alone), what is $P_{\text{conflict}}$ for any $T$? A: $0$ — no teammates means no drift, so no conflicts however long the branch lives.

---

See also: Pull Requests and Code Review (how the merge actually happens), Feature Flags (how to keep $T$ tiny even for big features), and DORA Metrics (which measure exactly this integration speed in the real world).