Git workflows — Gitflow, trunk-based development: Worked examples

Definition What kind of number is the exponent

$λ T$ ? Read $λ T$ as "the average number of conflict-causing changes that arrived while your branch was alive." It is an expected count, not a fixed integer. Concretely, imagine each change landing on the trunk as a random event ticking along at an average rate of $λ$ per day (a Poisson arrival model — random, independent little events spread over time). Over $T$ days the average number that shows up is $λ T$ , and this average is a real number: 2 changes/day over half a day averages $1$ , but 6/day over $0.71$ days averages $4.28$ — a perfectly meaningful average even though you can never see "4.28 changes" on any single day.

Why the exponent is allowed to be a real (non-integer) number. For a whole number $n$ , $(1 - p)^{n}$ is just $(1 - p)$ multiplied by itself $n$ times — "all $n$ changes miss you." To let $n = λ T$ be any real number we use the standard extension of powers to real exponents, $(1 - p)^{x} = e^{x l n (1 - p)}$ (the same rule that lets you write $2^{1.5}$ ). This turns our discrete "multiply survival for each change" into a smooth continuous approximation — a curve you can read off at any $T$ , not only at whole days. The domain is therefore $λ \geq 0, T \geq 0, 0 \leq p \leq 1$ , so $λ T \geq 0$ and the base $1 - p \in [0, 1]$ . When we want a plain integer count (e.g. "exactly 40 changes"), we round $λ T$ ; when we want the smooth risk curve, we keep it real. Both are the same formula viewed at different resolutions.

The scenario matrix

Think of a workflow as a machine with inputs (how long a branch lives, how busy the trunk is, whether the code is finished) and outputs (does it merge cleanly? where does the fix go? what version tag?). Every row below is a class of input the real world hands you. If we work one example per row, you never meet an unshown case.

#	Case class	The "sign / limit" it probes	Example
A	Short-lived branch, quiet trunk	small $T$ , small $λ$ → $P \to 0$	Ex 1
B	Long-lived branch, busy trunk	large $T$ , large $λ$ → $P \to 1$	Ex 2
C	Degenerate: $T = 0$ or $λ = 0$	zero input → guaranteed clean	Ex 3
D	Degenerate: $p = 1$ or $p = 0$	max-collision and no-collision inputs	Ex 3
E	Gitflow hotfix — where does the fix land?	routing across two homes	Ex 4
F	Gitflow release stabilization	who fixes bugs, `develop` vs `release/*`	Ex 5
G	TBD with feature flag — deploy ≠ release	incomplete code shipped safely	Ex 6
H	Real-world word problem	pick a number of daily integrations	Ex 7
I	Exam twist — compare two strategies numerically	which branch policy wins?	Ex 8

Prerequisite ideas we lean on: Branching and Merging, Continuous Integration, Feature Flags, Pull Requests and Code Review, Semantic Versioning.

Figure 1 (below) is our map of this whole table. The horizontal axis is branch lifetime $T$ and the vertical axis is trunk busyness $λ$ . The orange corner (bottom-left) is cells A and C — short branches on a quiet trunk, where risk collapses toward $0$ . The magenta corner (top-right) is cells B and D — long branches on a busy trunk, where risk climbs toward $1$ . The violet box is cell G: a feature flag lets you merge daily so you keep pulling yourself back into the safe corner even while building something large. Read the whole page as a journey between these two corners.

Figure — Git workflows — Gitflow, trunk-based development

Example 1 — Cell A: short branch, quiet trunk

Step 1 — count the diverging changes. $n = λ \cdot T = 2 \times 0.5 = 1.$ Why this step? $P_{conflict}$ depends on how many independent chances to collide accumulated while you were away. That count is $n = λ T$ : rate × time = expected number of arrivals. Half a day at 2/day averages exactly 1 change.

Step 2 — probability that the single change avoids you. $(1 - p) = 1 - 0.10 = 0.90.$ Why this step? Each change independently misses your lines with probability $1 - p$ . This is the "clean per-change" survival probability.

Step 3 — combine. $P_{clean} = (1 - p)^{n} = 0.9 0^{1} = 0.90, P_{conflict} = 1 - 0.90 = 0.10.$ Why this step? Independent events multiply, so all $n$ changes miss you with probability $(1 - p)^{n}$ . The complement is the conflict chance.

Verify: With exactly one incoming change, the conflict chance must equal $p$ itself ( $0.10$ ) — and it does. Units: $λ T$ = (changes/day)(days) = changes, dimensionless exponent. ✓

Example 2 — Cell B: long branch, busy trunk

Step 1 — count. $n = λ T = 5 \times 8 = 40$ diverging changes. Why? The branch drifted for 8 days on a busy trunk, so 40 independent collision chances (on average) piled up. This is exactly the "integration debt" the parent warned about.

Step 2 — clean survival. $(1 - p)^{n} = 0. 9^{40}$ . Why? All 40 must miss you for a clean merge.

Step 3 — evaluate. $0. 9^{40} \approx 0.01478, P_{conflict} = 1 - 0.01478 \approx 0.985.$ Why? We raise the per-change survival to the 40th power; repeated multiplication by 0.9 shrinks fast.

Verify: Compare with Example 1: same $p$ , but $n$ went $1 \to 40$ , and $P_{conflict}$ went $10% \to 98.5%$ . The exponential decay of $P_{clean}$ is the whole argument for short branches. ✓

Figure 2 (below) plots exactly these two examples on one curve. The horizontal axis is branch lifetime $T$ ; the vertical axis is $P_{conflict}$ . The lower orange curve is the quiet trunk ( $λ = 2$ ) and the upper magenta curve is the busy trunk ( $λ = 5$ ). The orange dot marks Example 1 ( $10%$ ) sitting low near the origin; the magenta dot marks Example 2 ( $98.5%$ ) pinned near the top. Notice how the curve bends upward fast then flattens as it presses against the dotted line at $1$ — that bending is the exponential decay of $P_{clean}$ made visible.

Example 3 — Cells C & D: the degenerate inputs

Step 1 — $T = 0$ . $n = λ \cdot 0 = 0$ , so $P_{clean} = (1 - p)^{0} = 1$ , hence $P_{conflict} = 0$ . Why? Anything raised to the power $0$ is $1$ , so $P_{conflict} = 0$ . Here is the plain reason why $(anything)^{0} = 1$ : the exponent counts how many incoming changes must miss you. If $n = 0$ , there are no changes to worry about, so the product of "everyone missed you" is an empty product — a product with no factors — and an empty product is defined to be $1$ (just as an empty sum is $0$ ). A merge that happens the instant you branched cannot conflict. This is the limit trunk-based chases.

Step 2 — $λ = 0$ . $n = 0 \cdot T = 0$ , again $P_{conflict} = 0$ for any $T$ . Why? If no conflict-causing change ever lands, branch lifetime is irrelevant — you could live 100 days safely. Same empty-product reasoning as Step 1: zero factors ⇒ $P_{clean} = 1$ . It confirms the danger is other people's changes, not time alone.

Step 3 — $p = 1$ , with $n = λ T = 5 \times 8 = 40$ . $(1 - 1)^{40} = 0^{40} = 0$ , so $P_{conflict} = 1$ . Why? If every single change touches your lines, then a single incoming change already guarantees collision. Because $n = 40 \geq 1$ there is at least one factor of $0$ , so the product is genuinely $0$ (this is a non-empty product, unlike Steps 1–2). The formula correctly saturates at certainty.

Step 4 — $p = 0$ , with $n = λ T = 5 \times 8 = 40$ . $(1 - 0)^{40} = 1^{40} = 1$ , so $P_{conflict} = 1 - 1 = 0$ . Why? If no change ever touches your lines, then no amount of drift can hurt you — even 40 incoming changes all miss, and $1^{40} = 1$ . This is the mirror image of Step 3: $p = 1$ forces certainty of conflict, $p = 0$ forces certainty of no conflict. Real life sits between the two.

Verify: All four are internal limits of the same formula — no special-casing needed. The three "safe" cases ( $T = 0$ , $λ = 0$ , $p = 0$ ) each make $P_{clean} = 1$ via an empty product or a base of $1$ ; only $p = 1$ with $n \geq 1$ forces a certain conflict. ✓

Example 4 — Cell E: the Gitflow hotfix routing

Step 1 — branch off main. git checkout main && git checkout -b hotfix/1.2.1. Why? Production is broken now. develop may hold half-finished features, so it is unsafe to build a fix on. main is the known-good live state.

Step 2 — merge into main, then tag.

git checkout main
git merge --no-ff hotfix/1.2.1
git tag v1.2.1

Why the tag? Under Semantic Versioning, a backward-compatible bug fix bumps only the PATCH number: 1.2.0 → 1.2.1. --no-ff keeps a merge commit so history shows a distinct hotfix boundary.

Step 3 — merge into develop too.

git checkout develop && git merge --no-ff hotfix/1.2.1

Why? "Hotfix Hits Both Homes." The next release is built from develop; if the fix is not there, the next release re-introduces the exact bug — a regression.

Verify: SemVer arithmetic — a PATCH bump takes MAJOR.MINOR.PATCH = 1.2.0 to 1.2.1, leaving MAJOR and MINOR unchanged. ✓

Example 5 — Cell F: stabilizing a Gitflow release

Step 1 — cut the release branch. git checkout develop && git checkout -b release/1.3.0. Why? This branch is feature-frozen: only bug fixes allowed. It buffers the release so develop stays free for new work.

Step 2 — fix the two bugs on release/1.3.0. Why? If you fix them on develop instead, (a) you cannot tell which fixes belong to this release, and (b) any unfinished feature freshly landing on develop would pollute the release. Stabilize on the frozen branch. This is the exact mistake the parent note flags.

Step 3 — start feature/reports off develop, in parallel. Why? Because the release lives on its own branch, develop is unblocked — new feature work proceeds concurrently with stabilization. See Branching and Merging.

Step 4 — finish: merge release/1.3.0 into main (tag v1.3.0) and back into develop. Why merge into develop too? So the two release bug fixes are not lost — same "both homes" logic as the hotfix.

Verify: Count the merge destinations: a release/* branch, like a hotfix/*, resolves into exactly 2 permanent branches. Both fixes are preserved via the develop merge — zero regressions. ✓

Example 6 — Cell G: trunk-based with a feature flag

Step 1 — strategy (a), the long branch. $n = 5 \times 6 = 30$ , so $P_{conflict}^{(a)} = 1 - 0. 9^{30} \approx 1 - 0.0424 = 0.9576.$ Why? 6 days of drift on a busy trunk = 30 accumulated collision chances → almost certain conflict. Since there is only one merge, this probability is the expected number of conflicting merges: $E_{a} = 0.9576$ .

Step 2 — strategy (b), per-merge probability. Each daily merge has $n = 5 \times 1 = 5$ : $P_{one day} = 1 - 0. 9^{5} \approx 1 - 0.5905 = 0.4095.$ Why? Feature Flags let you merge incomplete code that stays off in production, so each day's branch lives only 1 day → far fewer accumulated changes per merge.

Step 3 — pick the right metric: expected number of conflicts. Why not just compare the single worst merge? A per-merge probability is not comparable across strategies with different merge counts — (a) has 1 merge, (b) has 6. The fair, apples-to-apples metric is the expected number of conflicting merges across the whole 6-day job. By linearity of expectation (add the per-merge probabilities): $E_{b} = 6 \times 0.4095 = 2.457 conflicting merges .$

Step 4 — interpret both metrics honestly.

Expected count: $E_{a} \approx 0.96$ vs $E_{b} \approx 2.46$ . Strategy (b) actually has more conflict events.
Cost per event: each (b) conflict spans only 5 changes and is caught same-day by Continuous Integration; the single (a) conflict spans 30 changes — the "gluing disaster."

Why does (b) still win? The 2.46 expected conflicts in (b) are tiny, fresh, and cheap to resolve; the ~0.96 expected conflict in (a) is a large, stale, release-threatening merge. Count of conflicts ≠ cost of conflicts — and integration debt is about cost.

Verify: $0. 9^{30} \approx 0.0424$ so $P^{(a)} \approx 0.9576$ ; $0. 9^{5} \approx 0.5905$ so per-merge $\approx 0.4095$ ; $E_{b} = 6 \times 0.4095 = 2.457$ . The metric to trust for total workload is the expected count; the metric to trust for danger is the size of the worst conflict. ✓

Example 7 — Cell H: real-world word problem

Step 1 — set the target. Require $P_{conflict} (T) \leq 0.30$ , i.e. $1 - (1 - p)^{λ T} \leq 0.30 \Rightarrow (0.92)^{6 T} \geq 0.70.$ Why? We invert the model: given the output (30% max risk) we solve for the input $T$ .

Step 2 — take logarithms. Because $T$ is trapped in an exponent, the log is the tool that pulls it down: $6 T \cdot ln (0.92) \geq ln (0.70) .$ Why $ln$ ? $ln (a^{x}) = x ln a$ turns "unknown in the exponent" into "unknown multiplied by a number" — the only clean way to isolate $T$ . This is exactly why the exponent being a real number (from the definition callout) matters: $T$ can take any real value, and $ln$ works on the whole continuous curve.

Step 3 — solve for $T$ . Note $ln (0.92) < 0$ , so dividing flips the inequality: $T \leq \frac{l n ( 0.70 )}{6 l n ( 0.92 )} = \frac{- 0.35667}{6 \times ( - 0.08338 )} = \frac{- 0.35667}{- 0.50029} \approx 0.7129 days .$ Why flip? Dividing an inequality by a negative number reverses its direction — a standard algebra safeguard.

Verify: Plug back: $0.9 2^{6 \times 0.7129} = 0.9 2^{4.277} \approx 0.700$ , so $P_{conflict} \approx 0.300$ — exactly the cap. The "≤ 1 day" trunk-based rule is quantitatively justified here. ✓

Example 8 — Cell I: exam-style twist

Step 1 — Team G: one merge. $n = 4 \times 10 = 40$ , so $P_{G} = 1 - 0.9 5^{40} \approx 1 - 0.1285 = 0.8715.$ Expected conflicting merges $= 1 \times 0.8715 = 0.8715$ . Why? Team G merges exactly once, so its expected number of conflicting merges is simply that single merge's probability — there is nothing to add.

Step 2 — Team T: per-merge probability. Each of the 20 merges has $n = 4 \times 0.5 = 2$ : $P_{T} = 1 - 0.9 5^{2} \approx 1 - 0.9025 = 0.0975.$ Why per-merge count $= 2$ ? Rate 4/day over half a day = 2 accumulated changes, so each short branch faces only 2 collision chances.

Step 3 — Team T: expected total. By linearity of expectation (add the per-merge probabilities, no independence needed): $E_{T} = 20 \times 0.0975 = 1.95 conflicting merges .$ Why linearity? The expected value of a sum equals the sum of expected values, regardless of dependence. Twenty merges each contributing $\approx 0.0975$ give $1.95$ expected conflicting merges.

Step 4 — compare and interpret. $E_{G} \approx 0.87$ vs $E_{T} \approx 1.95$ . Why does "more events" still favour Team T? Cost per conflict is what hurts. Team T's conflicts span only 2 changes each — resolvable in minutes and caught same-day by Continuous Integration. Team G's single likely conflict spans 40 changes — a stale, release-threatening merge. Count of events ≠ cost of events; this mirrors DORA Metrics, where high deploy frequency with low change-failure rate beats rare, risky big-bang merges.

Verify: $0.9 5^{40} \approx 0.1285$ and $0.9 5^{2} = 0.9025$ ; $E_{T} = 20 (0.0975) = 1.95$ . The exam trap is comparing raw event counts instead of per-conflict size. ✓

Active recall

Recall Predict-then-check the model's limits

Q: What is $P_{conflict}$ when $T = 0$ ? ::: $0$ — no elapsed time means no incoming changes (empty product ⇒ $P_{clean} = 1$ ). Q: What is $P_{conflict}$ when $p = 0$ ? ::: $0$ — no change ever touches your lines, so $1^{λ T} = 1$ and there is nothing to collide with. Q: What is $P_{conflict}$ when $p = 1$ and $n \geq 1$ ? ::: $1$ — every change hits you, so a conflict is certain. Q: Why is $λ T$ allowed to be a non-integer? ::: It is an expected count of Poisson arrivals, and real powers extend $(1 - p)^{x} = e^{x l n (1 - p)}$ to the whole continuous curve. Q: Two teams do the same work; one merges 20× more often. Who has smaller conflicts? ::: The frequent-merger — each merge accumulates far fewer changes.

Recall Gitflow routing

Q: A hotfix/1.2.1 off main merges into which branches, and what SemVer tag? ::: Into main and develop; tag v1.2.1 (PATCH bump). Q: Where do release bugs get fixed — develop or release/*? ::: On the feature-frozen release/* branch, then merged back into both main and develop.