Exercises — Git workflows — Gitflow, trunk-based development

L1.1 Permanent: ==main and develop. Temporary: feature/*, release/*, hotfix/*==. (Mnemonic MAD-FRH from the parent note.)

L1.2 False. Trunk-based allows branches — it forbids only long-lived ones. Short-lived branches (hours to ~1 day) merged via small PRs are normal. The discipline is lifetime, not existence.

L1.3 Here $n=\lambda T=\lambda \cdot 0=0$. Substitute: $P_{\text{conflict}}=1-(1-p{)}^n=1-(1-p{)}^0=1-1=0.$ A branch that lives no time has $n=0$ missed changes, so it cannot drift, so it cannot conflict — probability $0$. This is the mathematical reason "merge immediately" is the safest possible strategy. On the figure this is where every curve touches the origin.

L2.1 First find $n=\lambda T=4\times 5=20$ diverging changes, then plug $n$ into the formula. $P_{\text{conflict}}=1-(1-0.02{)}^n=1-0.98^{20}.$ $0.98^{20}\approx 0.6676$, so $P_{\text{conflict}}\approx 1-0.6676=0.332$ (about a 33% chance of a conflict).

L2.2 Now $n=\lambda T=4\times 0.5=2$. $P_{\text{conflict}}=1-0.98^n=1-0.98^2=1-0.9604=0.040$ — about 4%. Same team, same collision odds — only the lifetime (hence $n$) changed, and conflict risk dropped from 33% to 4%. That gap is the argument for CI-driven short branches.

L2.3 Correct order:

git checkout -b feature/login       # 1: isolate new work off develop
# ...commits...
git checkout develop                # 2: return to the integration branch
git merge --no-ff feature/login     # 3: merge, forcing a merge commit

What is a fast-forward? When develop has not moved since you branched, Git can merge by simply sliding develop's pointer forward onto your feature's last commit — no new commit is created, and the history becomes a single straight line as if the feature commits were made directly on develop. That is a "fast-forward" merge. --no-ff forbids that shortcut and forces Git to create an explicit merge commit instead. Why we want that: with a fast-forward the feature boundary vanishes — you can no longer see which commits belonged to one feature. The merge commit is a documentation anchor saying "these commits were one feature." See Branching and Merging.

L3.1 Two errors:

1. Branched off the wrong base. A hotfix must branch off ==main==, because main is the exact live code that is broken. develop may contain unreleased, unstable work — building the patch on top of it risks shipping half-finished features to production.
2. Merged into main only. It must merge into both main and develop. If you skip develop, the next release built from develop re-introduces the same bug — a regression.

Correct procedure:

git checkout main
git checkout -b hotfix/1.2.1
# ...fix...
git checkout main    && git merge --no-ff hotfix/1.2.1 && git tag v1.2.1
git checkout develop && git merge --no-ff hotfix/1.2.1

The tag v1.2.1 follows Semantic Versioning — a patch bumps the third number.

L3.2 We want $P_{\text{conflict}}=0.5$, i.e. $(1-p{)}^{\lambda T}=0.5$. Take the natural log of both sides (the log turns "unknown in the exponent" into "unknown multiplied" — that's why we reach for logs here): $\lambda T\cdot \ln (1-p)=\ln (0.5).$ Solve for $T$: $T^{\star }=\frac{\ln 0.5}{\lambda \ln (1-p)}.$ Watch the signs carefully. Because $1-p=0.98<1$, its logarithm $\ln (0.98)$ is negative. And $\ln (0.5)$ is also negative. A negative divided by a negative is positive, so $T^{\star }$ comes out positive as a lifetime must: $T^{\star }=\frac{-0.6931}{4\times (-0.020203)}=\frac{-0.6931}{-0.080811}\approx 8.58\text{ days}.$ So a branch on this team crosses a coin-flip's worth of conflict risk at roughly 8.6 days (the labelled amber dot on the figure) — a strong argument for merging well before then.

L3.3 $n=\lambda T=3\times 4=12$ for both teams.

• Team A: $P_{\text{conflict}}=1-(1-0.01{)}^n=1-0.99^{12}=1-0.8864\approx 0.114$ (≈11%).
• Team B: $P_{\text{conflict}}=1-(1-0.05{)}^n=1-0.95^{12}=1-0.5404\approx 0.460$ (≈46%). Same $\lambda$, same $T$, same $n$ — the only difference is $p$, driven by code architecture. Good modularity (small $p$) roughly quartered the conflict risk. Clean boundaries mean fewer people editing the same lines, which literally lowers $p$ in the model.

L4.1 Choose Gitflow. Reasons:

1. Scheduled 6-week releases map naturally onto release/* branches, where you feature-freeze and stabilise while develop keeps moving.
2. Three supported versions need long-lived maintenance lines and clean hotfix/* paths per version — Gitflow's ceremony provides that traceability.
3. Regulated/audited + weak CI: the explicit merge commits and branch structure give an audit trail, and the human review gates compensate for tests you can't fully trust. Speed isn't the constraint here — traceability is.

L4.2 Merge the incomplete code behind a feature flag — a runtime switch that keeps the new path turned off in production:

if flags.enabled("payment_redesign"):   # off in prod today
    run_new_payment()
else:
    run_old_payment()

Now the code lives on main and deploys every afternoon, but users never see it until you flip the flag. This decouples deploy from release. The two enabling technologies: Feature Flags (hide incomplete work) and Continuous Integration (catch a broken trunk within minutes so daily merges stay safe).

L4.3 Biggest blocker: a slow, flaky CI pipeline breaks the core promise of trunk-based development — that a broken trunk is caught in minutes and that green means green. A 15% false-failure rate trains developers to ignore red builds ("just re-run it"), so real breakages slip through. Concrete fixes (any one): quarantine/fix flaky tests until the suite is deterministic; parallelise the suite to cut the 40 min feedback loop; add a fast pre-merge subset (~5 min) that gates PRs. Trunk-based depends on a trustworthy, fast signal — without it you're forced back toward long branches and Gitflow-style gates.

L5.1 Start from the clean probability, $P_{\text{clean}}(T)=(1-p{)}^n$ with $n=\lambda T$. Rewrite the base using the exponential, because the exponential is the one function whose rate of change is proportional to itself — exactly the behaviour "each day multiplies risk by the same factor." Using the identity $a^x=e^{x\ln a}$: $P_{\text{clean}}(T)=e^{\lambda T\ln (1-p)}.$ Since $0<1-p<1$, we have $\ln (1-p)<0$, so the exponent is negative — this is exponential decay of safety. Now the conflict probability is one minus that: $P_{\text{conflict}}(T)=1-e^{\lambda T\ln (1-p)}.$ Differentiate with respect to $T$ (the chain rule brings the constant $\lambda \ln (1-p)$ down out of the exponent): $\frac{d{P}_{\text{conflict}}}{dT}=-\lambda \ln (1-p)e^{\lambda T\ln (1-p)}=\underset{>0\text{(constant)}}{\underbrace{[-\lambda \ln (1-p)]}}\cdot \underset{\text{shrinks as }T\text{ grows}}{\underbrace{(1-p{)}^{\lambda T}}}.$ Interpreting the sign: the first factor $-\lambda \ln (1-p)$ is positive (because $\ln (1-p)$ is negative and we negate it), and the second factor $(1-p{)}^{\lambda T}$ is always positive. So $\frac{d{P}_{\text{conflict}}}{dT}>0$ everywhere — conflict risk is always rising with branch lifetime; you never reduce risk by waiting. Interpreting the magnitude: the second factor $(1-p{)}^{\lambda T}$ is largest at $T=0$ (equal to 1) and shrinks as $T$ grows. Since the derivative is the constant times this shrinking factor, the derivative is biggest when the branch is young and tapers toward 0 as $T\to \infty$. In words: each extra day adds risk, but the earliest days add the most absolute risk — while there is still safety left to lose. Once risk is already near 1, extra days barely move it. This is the calculus behind "merge early" and matches the figure's steep-then-flat curve. $■$

L5.2 Compute $n=\lambda T=5\times 6=30$ for both cases, then apply the formula.

• Old ($p=0.04$): $P_{\text{conflict}}=1-(1-0.04{)}^n=1-0.96^{30}=1-0.2939\approx 0.706$ (≈71%).
• New ($p=0.02$): $P_{\text{conflict}}=1-(1-0.02{)}^n=1-0.98^{30}=1-0.5455\approx 0.455$ (≈45%). Halving $p$ did not halve the conflict probability. The risk fell from 0.706 to 0.455 — a ratio of $0.455/0.706\approx 0.64$, i.e. about a 36% reduction, not the 50% the manager claimed. Because $p$ sits inside the exponent, the relationship is non-linear: you cannot scale the output by scaling one input. The improvement is real and worthwhile — just not a clean halving.

L5.3 Deployment frequency and change failure rate are two DORA Metrics usually treated as a trade-off (deploy faster → break more). The conflict model dissolves the trade-off because a single lever — short branch lifetime $T$, which shrinks $n=\lambda T$ — improves both at once:

• Deployment frequency ↑: small $T$ (small $n$) keeps $P_{\text{conflict}}=1-(1-p{)}^n$ near zero, so merges are trivial and integration is continuous. Trivial merges mean you can integrate and ship many times a day instead of batching up a risky release.
• Change failure rate ↓: small $T$ also means each change is a small diff. Small diffs are easier to review, easier to test, and if something breaks, CI pinpoints the tiny culprit in minutes. Less code per deploy ⇒ fewer ways for a deploy to fail. Both metrics improve because both are downstream of the same quantity, $T$. That is why elite teams score high on all four DORA metrics simultaneously rather than trading one for another — short-lived branches are a common cause, not a compromise.

Longest-safe rule of thumb ::: Keep $T$ small; conflict risk decays exponentially, so a half-day branch is dramatically safer than a five-day one. Hotfix base and merge targets ::: Branch off main; merge into both main and develop. The prerequisite for trunk-based ::: Strong, fast, trustworthy CI that keeps trunk green. What halving $p$ does to $P_{\text{conflict}}$ ::: Reduces it non-linearly (only ≈36% at $\lambda =5,T=6$) — because $p$ sits in an exponent. The two extremes of $p$ ::: $p=0$ ⇒ never conflicts; $p=1$ ⇒ certain conflict once any change lands.