Git workflows — Gitflow, trunk-based development

4.5.9 · Coding › Software Engineering

Workflows exist hi kyun karte hain?

Problem kya hai? Agar 10 developers bina kisi discipline ke seedha ek branch mein commit karte rahein, to ye hoga:

broken builds jo sabko block kar dein,
merge conflicts ka pile-up kyunki branches alag ho jaati hain,
koi saaf tarika nahi ki kahein "ye exact state wahi hai jo humne ship ki thi."

Workflows isko kaise fix karte hain: ye teen baar-baar aane wale sawaalon ka jawaab dete hain:

Naya kaam kahan jaata hai? (feature branches)
Kaam releasable kaise banta hai? (integration / release branches ya seedha trunk mein merge)
Production ko fast kaise fix karein? (hotfix path)

Gitflow

Do permanent branches kyun? Kyunki Gitflow "kya build ho raha hai" (develop) ko "kya live hai" (main) se alag karta hai. release/* branch ek buffer hai jahan sirf bug fixes allowed hain — koi nayi features nahi — taaki ek release stabilize ho sake jabki develop pe nayi feature work jaari rahe.

Worked example Gitflow mein ek feature ka safar

git checkout develop
git checkout -b feature/login        # Kyun? naya kaam develop se isolated
# ...commits...
git checkout develop
git merge --no-ff feature/login      # Kyun --no-ff? merge commit rakhne ke liye taaki history mein feature boundary dikhein
git branch -d feature/login

Ye step (--no-ff) kyun? Fast-forward se ye fact mit jaata ki wo commits ek feature ke the. Merge commit ek documentation anchor hai.

Worked example Ek hotfix

git checkout main
git checkout -b hotfix/1.2.1         # Kyun main se? prod ABHI tuta hua hai; develop unstable ho sakta hai
# ...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   # Kyun develop mein bhi? taaki fix agli release mein kho na jaaye

Develop mein bhi merge kyun? Agar sirf main fix karo, to develop se bani agli release bug wapas le aayegi — ek classic regression.

Trunk-Based Development (TBD)

Bina chaos ke ye kaam kyun karta hai? Do enabling technologies:

Continuous Integration (CI): har push test suite run karta hai, is liye broken trunk minutes mein pakad aata hai.
Feature flags: aap adhoora code merge karte ho jo production mein off hota hai, deploy ko release se decouple karta hai.

Worked example TBD with feature flag

if flags.enabled("new_checkout"):   # Kyun? abhi trunk mein merge karo, users ko baad mein expose karo
    run_new_checkout()
else:
    run_old_checkout()

Ye step kyun? Adhoora new_checkout roz production mein jaata hai lekin invisible rehta hai. Integration debt ≈ 0 kyunki branch sirf kuch ghante jiya.

"Integration pain" ko quantify karna

Yahaan Newton's laws nahi likhe ja sakte, lekin ek model zaroor hai. Maano conflict-causing changes shared branch pe rate $λ$ (changes/day) se aate hain. Ek branch jo $T$ din jeeti hai, lagbhag itna drift karti hai:

$drift (T) = λ \cdot T (expected diverging changes) .$

Agar har diverging change mein independent probability $p$ hai ki wo tumhare edits se overlap karega, to tumhara merge conflict-free hone ki probability hai:

$P_{clean} (T) = (1 - p)^{λ T} .$

Derivation (scratch se): $n = λ T$ independent changes mein se har ek tumhare lines se bachta hai probability $(1 - p)$ se. Independent events ⇒ multiply ⇒ $(1 - p)^{n}$ . Substitute $n = λ T$ . ∎

Ye branch lifetime $T$ mein exponentially decay karta hai — "merge early, merge often" ka mathematical heart yehi hai.

Figure — Git workflows — Gitflow, trunk-based development

Kab kaunsa use karein? (80/20)

Common mistakes

Active recall

Recall Forecast-then-verify: pehle predict karo, phir reveal karo

Q: Gitflow mein, hotfix/* ___ se branch karta hai aur ___ aur ___ mein merge hota hai? A: main se branch karta hai; main aur develop dono mein merge hota hai.

Q: Conflict probability branch lifetime ke saath kyun badhti hai? A: Lambi zindagi ⇒ shared branch pe zyada independent diverging changes ⇒ $P_{conflict} = 1 - (1 - p)^{λ T}$ badhta hai.

Q: Woh do technologies kaunsi hain jo trunk-based ko safe banati hain? A: Continuous Integration + feature flags.

Recall Feynman: ek 12-saal ke bacche ko samjhao

Socho ek bada group EK shared poster pe draw kar raha hai. Gitflow aise hai jaise sab apni alag sheet pe poori tasveer banaate hain, phir kaafi baad poster pe chipkaate hain — lekin tab tak poster badal chuka hota hai aur glue fit nahi hota. Trunk-based aise hai jaise sab har kuch minute mein poster pe ek chota sticker lagate hain — choti additions, fix karna aasaan, aur agar sticker adhoora hai to ek flap se dhak do (feature flag) jab tak ready na ho. Thoda-thoda aur aksar karne se kabhi bhi giant gluing disaster nahi aata.

Flashcards

Gitflow mein do permanent branches kaunsi hain?

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

Gitflow mein feature branches kahan se start hoti hain aur kahan merge hoti hain?

develop.

Gitflow mein release branches kahan merge hoti hain?

Dono main aur develop mein.

Gitflow hotfix ko develop mein bhi main ke saath merge kyun karna padta hai?

Warna develop se bani agli release bug wapas le aayegi (regression).

Trunk-based development define karo.

Sab ek shared branch mein kam se kam daily integrate karte hain, bahut short-lived branches ke zariye; releases trunk se cut hoti hain; adhoora kaam feature flags ke peeche chhupa hota hai.

TBD mein branch ki maximum recommended lifetime kitni hai?

Lagbhag ek din (hours se ~1 din).

Trunk-based development ko safe banane wali do technologies kaunsi hain?

Strong CI (broken trunk jaldi pakadta hai) aur feature flags (adhoora code chhupate hain).

"Integration debt" kya hai?

Main se drift ho gayi branch ko merge karne ki badhti cost/risk; branch lifetime ke saath badhti hai.

Merge-conflict probability vs branch lifetime ka formula batao.

P_{co n f l i c t} (T) = 1 - (1 - p)^{λ T}

Gitflow merges mein --no-ff kyun zaroori hai?

Ye ek merge commit force karta hai, history mein feature boundary preserve karta hai.

TBD mein "deploy" ko "release" se kaun decouple karta hai?

Feature flags — code deploy ho sakta hai jabki users ke liye invisible rehta hai.

Gitflow trunk-based se kab better hai?

Scheduled releases, multiple supported versions, regulated/audited environments, ya weak CI jahan ceremony traceability add karta hai.

Connections

Continuous Integration — wo prerequisite jo trunk-based ko viable banata hai.
Feature Flags — deploy ko release se decouple karo; bade features ki daily integration enable karo.
Branching and Merging — Git primitives jinpar har workflow tiki hoti hai.
Pull Requests and Code Review — TBD mein short-lived branches ka gate.
Semantic Versioning — main/release tags ko version numbers kaise milte hain.
DORA Metrics — deployment frequency & lead time, jise TBD optimize karta hai.