Git workflows — Gitflow, trunk-based development

WHY do workflows exist at all?

WHAT problem are we solving? If 10 developers all commit straight to one branch with no discipline, you get:

broken builds that block everyone,
merge conflicts that pile up because branches drift apart,
no clean way to say "this exact state is what we shipped."

HOW workflows fix it: they answer three recurring questions:

Where does new work go? (feature branches)
How does work become releasable? (integration / release branches or direct merge to trunk)
How do we fix production fast? (hotfix path)

Gitflow

WHY two permanent branches? Because Gitflow separates "what is being built" (develop) from "what is live" (main). The release/* branch is the buffer where you only allow bug fixes — no new features — so a release can stabilize while new feature work continues on develop.

Worked example A feature through Gitflow

git checkout develop
git checkout -b feature/login        # Why? new work isolated from develop
# ...commits...
git checkout develop
git merge --no-ff feature/login      # Why --no-ff? keep a merge commit so history shows the feature boundary
git branch -d feature/login

Why this step (--no-ff)? A fast-forward would erase the fact that those commits belonged to one feature. The merge commit is a documentation anchor.

Worked example A hotfix

git checkout main
git checkout -b hotfix/1.2.1         # Why off main? prod is broken NOW; develop may be unstable
# ...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   # Why also develop? so the fix isn't lost in the next release

Why merge into develop too? If you only fix main, the next release built from develop would re-introduce the bug — a classic regression.

Trunk-Based Development (TBD)

WHY does this work without chaos? Two enabling technologies:

Continuous Integration (CI): every push runs the test suite, so a broken trunk is caught in minutes.
Feature flags: you merge incomplete code that is turned off in production, decoupling deploy from release.

Worked example TBD with a feature flag

if flags.enabled("new_checkout"):   # Why? merge to trunk now, expose to users later
    run_new_checkout()
else:
    run_old_checkout()

Why this step? Half-built new_checkout ships to production every day but stays invisible. Integration debt ≈ 0 because the branch lived only a few hours.

Quantifying "integration pain"

You can't write Newton's laws here, but there is a model. Let conflict-causing changes arrive on the shared branch at rate $\lambda$ (changes/day). A branch that lives $T$ days drifts past roughly

$\text{drift}(T) = \lambda \cdot T \quad\text{(expected diverging changes)}.$

If each diverging change has independent probability $p$ of overlapping your edits, the chance your merge is conflict-free is

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

Derivation (from scratch): Each of the $n=\lambda T$ independent changes avoids your lines with probability $(1-p)$ . Independent events ⇒ multiply ⇒ $(1-p)^n$ . Substitute $n=\lambda T$ . ∎

This decays exponentially in branch lifetime $T$ — the mathematical heart of "merge early, merge often."

Figure — Git workflows — Gitflow, trunk-based development

When to use which? (the 80/20)

Common mistakes

Active recall

Recall Forecast-then-verify: predict before revealing

Q: In Gitflow, a hotfix/* branches off ___ and merges into ___ and ___? A: branches off main; merges into main and develop.

Q: Why does conflict probability grow with branch lifetime? A: Longer life ⇒ more independent diverging changes on the shared branch ⇒ $P_{\text{conflict}}=1-(1-p)^{\lambda T}$ grows.

Q: What two technologies make trunk-based safe? A: Continuous Integration + feature flags.

Recall Feynman: explain to a 12-year-old

Imagine a big group drawing on ONE shared poster. Gitflow is like everyone taking their own sheet of paper, drawing a whole picture, then gluing it onto the poster much later — but by then the poster changed and the glue doesn't fit. Trunk-based is like everyone adding one small sticker to the poster every few minutes — tiny additions, easy to fix, and if a sticker is half-done you cover it with a flap (a feature flag) until it's ready. Adding small and often means you never have a giant gluing disaster.

Flashcards

What are the two permanent branches in Gitflow?

main (releases, tagged) and develop (integration).

In Gitflow, which branch do feature branches start from and merge back to?

develop.

In Gitflow, where do release branches merge into?

Both main and develop.

Why must a Gitflow hotfix merge into develop as well as main?

Otherwise the next release built from develop re-introduces the bug (regression).

Define trunk-based development.

Everyone integrates into one shared branch at least daily, via very short-lived branches; releases cut from trunk; incomplete work hidden behind feature flags.

What is the maximum recommended lifetime of a branch in TBD?

Roughly a day (hours to ~1 day).

What two technologies make trunk-based development safe?

Strong CI (catches broken trunk fast) and feature flags (hide unfinished code).

What is "integration debt"?

The growing cost/risk of merging a branch that has drifted from main; grows with branch lifetime.

Give the formula for merge-conflict probability vs branch lifetime.

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

Why does --no-ff matter in Gitflow merges?

It forces a merge commit, preserving the feature boundary in history.

What decouples "deploy" from "release" in TBD?

Feature flags — code can deploy while staying invisible to users.

When is Gitflow preferable to trunk-based?

Scheduled releases, multiple supported versions, regulated/audited environments, or weak CI where ceremony adds traceability.

Connections

Continuous Integration — the prerequisite that makes trunk-based viable.
Feature Flags — decouple deploy from release; enable daily integration of big features.
Branching and Merging — the Git primitives every workflow sits on.
Pull Requests and Code Review — the gate for short-lived branches in TBD.
Semantic Versioning — how main/release tags get version numbers.
DORA Metrics — deployment frequency & lead time, which TBD optimizes.

Concept Map

Hinglish (regional understanding)

Intuition Hinglish mein samjho

Dekho, Git workflow ka matlab hai team ka ek agreement — branches kaise banayenge, kaise merge karenge, aur production pe kaise bhejenge. Git khud sirf commits store karta hai; workflow ek insaani rule hai taaki 10 log ek hi codebase pe kaam karein bina ek dusre ko tod-fod kiye.

Gitflow mein bahut saari branches hoti hain — do permanent (main = jo live hai, develop = jaha sab features jud te hain) aur teen temporary (feature, release, hotfix). Yeh control aur traceability deta hai, lekin branches lambi chalti hain. Yaad rakho: hotfix hamesha main aur develop dono mein merge karna padta hai, warna agle release mein bug wapas aa jayega.

Trunk-based iske ulta hai — sab log ek hi branch (main/trunk) pe roz integrate karte hain, branch sirf kuch ghante jeeti hai. Adhura feature bhi merge ho jata hai par feature flag se chhupa diya jata hai, aur CI har push pe test chala ke trunk ko green rakhta hai. Isse "integration debt" kam rehta hai.

Asli maths intuition yeh hai: branch jitni lambi jiyegi, utne zyada changes us shared branch pe aa jayenge, aur conflict ka chance exponentially badhta hai — $P_{conflict}=1-(1-p)^{\lambda T}$ . Isliye chhoti aur baar-baar merge karna safe hai, lambi branch chhupana safe nahi. Decision simple hai: agar tumhari CI strong hai aur fast deploy chahiye to trunk-based; agar fixed release schedule ya audit/regulation hai to Gitflow.

Git workflows — Gitflow, trunk-based development

WHY do workflows exist at all?

Gitflow

Trunk-Based Development (TBD)

Quantifying "integration pain"

When to use which? (the 80/20)

Common mistakes

Active recall

Flashcards

Connections

Concept Map

Hinglish (regional understanding)

Go deeper — visual, from zero

Test yourself — Software Engineering

Connections