Branching strategy — Git Flow, GitHub Flow আর trunk-based development

১ · দলের কেন একটি branching strategy লাগে

পর্ব ১২-এ (Branch — pointer, HEAD, switch আর detached HEAD) দেখেছেন, Git-এর কাছে একটি branch মাত্র একটি ছোট pointer — বানাতে খরচ নেই, মুছতেও না। পর্ব ১৩-এ (Merge আর conflict) দেখেছেন দুই branch কীভাবে merge হয়, আর কখন conflict হয়। প্রশ্ন হলো: পাঁচ, বিশ বা দুশো জন মানুষ যখন একই repository-তে কাজ করেন, তখন এই সস্তা branch-গুলো কে কখন খুলবেন, কতদিন রাখবেন, আর কোথায় মেলাবেন?

চুক্তি না থাকলে দলগুলো সাধারণত তিন রকম ব্যথায় ভোগে:

একটি branching strategy অন্তত এই প্রশ্নগুলোর উত্তর লিখে রাখে:

1. কোন branch-গুলো স্থায়ী (long-lived), আর কোনগুলো কাজ শেষে মুছে ফেলার জন্য (short-lived)?
2. নতুন কাজের branch কোথা থেকে খোলা হবে, আর কোথায় merge হবে? কোন দিকে merge নিষেধ?
3. একটি অস্থায়ী branch সর্বোচ্চ কতদিন বাঁচতে পারে?
4. Release কোথা থেকে বের হয় — কোন branch, কোন tag? জরুরি fix কোথায় যায়, আর কীভাবে বাকি জায়গায় পৌঁছায়?
5. মূল branch-এ ঢোকার শর্ত কী — review, সবুজ CI, কয়জনের অনুমোদন?

এই পর্বে চারটি বহুল আলোচিত উত্তর দেখব — Git Flow, GitHub Flow, GitLab Flow আর trunk-based development — তারপর শিখব নিজের দলের জন্য কীভাবে বাছবেন। মনে রাখবেন, এগুলো কোনো আন্তর্জাতিক মানদণ্ড নয়; প্রতিটি কোনো একজন লেখক বা প্রতিষ্ঠানের প্রস্তাব, আর বাস্তবে দলগুলো প্রায়ই মিশিয়ে ব্যবহার করে। নামও সবসময় এক অর্থে ব্যবহার হয় না — কেউ “GitHub Flow” বলতে যা বোঝান, আরেকজন তাকেই “feature branch workflow” বলেন।

২ · Long-lived branch আর integration-এর ঝুঁকি — হিসাব করে দেখি

“Branch বেশিদিন রাখলে ঝামেলা বাড়ে” — কথাটা অনেকে বলেন। কিন্তু কতটা বাড়ে? একটি সরল মডেল দিয়ে মেপে দেখা যাক। পর্ব ১৩-এর শেষে দেখেছিলেন, দুই branch যত বেশি লাইন বদলায়, conflict-এর সম্ভাবনা তত দ্রুত বাড়ে। এবার পুরো দলের দিক থেকে দেখি।

মডেল: ৬ জন developer, ৩০ কর্মদিবস, ২০০০ লাইনের একটি codebase. প্রত্যেকে দিনে ৫টি এলোমেলো লাইন বদলান। প্রত্যেকের branch বাঁচে T দিন, তারপর মূল branch-এ (trunk) merge হয় আর নতুন branch শুরু হয়। Merge-এর সময় এই branch যে লাইনগুলো বদলেছে, সেগুলোর কোনোটি যদি branch শুরুর পরে অন্য কেউ trunk-এ বদলে থাকেন, তবে সেই লাইন হাতে মেলাতে হবে। তিনটি T তুলনা করি — ১, ৩ আর ১০ দিন। Seed-যুক্ত PRNG (mulberry32) ব্যবহার করায় প্রতিবার একই ফল আসবে, আর তিনটি T-তেই হুবহু একই সম্পাদনাগুলো হবে — বদলাচ্ছে শুধু কতদিন পরপর মেলানো হয়।

// Integration risk: 6 developers, 30 working days, a 2000-line codebase.
// Each developer edits 5 random lines a day on a branch that lives T days,
// then merges. Lines this branch changed that others also changed on trunk
// since the branch started must be resolved by hand (a model, not real Git).
function mulberry32(a) { return () => { a = (a + 0x6D2B79F5) | 0; let t = Math.imul(a ^ (a >>> 15), 1 | a);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
const DEVS = 6, DAYS = 30, LINES = 2000, PER_DAY = 5;
function simulate(T) {
  const rnd = mulberry32(44);               // same seed: same edits for every T
  const trunk = [];                         // [{day, lines}] merged so far
  const open = Array.from({ length: DEVS }, () => ({ start: 0, lines: new Set() }));
  let merges = 0, conflicted = 0, toResolve = 0;
  for (let day = 0; day < DAYS; day++) {
    for (let d = 0; d < DEVS; d++)
      for (let k = 0; k < PER_DAY; k++) open[d].lines.add(Math.floor(rnd() * LINES));
    if ((day + 1) % T !== 0 && day !== DAYS - 1) continue;   // branches merge every T days
    for (let d = 0; d < DEVS; d++) {
      const b = open[d], others = new Set();
      for (const m of trunk) if (m.day >= b.start) for (const x of m.lines) others.add(x);
      const clash = [...b.lines].filter(x => others.has(x)).length;
      merges++; if (clash) conflicted++; toResolve += clash;
      trunk.push({ day, lines: b.lines });
      open[d] = { start: day + 1, lines: new Set() };
    }
  }
  return { merges, conflicted, toResolve };
}
console.log("branch life  merges  merges with conflict  lines to resolve  per merge");
for (const T of [1, 3, 10]) {
  const r = simulate(T);
  console.log(String(T + " day").padStart(11) + String(r.merges).padStart(8) +
    String(r.conflicted).padStart(22) + String(r.toResolve).padStart(18) +
    (r.toResolve / r.merges).toFixed(2).padStart(11));
}

branch life  merges  merges with conflict  lines to resolve  per merge
      1 day     180                     5                 5       0.03
      3 day      60                    15                16       0.27
     10 day      18                    14                53       2.94

কেন T²? — একটি ছোট হিসাব

একটি branch T দিনে নিজে প্রায় 5T লাইন বদলায়। একই সময়ে বাকিরা trunk-এ গড়ে আরও কয়েকগুণ 5T লাইন ঢোকান। দুটি এলোমেলো set-এর প্রত্যাশিত মিল ≈ (প্রথম set-এর আকার × দ্বিতীয় set-এর আকার) ÷ মোট লাইন। দুটি আকারই T-এর সমানুপাতিক, তাই গুণফল T²-এর সমানুপাতিক। আবার মোট merge-এর সংখ্যা ৩০/T, তাই সব merge মিলিয়ে বোঝা ≈ (৩০/T) × T² ∝ T. শত-হাজারবার আলাদা seed দিয়ে চালালে গড় দাঁড়ায় প্রতি merge-এ প্রায় ০.০৩, ০.২৮ আর ২.৯৫ — উপরের ফলের খুব কাছে; seed ৪৪ সেজন্যই প্রতিনিধিত্বমূলক।

তবে ইচ্ছাকৃত দীর্ঘজীবী branch — যেমন পুরোনো version-এর release branch, যেখানে শুধু বাছাই করা fix যায় — এই ঝুঁকির বাইরে। বিপদ হলো নতুন কাজের দীর্ঘজীবী branch.

৩ · Git Flow — দুটি স্থায়ী branch আর তিন রকম অস্থায়ী branch

২০১০ সালের জানুয়ারিতে ডাচ developer Vincent Driessen নিজের blog-এ “A successful Git branching model” নামে একটি লেখা প্রকাশ করেন। লেখাটি দ্রুত ছড়িয়ে পড়ে, আর মডেলটি পরিচিত হয় Git Flow নামে। এর মূল চিন্তা: release-এর জন্য তৈরি কোড আর চলমান উন্নয়নের কোড আলাদা লাইনে রাখা, আর প্রতিটি কাজের ধরনের জন্য আলাদা ধরনের branch.

কয়েকটি খুঁটিনাটি, যা প্রায়ই ভুল বলা হয়:

• নামকরণ: মূল লেখায় নাম ছিল release-1.2, hotfix-1.2.1 ধাঁচের; feature/, release/, hotfix/ উপসর্গ জনপ্রিয় করে পরের git-flow extension.
• সবসময় --no-ff: মূল লেখা feature merge-এ --no-ff ব্যবহারের পরামর্শ দেয়, যাতে history-তে feature-এর সীমানা থাকে আর পুরো feature একটি merge commit revert করে ফেরানো যায় (পর্ব ১৩-এর অংশ ৩)।
• Back-merge: Release বা hotfix শুধু main-এ মেলালে কাজ অর্ধেক। ঠিক করা bug আর নতুন version নম্বর develop-এ না ফিরলে পরের release-এ bug আবার ফিরে আসে। একটি ব্যতিক্রম: hotfix-এর সময় কোনো release branch চালু থাকলে, মূল লেখা অনুযায়ী hotfix develop-এর বদলে সেই release branch-এ মেলানো হয় — release শেষে সেটি এমনিতেই develop-এ পৌঁছাবে।
• git flow command মূল Git-এর অংশ নয়। এটি আলাদা করে ইনস্টল করা একটি extension; কয়েকটি ভিন্ন সংস্করণ আছে আর তাদের option আলাদা। পরের অংশে আমরা শুধু plain Git দিয়ে পুরো প্রবাহ চালাব — তাতে ভেতরে কী হচ্ছে, স্পষ্ট দেখা যাবে।

৪ · Git Flow হাতে-কলমে — plain Git-এ একটি release আর একটি hotfix

এই পর্বের সব Git আউটপুট আসল — একটি খালি পরীক্ষার folder-এ Git ২.৫৩ দিয়ে চালানো। লেখকের নাম “Rahim”, email rahim@example.com, আর প্রতিটি commit-এর সময় GIT_AUTHOR_DATE ও GIT_COMMITTER_DATE দিয়ে ২০২৬-০১-১৫ সকাল ১০:০১ (+06:00) থেকে প্রতিটি commit ও tag-এ এক মিনিট করে বাড়ানো, তাই একই ফাইল আর একই ধাপ মানলে আপনিও একই hash পাবেন। গল্পটি একটি কাল্পনিক অনলাইন বাজার অ্যাপের: শুরুতে main-এ একটি commit 2d3260e (“Initial commit”), যেখানে VERSION ফাইলে লেখা 0.1.0. প্রথমে feature আর release:

$ git switch -c develop
Switched to a new branch 'develop'
$ git switch -c feature/wallet-payment
Switched to a new branch 'feature/wallet-payment'
# (create payment.conf; git add payment.conf)
$ git commit -m "Add mobile wallet payment"
[feature/wallet-payment c8f1ddc] Add mobile wallet payment
 1 file changed, 1 insertion(+)
 create mode 100644 payment.conf
$ git switch develop
Switched to branch 'develop'
$ git merge --no-ff feature/wallet-payment --no-edit
Merge made by the 'ort' strategy.
 payment.conf | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 payment.conf
$ git branch -d feature/wallet-payment
Deleted branch feature/wallet-payment (was c8f1ddc).
$ git switch -c release/1.0 develop
Switched to a new branch 'release/1.0'
# (VERSION: 0.1.0 -> 1.0.0; git add VERSION)
$ git commit -m "Bump version to 1.0.0"
[release/1.0 7656b66] Bump version to 1.0.0
 1 file changed, 1 insertion(+), 1 deletion(-)
# meanwhile, another feature lands on develop: 41b9e33 "Add order tracking",
# merged with --no-ff as 3ed99bd (same commands as above, output omitted) …
$ git switch main
Switched to branch 'main'
$ git merge --no-ff release/1.0 --no-edit
Merge made by the 'ort' strategy.
 VERSION      | 2 +-
 payment.conf | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)
 create mode 100644 payment.conf
$ git tag -a v1.0.0 -m "Release 1.0.0"
$ git switch develop
Switched to branch 'develop'
$ git merge --no-ff release/1.0 --no-edit
Merge made by the 'ort' strategy.
 VERSION | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git branch -d release/1.0
Deleted branch release/1.0 (was 7656b66).

এবার production-এ একটি ভুল ধরা পড়ল — README-তে ডেলিভারি ফি লেখা নেই, গ্রাহকেরা বিভ্রান্ত। পরের release পর্যন্ত অপেক্ষা করা যাবে না, আর develop-এ ইতিমধ্যে অপ্রকাশিত order tracking আছে, তাই সেখান থেকেও release করা যাবে না। এটাই hotfix branch-এর কাজ:

$ git switch -c hotfix/1.0.1 main
Switched to a new branch 'hotfix/1.0.1'
# (add the delivery fee line to README.md; git add)
$ git commit -m "Fix delivery fee shown on README"
[hotfix/1.0.1 f465007] Fix delivery fee shown on README
 1 file changed, 1 insertion(+)
# (VERSION: 1.0.0 -> 1.0.1; git add)
$ git commit -m "Bump version to 1.0.1"
[hotfix/1.0.1 d0aed8e] Bump version to 1.0.1
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git switch main
Switched to branch 'main'
$ git merge --no-ff hotfix/1.0.1 --no-edit
Merge made by the 'ort' strategy.
 README.md | 1 +
 VERSION   | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
$ git tag -a v1.0.1 -m "Release 1.0.1"
$ git switch develop
Switched to branch 'develop'
$ git merge --no-ff hotfix/1.0.1 --no-edit
Merge made by the 'ort' strategy.
 README.md | 1 +
 VERSION   | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
$ git branch -d hotfix/1.0.1
Deleted branch hotfix/1.0.1 (was d0aed8e).
$ git log --graph --oneline --all --decorate
*   a704cd1 (HEAD -> develop) Merge branch 'hotfix/1.0.1' into develop
|\
* \   b266439 Merge branch 'release/1.0' into develop
|\ \
* \ \   3ed99bd Merge branch 'feature/order-tracking' into develop
|\ \ \
| * | | 41b9e33 Add order tracking
|/ / /
| | | *   f94e273 (tag: v1.0.1, main) Merge branch 'hotfix/1.0.1'
| | | |\
| | | |/
| | |/|
| | * | d0aed8e Bump version to 1.0.1
| | * | f465007 Fix delivery fee shown on README
| | |/
| | *   34ce3fb (tag: v1.0.0) Merge branch 'release/1.0'
| | |\
| | |/
| |/|
| * | 7656b66 Bump version to 1.0.0
|/ /
* |   001c6ac Merge branch 'feature/wallet-payment' into develop
|\ \
| |/
|/|
| * c8f1ddc Add mobile wallet payment
|/
* 2d3260e Initial commit
$ git log --oneline --first-parent main
f94e273 Merge branch 'hotfix/1.0.1'
34ce3fb Merge branch 'release/1.0'
2d3260e Initial commit

একই প্রবাহ একটি ছোট মডেলেও চালিয়ে দেখা যায়। নিচের প্রোগ্রামে commit-এর DAG একটি সাধারণ তালিকা: প্রতিটি commit তার parent-দের মনে রাখে, আর কোন লেনে (branch-এর ধরনে) তৈরি হয়েছিল সেটিও। একটি Git Flow command-এর ক্রম চালিয়ে প্রোগ্রামটি লেন-ভিত্তিক graph ছাপে — o সাধারণ commit, M merge commit:

// A tiny commit-DAG model that runs a Git Flow command script and prints lanes.
const LANES = ["main", "hotfix", "release", "develop", "feature"];
const commits = [], refs = {}, tags = {}; let head = "main", n = 0;
const lane = b => LANES.find(l => b === l || b.startsWith(l + "/"));
function commit(msg, parents) {
  const id = "c" + (++n);
  commits.push({ id, msg, parents, lane: lane(head) });
  refs[head] = id;
}
const git = {
  commit: msg => commit(msg, refs[head] ? [refs[head]] : []),
  branch: (b, from = head) => { refs[b] = refs[from]; head = b; },   // switch -c b from
  switch: b => { head = b; },
  merge: b => commit("Merge " + b + " into " + head, [refs[head], refs[b]]),  // --no-ff
  tag: t => { tags[refs[head]] = t; },
  delete: b => { delete refs[b]; }
};
function show(title) {
  console.log("== " + title + "  (" + LANES.map(l => l.slice(0, 4)).join(" ") + ")");
  for (const c of commits) {
    const cells = LANES.map(l => (l === c.lane ? (c.parents.length > 1 ? "M" : "o") : ".").padEnd(5));
    console.log(c.id.padEnd(4) + cells.join("") + c.msg + (tags[c.id] ? "  [tag " + tags[c.id] + "]" : ""));
  }
}
git.commit("Initial commit"); git.branch("develop");
git.branch("feature/wallet"); git.commit("Add wallet payment");
git.switch("develop"); git.merge("feature/wallet"); git.delete("feature/wallet");
git.branch("release/1.0"); git.commit("Bump version to 1.0.0");
git.switch("main"); git.merge("release/1.0"); git.tag("v1.0.0");
git.switch("develop"); git.merge("release/1.0"); git.delete("release/1.0");
git.branch("hotfix/1.0.1", "main"); git.commit("Fix delivery fee, bump to 1.0.1");
git.switch("main"); git.merge("hotfix/1.0.1"); git.tag("v1.0.1");
git.switch("develop"); git.merge("hotfix/1.0.1"); git.delete("hotfix/1.0.1");
show("after feature, release, tag, hotfix, back-merge");
console.log("branches left:", Object.keys(refs).join(", "), "| parents of c9:", commits[8].parents.join(" + "));

== after feature, release, tag, hotfix, back-merge  (main hotf rele deve feat)
c1  o    .    .    .    .    Initial commit
c2  .    .    .    .    o    Add wallet payment
c3  .    .    .    M    .    Merge feature/wallet into develop
c4  .    .    o    .    .    Bump version to 1.0.0
c5  M    .    .    .    .    Merge release/1.0 into main  [tag v1.0.0]
c6  .    .    .    M    .    Merge release/1.0 into develop
c7  .    o    .    .    .    Fix delivery fee, bump to 1.0.1
c8  M    .    .    .    .    Merge hotfix/1.0.1 into main  [tag v1.0.1]
c9  .    .    .    M    .    Merge hotfix/1.0.1 into develop
branches left: main, develop | parents of c9: c6 + c7

Git Flow কোথায় মানায় — আর লেখক নিজে কী বলেছেন

Git Flow-এর কাঠামো ভালো কাজ করে যখন software নির্দিষ্ট version নম্বর নিয়ে, নির্দিষ্ট সময়ে প্রকাশ হয়, আর একই সময়ে একাধিক version চালু থাকে: দোকানে বিক্রি হওয়া desktop software, একটি library যার ব্যবহারকারীরা নিজেরাই ঠিক করেন কবে upgrade করবেন, যন্ত্রের firmware, বা গ্রাহকের নিজের server-এ বসানো product. সেখানে “release-এর জন্য স্থির কোড” আলাদা রাখার দাম আছে।

অন্যদিকে দিনে কয়েকবার deploy হওয়া web app-এ develop আর main-এর ফারাক প্রায়ই অর্থহীন বোঝা হয়ে দাঁড়ায়। মজার ব্যাপার হলো, এই কথা লেখক নিজেই বলেছেন। ২০২০ সালের মার্চে Driessen মূল লেখার ওপরে একটি “note of reflection” যোগ করেন। আমাদের জানা মতে তার সারকথা: এক দশকে software-এর ধরন বদলেছে; continuously delivered web app-এর দলের জন্য তিনি GitHub Flow-এর মতো সরলতর workflow বেছে নেওয়ার পরামর্শ দেন, আর স্পষ্টভাবে version-যুক্ত, একাধিক version চালু থাকা software-এর জন্য Git Flow এখনো উপযুক্ত হতে পারে। শব্দ ধরে উদ্ধৃত করার আগে মূল লেখাটি নিজে পড়ে নিন — কিন্তু শিক্ষাটি পরিষ্কার: একটি কৌশল তার প্রেক্ষাপটের সাথে বাঁধা।

৫ · GitHub Flow — main সবসময় deploy-যোগ্য

২০১১ সালে GitHub-এর সহ-প্রতিষ্ঠাতা Scott Chacon নিজের blog-এ লেখেন, GitHub নিজে Git Flow ব্যবহার করে না, কারণ তাঁরা দিনে বহুবার deploy করেন, আর সেখানে Git Flow অপ্রয়োজনীয় জটিল। তিনি যে সরল প্রবাহ বর্ণনা করেন, সেটি GitHub Flow নামে পরিচিত। আমাদের জানা মতে মূল লেখার নিয়মগুলো মোটামুটি এমন:

1. main-এ (তখনকার নাম master) যা আছে, তা সবসময় deploy করা যায়।
2. নতুন কাজের জন্য main থেকে বর্ণনামূলক নামের একটি branch খুলুন।
3. নিয়মিত commit করুন, আর একই নামের branch-এ server-এ push করুন (push আর remote — পর্ব ১৪, Remote repository).
4. মতামত দরকার হলে বা কাজ শেষ হলে একটি pull request খুলুন।
5. কেউ review করে অনুমোদন দিলে main-এ merge করুন।
6. main-এ merge হওয়ার পর সাথে সাথে deploy করুন।

প্রথম নিয়মটিই সবচেয়ে কঠিন: “সবসময় deploy-যোগ্য” মানে প্রতিটি merge-এর আগে test, CI আর review-কে বিশ্বাস করার মতো শক্ত হতে হবে।

GitHub Flow কোথায় মানায়: একটিমাত্র চালু version (যেমন একটি web app বা SaaS), ঘন ঘন deploy, আর ভালো স্বয়ংক্রিয় test. কোথায় কষ্ট: একই সময়ে ১.x আর ২.x দুটোকেই fix দিতে হলে (এখানে এর কোনো নিয়ম নেই); app store-এর মতো বাইরের অনুমোদনের কারণে “merge করলাম, কিন্তু deploy হতে এক সপ্তাহ” হলে; আর test দুর্বল হলে, কারণ তখন “main সবসময় deploy-যোগ্য” কেবল একটি আশা। আরেকটি সূক্ষ্ম বিষয়: GitHub Flow branch-এর আয়ু বেঁধে দেয় না। দুই সপ্তাহের PR-ও GitHub Flow — আর তখন অংশ ২-এর সব ঝুঁকি ফিরে আসে।

৬ · GitLab Flow আর environment branch-এর বিতর্ক

GitHub Flow-এর ফাঁকগুলো পূরণ করতে ২০১৪ সালের দিকে GitLab একটি মাঝামাঝি প্রস্তাব দেয়, যা GitLab Flow নামে পরিচিত। ভিত্তি GitHub Flow-এর মতোই — feature branch, merge request (GitLab-এ pull request-এর নাম), main — কিন্তু সাথে দুই রকম বাড়তি branch, পরিস্থিতি অনুযায়ী। (GitLab-এর পরের documentation-এ বর্ণনা কয়েকবার বদলেছে; নিচে মূল ধারণাটি দেওয়া হলো।)

Release branch-এর অংশটি অংশ ৮-এ trunk-based development-এর সাথে বিস্তারিত দেখব — দুই কৌশলে নিয়মটি প্রায় একই। এখানে বিতর্কিত অংশটি নিয়ে কথা বলি: environment branch.

Environment branch — কেন অনেকে একে anti-pattern বলেন

অনেক দলে একটি “সহজ” ব্যবস্থা দেখা যায়: dev, staging, production তিনটি branch; প্রতিটি branch-এ push হলে সেই environment-এ নতুন build হয়ে deploy হয়। Staging-এ পরীক্ষা শেষ হলে staging-কে production-এ merge করা হয়। শুনতে সহজ, কিন্তু Continuous Delivery-র সমর্থকেরা — বিশেষ করে Jez Humble ও David Farley-র Continuous Delivery (২০১০) বইয়ের ধারায় — কয়েকটি সমস্যার কথা বলেন:

• প্রতি environment-এ নতুন build: Staging-এ যে binary test হলো, production-এ সেটি যায় না; যায় আরেকটি build. Dependency-র version বা build-এর পরিবেশ একটু বদলালেই “staging-এ চলেছিল” আর মূল্যহীন। পছন্দের নিয়ম হলো build একবার, একই artifact ধাপে ধাপে এগিয়ে নেওয়া (System Design কোর্সের Deployment আর release পর্বের অংশ ১)।
• Branch-গুলো আলাদা হয়ে যায় (drift): কেউ জরুরি অবস্থায় সরাসরি production-এ fix করলেন, dev-এ ফেরত দিতে ভুলে গেলেন। কয়েক মাস পরে তিন branch-এর কোড তিন রকম, আর merge মানেই conflict.
• Cherry-pick-এর জঙ্গল: “এই তিনটি feature production-এ যাবে, ওই দুটি নয়” — তখন merge-এর বদলে বাছাই করা cherry-pick, আর history-র প্রতি আস্থা শেষ।

তাহলে GitLab Flow কেন এটি প্রস্তাব করে? তাদের সংস্করণে নিয়ম কঠোর: merge সবসময় এক দিকে (main থেকে নিচে), environment branch-এ সরাসরি কাজ নিষেধ, আর branch-গুলো আসলে “কোন environment-এ কোন commit আছে” তার রেকর্ড। কিছু ক্ষেত্রে এটি সত্যিই কাজের — যেমন একটি static website বা infrastructure-এর config, যেখানে branch-এর অবস্থাই deploy-এর ঘোষণা (একে অনেক দল GitOps-এর অংশ হিসেবে দেখে)। সারকথা: environment branch তখনই বিপজ্জনক, যখন সেটি একমুখী নয়, আর প্রতিটি branch থেকে আলাদা build হয়।

৭ · Trunk-based development — একটি লাইন, ছোট ধাপ, feature flag

Trunk-based development (সংক্ষেপে TBD) অংশ ২-এর হিসাবকে তার যৌক্তিক শেষ পর্যন্ত নিয়ে যায়: branch-এর আয়ু যদি ঝুঁকির মূল কারণ হয়, তাহলে আয়ুই কমিয়ে দিন। “Trunk” হলো মূল branch-এর পুরোনো নাম (Subversion-এর যুগ থেকে) — আজ সাধারণত main. ধারণাটি নতুন নয়; continuous integration-এর মূল কথাই এটি। আজকের পরিচিত বর্ণনার একটি বড় উৎস trunkbaseddevelopment.com নামের সাইট, যা Paul Hammant-সহ কয়েকজন লেখক রক্ষণাবেক্ষণ করেন। সেখানের মূল নিয়মগুলো সংক্ষেপে (শব্দ ধরে নয়):

• সবাই একটি branch-এ মেলান। ছোট দলে সরাসরি trunk-এ commit; বড় দলে খুব short-lived feature branch — সাধারণত এক-দুই দিনের বেশি নয় — আর pull request-এ review.
• Trunk কখনো ভাঙা থাকে না। প্রতিটি commit-এর আগে আর পরে build ও test; ভাঙলে প্রথম কাজ সেটি ঠিক করা বা ফেরত নেওয়া।
• অসমাপ্ত কাজ লুকানো থাকে feature flag দিয়ে, বা বড় পরিবর্তন হয় branch by abstraction দিয়ে — কোডে, branch-এ নয়।
• Release হয় trunk থেকে, অথবা দরকার হলে trunk থেকে কাটা একটি release branch থেকে; সেখানে fix আসে trunk থেকে cherry-pick করে (অংশ ৮)।

Feature flag — অসমাপ্ত কাজ trunk-এ, কিন্তু ব্যবহারকারীর চোখের আড়ালে

প্রশ্ন জাগে: নতুন checkout পাতা বানাতে যদি দুই সপ্তাহ লাগে, আর branch এক দিনের বেশি রাখা নিষেধ হয়, তাহলে অর্ধেক বানানো পাতা কি production-এ চলে যাবে? যাবে — কিন্তু বন্ধ অবস্থায়। কোড deploy হওয়া আর ব্যবহারকারীর কাছে সুবিধাটি release হওয়া দুটি আলাদা ঘটনা; মাঝখানে থাকে একটি সুইচ:

if (flags.isOn("new_checkout", user)) {
  return newCheckout(cart);      // unfinished work, hidden by default
}
return checkout(cart);           // what every user sees today

নিচের stepper-এ trunk-based দলের একটি দিন দেখুন। প্রথম তিনটি commit-এর বার্তা অংশ ৮-এর আসল transcript-এর সাথে মেলে।

Branch by abstraction — বড় পরিবর্তন, branch ছাড়াই

Flag ছোট সুবিধার জন্য ভালো, কিন্তু ধরুন পুরো payment library বদলাতে হবে — কয়েকশো জায়গায় ব্যবহার। দুই মাসের branch না খুলে branch by abstraction (নামটি Paul Hammant-এর দেওয়া বলে পরিচিত; Martin Fowler-ও এ নিয়ে লিখেছেন) কয়েকটি ছোট, প্রতিটি নিজে নিরাপদ ধাপে কাজটি করে:

1. পুরোনো library-র সামনে একটি abstraction (interface) বসান, যার ভেতরে আপাতত পুরোনো implementation.
2. ধীরে ধীরে সব ব্যবহারকারী কোডকে সরাসরি library-র বদলে abstraction ডাকতে বদলান — প্রতিটি ধাপ আলাদা commit, trunk-এ।
3. একই abstraction-এর পেছনে নতুন implementation লিখুন, ধাপে ধাপে, trunk-এ — flag দিয়ে বন্ধ রেখে।
4. Flag দিয়ে নতুন implementation-এ সুইচ করুন, প্রথমে অল্প ব্যবহারকারীর জন্য।
5. সব ঠিক থাকলে পুরোনো implementation মুছে দিন; চাইলে abstraction-ও।

প্রতিটি ধাপের পর software চলে, test সবুজ থাকে, আর বাকি দল প্রতিদিনের কাজ চালিয়ে যায়। Interface আর dependency inversion-এর ধারণা পর্ব ২৮ (SOLID ২) আর ৩১-এ (Interface আর contract) গভীরভাবে আসবে।

৮ · Release branch আর cherry-pick — trunk থেকে release

সব দল প্রতিটি commit সাথে সাথে release করতে পারে না। Mobile app store-এ যায়, গ্রাহককে আগে জানাতে হয়, বা পুরোনো version-কে কিছুদিন fix দিতে হয়। Trunk-based দল তখন trunk থেকে একটি release branch কাটে — কিন্তু Git Flow-এর সাথে দুটি বড় পার্থক্য: (১) release branch-এ সরাসরি কাজ হয় না, fix আগে trunk-এ যায়, তারপর cherry-pick করে release branch-এ আসে; (২) release branch কখনো trunk-এ ফেরত merge হয় না। পুরো ঘটনাটি plain Git-এ (তারিখ এবার ২০২৬-০১-২০, বাকি নিয়ম আগের মতো; শুরুতে একটি “Initial commit” 9d5de7a):

# (add newCheckout() skeleton, still unused; git add)
$ git commit -m "Add newCheckout skeleton behind flag"
[main 44ba59a] Add newCheckout skeleton behind flag
 1 file changed, 1 insertion(+)
$ git switch -c ruma/cart-total
Switched to a new branch 'ruma/cart-total'
# (fill in the cart total; git add)
$ git commit -m "Compute cart total in newCheckout"
[ruma/cart-total 4c283f9] Compute cart total in newCheckout
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git switch main
Switched to branch 'main'
$ git merge --ff-only ruma/cart-total
Updating 44ba59a..4c283f9
Fast-forward
 checkout.js | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git branch -d ruma/cart-total
Deleted branch ruma/cart-total (was 4c283f9).
$ git switch -c release/1.4
Switched to a new branch 'release/1.4'
$ git tag -a v1.4.0 -m "Release 1.4.0"
$ git switch main
Switched to branch 'main'
# (add the VAT line; git add)
$ git commit -m "Add VAT line to newCheckout"
[main 654735c] Add VAT line to newCheckout
 1 file changed, 1 insertion(+), 1 deletion(-)
# (create limits.conf with max_items = 50; git add)
$ git commit -m "fix: limit cart to 50 items"
[main 7b6618b] fix: limit cart to 50 items
 1 file changed, 1 insertion(+)
 create mode 100644 limits.conf
$ git switch release/1.4
Switched to branch 'release/1.4'
$ git cherry-pick -x 7b6618b
[release/1.4 aea1563] fix: limit cart to 50 items
 Date: Tue Jan 20 10:06:00 2026 +0600
 1 file changed, 1 insertion(+)
 create mode 100644 limits.conf
$ git tag -a v1.4.1 -m "Release 1.4.1"
$ git log --graph --oneline --all --decorate
* aea1563 (HEAD -> release/1.4, tag: v1.4.1) fix: limit cart to 50 items
| * 7b6618b (main) fix: limit cart to 50 items
| * 654735c Add VAT line to newCheckout
|/
* 4c283f9 (tag: v1.4.0) Compute cart total in newCheckout
* 44ba59a Add newCheckout skeleton behind flag
* 9d5de7a Initial commit
$ git log -1 --format=%B release/1.4
fix: limit cart to 50 items

(cherry picked from commit 7b6618b5b66fce31811818022b1bdb61b0fe0324)

গবেষণা কী বলে — DORA আর Accelerate

Branching নিয়ে বিতর্ক প্রায়ই মতামতের লড়াই। কিছু তথ্য এসেছে DORA (DevOps Research and Assessment) দলের বার্ষিক জরিপ থেকে, যার ফলাফল Nicole Forsgren, Jez Humble ও Gene Kim-এর বই Accelerate (২০১৮)-এ সংকলিত। আমাদের জানা মতে বইটি জানায়: যেসব দল trunk-based development মানে — একই সময়ে তিনটির কম সক্রিয় branch, branch এক দিনের কম সময়ে trunk-এ মেশে, আর “code freeze” বা integration-এর আলাদা পর্যায় নেই — তারা software delivery-র মাপকাঠিতে (কত ঘন ঘন deploy, পরিবর্তন production-এ পৌঁছাতে কত সময়, কত পরিবর্তন সমস্যা ঘটায়, সমস্যা থেকে ফিরতে কত সময়) গড়ে ভালো করে। এই DORA metric-গুলোর হিসাব পর্ব ৫৯-এ।

তবে এটি জরিপভিত্তিক সম্পর্ক (correlation), প্রতিটি দলের জন্য নিশ্চিত কারণ নয়: একই দলগুলোর প্রায়ই ভালো test, CI আর দ্রুত review-ও আছে, আর জরিপের দলগুলো মূলত service বা web software বানায়। কীভাবে পড়বেন — ভাবনার প্রশ্ন ৫-এ।

৯ · কৌশল বেছে নেওয়া — product, দল, release-এর গতি আর নিয়ন্ত্রণ

চারটি কৌশল পাশাপাশি রাখলে দেখা যায়, এরা আসলে একটি মাত্রার ওপর বসানো: বাঁয়ে “আলাদা রাখুন, নির্দিষ্ট দিনে মেলান” (Git Flow), ডানে “সবসময় মেলান, সুইচ দিয়ে লুকান” (TBD). GitHub Flow আর GitLab Flow মাঝখানে।

বাছাইয়ের সময় চারটি প্রশ্ন সবচেয়ে বেশি কাজে লাগে:

• Product-এর ধরন আর version: একই সময়ে কয়টি version-কে fix দিতে হয়? একটি হলে release branch-এর জটিলতা লাগে না।
• Release-এর গতি (cadence): দিনে কয়েকবার, সপ্তাহে একবার, না তিন মাসে একবার? আর deploy কি আপনার হাতে, না app store বা গ্রাহকের হাতে?
• দলের আকার আর পরিপক্বতা: কতজন, কতটা স্বয়ংক্রিয় test, review কত দ্রুত হয়? দুর্বল test নিয়ে TBD মানে প্রতিদিন ভাঙা trunk.
• নিয়ন্ত্রণ আর audit: ব্যাংকিং, স্বাস্থ্য বা সরকারি কাজে প্রায়ই প্রমাণ রাখতে হয় — কোন পরিবর্তন কে অনুমোদন দিলেন, কোন version কবে production-এ গেল। এর উত্তর branch-এর সংখ্যায় নয়; সুরক্ষিত branch, বাধ্যতামূলক review, tag আর pipeline-এর রেকর্ডে। Trunk-based দলও এগুলো পূরণ করতে পারে।

এই প্রশ্নগুলোকে নিয়মে লিখে ফেললে একটি ছোট “পরামর্শদাতা” বানানো যায়। নিচের নিয়মগুলো কোনো মানদণ্ড নয় — আলোচনার জন্য লেখা, যাতে প্রতিটি নিয়ম নিয়ে আপনি তর্ক করতে পারেন। চারটি কাল্পনিক দলের জন্য চালিয়ে দেখুন:

// A rule-based branching-strategy recommender. The rules are a teaching aid,
// written out so you can argue with them: each rule adds or removes points.
const RULES = [
  ["Git Flow",    "2+ versions supported at once", p => p.versions >= 2, +3],
  ["Git Flow",    "scheduled releases (< 1 per week)", p => p.deploysPerWeek < 1, +2],
  ["Git Flow",    "deploys 5+ times a week", p => p.deploysPerWeek >= 5, -3],
  ["GitHub Flow", "deploys at least weekly", p => p.deploysPerWeek >= 1, +3],
  ["GitHub Flow", "only one live version", p => p.versions === 1, +2],
  ["GitHub Flow", "2+ versions supported at once", p => p.versions >= 2, -3],
  ["GitHub Flow", "weak test automation", p => p.tests === "low", -1],
  ["GitLab Flow", "release gated by an outside step (store, client)", p => p.gated, +3],
  ["GitLab Flow", "2+ versions supported at once", p => p.versions >= 2, +1],
  ["GitLab Flow", "regulated: audit of what reached production", p => p.regulated, +1],
  ["Trunk-based", "strong automated tests and CI", p => p.tests === "high", +3],
  ["Trunk-based", "deploys 5+ times a week", p => p.deploysPerWeek >= 5, +2],
  ["Trunk-based", "weak test automation", p => p.tests === "low", -4],
  ["Trunk-based", "large team (30+), merge pain grows", p => p.team >= 30, +1],
];
const profiles = [
  { name: "web shop",      deploysPerWeek: 15,  versions: 1, team: 12, tests: "high",   gated: false, regulated: false },
  { name: "desktop app",   deploysPerWeek: 0.1, versions: 3, team: 8,  tests: "medium", gated: false, regulated: false },
  { name: "banking app",   deploysPerWeek: 0.5, versions: 2, team: 35, tests: "medium", gated: true,  regulated: true },
  { name: "2-person team", deploysPerWeek: 3,   versions: 1, team: 2,  tests: "low",    gated: false, regulated: false },
];
for (const p of profiles) {
  const score = { "Git Flow": 0, "GitHub Flow": 0, "GitLab Flow": 0, "Trunk-based": 0 };
  for (const [s, , test, pts] of RULES) if (test(p)) score[s] += pts;
  const ranked = Object.entries(score).sort((a, b) => b[1] - a[1]);
  const close = ranked[0][1] - ranked[1][1] <= 1 ? "  (close: discuss!)" : "";
  console.log(p.name.padEnd(14) + ranked.map(([s, v]) => s + " " + v).join(" | ") + close);
}
const why = RULES.filter(r => r[2](profiles[2])).map(r => r[0] + ": " + r[1] + " (" + (r[3] > 0 ? "+" : "") + r[3] + ")");
console.log("why, for banking app ->\n  " + why.join("\n  "));

web shop      GitHub Flow 5 | Trunk-based 5 | GitLab Flow 0 | Git Flow -3  (close: discuss!)
desktop app   Git Flow 5 | GitLab Flow 1 | Trunk-based 0 | GitHub Flow -3
banking app   Git Flow 5 | GitLab Flow 5 | Trunk-based 1 | GitHub Flow -3  (close: discuss!)
2-person team GitHub Flow 4 | Git Flow 0 | GitLab Flow 0 | Trunk-based -4
why, for banking app ->
  Git Flow: 2+ versions supported at once (+3)
  Git Flow: scheduled releases (< 1 per week) (+2)
  GitHub Flow: 2+ versions supported at once (-3)
  GitLab Flow: release gated by an outside step (store, client) (+3)
  GitLab Flow: 2+ versions supported at once (+1)
  GitLab Flow: regulated: audit of what reached production (+1)
  Trunk-based: large team (30+), merge pain grows (+1)

Branch-এর নাম আর সুরক্ষা — নিয়মকে কাগজ থেকে ব্যবস্থায়

নামের Git-নিয়ম আর প্রচলিত উপসর্গ (feature/, fix/, hotfix/, release/) পর্ব ১২-এর অংশ ৮-এ দেখেছেন। কৌশলের দিক থেকে কয়েকটি বাড়তি রীতি:

• নাম কৌশলের সাথে মিলিয়ে: Git Flow-এ উপসর্গই বলে দেয় branch কোথা থেকে খোলা আর কোথায় মিশবে; release branch-এ version নম্বর (release/1.4) রাখলে tag-এর সাথে মেলানো সহজ। TBD-তে branch এত ছোট যে নাম প্রায়ই ticket নম্বর বা লেখকের নামসহ (ruma/cart-total).
• সুরক্ষিত branch (branch protection): hosting platform-গুলোতে স্থায়ী branch-এ নিয়ম বসানো যায় — সরাসরি push নিষেধ, অন্তত একজনের অনুমোদন, সবুজ CI check বাধ্যতামূলক, force push আর মুছে ফেলা নিষেধ, কখনো কখনো linear history বাধ্যতামূলক। নাম আর বিস্তারিত platform-ভেদে আলাদা, আর লেখার সময়ে কিছু সুবিধা শুধু নির্দিষ্ট plan-এ পাওয়া যায়।
• Merge queue: ব্যস্ত trunk-এ দুটি PR আলাদাভাবে সবুজ, কিন্তু একসাথে ভাঙে (semantic conflict). Merge queue প্রতিটি PR-কে সর্বশেষ trunk-এর সাথে মেলানো অবস্থায় test করে, তবেই ঢোকায়। TBD-র বড় দলে এটি প্রায় অপরিহার্য।

১০ · AI-এর যুগে — branching-এর পরামর্শে AI-কে যাচাই

“আমাদের দলের জন্য একটি Git workflow বানিয়ে দিন” — AI কয়েক সেকেন্ডে সুন্দর ছক, command আর CI ফাইল দিয়ে দেয়। কিন্তু এই বিষয়ে তার কিছু চেনা ভুল আছে:

AI-এর দেওয়া workflow হাতে পেলে — চেকলিস্ট

• প্রস্তাবটি আমাদের version-সংখ্যা, deploy-এর গতি আর test-এর অবস্থার সাথে মেলে — শুধু “জনপ্রিয়” বলে বাছা হয়নি
• একটি throwaway repository-তে পুরো release আর hotfix প্রবাহ নিজে চালিয়ে git log --graph --oneline --all দেখেছি
• প্রতিটি fix শেষে যে সব branch-এ থাকার কথা, সেখানে আছে (git branch --contains)
• প্রতিটি command আর option git help বা অফিসিয়াল documentation-এ যাচাই করেছি; extension-এর command আলাদা করে চিনেছি
• সুরক্ষিত branch, review আর CI-এর নিয়ম platform-এ সত্যিই চালু করেছি, শুধু লিখে রাখিনি
• উল্লেখ করা গবেষণা, সাল আর লেখক মূল উৎসে মিলিয়েছি; prompt-এ কোনো token বা গোপন মান দিইনি