Pull request আর fork — দলের কাজের ধারা, review আর merge-এর নিয়ম

১ · Pull request কী — Git-এর command নয়, platform-এর সুবিধা

পর্ব ১৩-এ (Merge আর conflict) আপনি নিজের কম্পিউটারে git merge চালিয়েছিলেন — সিদ্ধান্তও আপনার, কাজও আপনার। কিন্তু দলে কাজ করলে প্রশ্ন বদলে যায়: আমার branch মূল কোডে ঢুকবে কি না, সেই সিদ্ধান্ত কে নেবে? কে আগে পড়ে দেখবে? Test চলেছে কি না কে নিশ্চিত করবে? এই প্রশ্নগুলোর উত্তর দিতেই তৈরি হয়েছে pull request — সংক্ষেপে PR.

খেয়াল করুন, “pull request” নামটি অনুরোধকারীর দিক থেকে: “আমার branch থেকে আমার কাজ আপনি pull করে নিন।” GitLab একই জিনিসকে বলে merge request (MR) — নামটি গ্রহণকারীর দিক থেকে: “এটি merge করুন।” Bitbucket আর GitHub বলে pull request. নাম আলাদা, মূল ধারণা একই। এই পর্বে দুটির জন্যই “PR” লিখব।

এক নজরে একটি PR-এর ভেতরে যা থাকে:

২ · Git-এর নিজস্ব পথ — format-patch, am আর request-pull

Platform ছাড়াও Git দিয়ে অন্যের কাছে কাজ পাঠানো যায় — এবং পৃথিবীর সবচেয়ে বড় open-source project-গুলোর কয়েকটি আজও তাই করে। এই পদ্ধতি বুঝলে PR-এর ভেতরের ধারণাটিও পরিষ্কার হয়: commit-কে এমনভাবে পাঠানো, যাতে অন্যজন পড়ে, মন্তব্য করে, তারপর নিজের history-তে বসাতে পারেন।

এই পর্বের পুরো গল্পটি একটি কাল্পনিক অনলাইন বাজার অ্যাপ-এর ছোট project bazar-cart নিয়ে। Maintainer রহিম (Rahim); বাইরের একজন অবদানকারী নাদিয়া (Nadia) checkout-এ coupon code-এর সুবিধা যোগ করতে চান। সব আউটপুট এই কম্পিউটারে Git ২.৫৩ দিয়ে আসল scratch repository-তে চালিয়ে নেওয়া; “upstream” আর “fork” দুটোই স্থানীয় bare repository, আর তারিখ স্থির রাখা হয়েছে, তাই hash-গুলো আপনিও একই পাবেন।

Patch তৈরি — git format-patch

নাদিয়ার feature/coupon branch-এ main-এর পরে দুটি commit আছে। git format-patch প্রতিটি commit-কে একটি email-আকারের ফাইলে লেখে:

$ git format-patch -o ../outgoing main
../outgoing/0001-Add-coupon-code-field.patch
../outgoing/0002-Limit-coupon-code-to-12-characters.patch
$ cat ../outgoing/0002-*.patch
From a36d5d25df1f1371ee60a208af54817e55ce312d Mon Sep 17 00:00:00 2001
From: Nadia <nadia@example.com>
Date: Thu, 15 Jan 2026 10:03:00 +0600
Subject: [PATCH 2/2] Limit coupon code to 12 characters

---
 cart.conf | 1 +
 1 file changed, 1 insertion(+)

diff --git a/cart.conf b/cart.conf
index 711a8db..cbe1a3f 100644
--- a/cart.conf
+++ b/cart.conf
@@ -3,3 +3,4 @@ max_items = 30
 delivery_fee = 60
 tax = 0
 coupon = enabled
+coupon_max_length = 12
--
2.53.0.windows.2

Patch বসানো — git am

রহিম email থেকে ফাইলগুলো সংরক্ষণ করে নিজের repository-তে git am (apply mailbox) চালালেন। এর মধ্যে রহিমের main-এ README-এর একটি বানান-সংশোধন যোগ হয়েছে:

$ git am ../outgoing/0001-Add-coupon-code-field.patch ../outgoing/0002-Limit-coupon-code-to-12-characters.patch
Applying: Add coupon code field
Applying: Limit coupon code to 12 characters
$ git log --format='%h %s  (author %an, committer %cn)' -3
6e4ce92 Limit coupon code to 12 characters  (author Nadia, committer Rahim)
6a4da1e Add coupon code field  (author Nadia, committer Rahim)
8fab4eb Fix typo in README  (author Rahim, committer Rahim)

Pull-এর অনুরোধ লেখা — git request-pull

অনেক commit হলে patch না পাঠিয়ে বলা সহজ: “আমার repository-র অমুক branch থেকে pull করে নিন।” git request-pull সেই অনুরোধের লেখা তৈরি করে — কোথা থেকে শুরু, কোথায় পাওয়া যাবে, কোন commit পর্যন্ত, আর সারসংক্ষেপ:

$ git request-pull main ../fork.git feature/coupon
The following changes since commit c5c366f1016194ea36864dea49dd4b62e0456014:

  Raise max items to 30 (2026-01-15 10:04:00 +0600)

are available in the Git repository at:

  ../fork.git feature/coupon

for you to fetch changes up to a36d5d25df1f1371ee60a208af54817e55ce312d:

  Limit coupon code to 12 characters (2026-01-15 10:07:00 +0600)

----------------------------------------------------------------
Nadia (2):
      Add coupon code field
      Limit coupon code to 12 characters

 cart.conf | 2 ++
 1 file changed, 2 insertions(+)

৩ · দুই ধরনের কাজের ধারা — shared repository বনাম fork

Platform-এ PR খোলার দুটি প্রচলিত ধারা আছে। পার্থক্যটা হলো: আপনার branch কোথায় থাকে, আর মূল repository-তে push করার অনুমতি আপনার আছে কি না।

Fork হলো platform-এর server-এ মূল repository-র একটি পূর্ণ কপি, যার মালিক আপনি। Git-এর দৃষ্টিতে এটি শুধু আরেকটি remote repository; “fork” শব্দটির বিশেষ অর্থ শুধু platform-এর কাছে — সে মনে রাখে কোন repository কোনটির কপি, তাই fork থেকে মূলটিতে PR খোলা যায়। মূল repository-কে প্রচলিত ভাষায় বলে upstream. নিচের ছবিতে পুরো ধারাটি দেখুন:

এবার আসল command-গুলো। Platform-এ “Fork” বোতাম চাপলে server যা করে, স্থানীয় ডেমোতে তার কাছাকাছি সমতুল্য হলো একটি --bare clone. তারপর নাদিয়া নিজের fork clone করেন আর মূল repository-কে upstream নামে যোগ করেন:

$ git clone --bare upstream.git fork.git
Cloning into bare repository 'fork.git'...
done.
$ git clone fork.git bazar-cart
Cloning into 'bazar-cart'...
done.
$ git remote set-url origin ../fork.git
$ git remote add upstream ../upstream.git
$ git remote -v
origin	../fork.git (fetch)
origin	../fork.git (push)
upstream	../upstream.git (fetch)
upstream	../upstream.git (push)
$ git switch -c feature/coupon
Switched to a new branch 'feature/coupon'
$ git commit -m "Add coupon code field"
[feature/coupon 39c5008] Add coupon code field
 1 file changed, 1 insertion(+)
$ git commit -m "Limit coupon code to 12 characters"
[feature/coupon 3762e90] Limit coupon code to 12 characters
 1 file changed, 1 insertion(+)
$ git push -u origin feature/coupon
To ../fork.git
 * [new branch]      feature/coupon -> feature/coupon
branch 'feature/coupon' set up to track 'origin/feature/coupon'.

এবার পুরো ধারাটি ধাপে ধাপে দেখুন। প্রতিটি ধাপে তিন জায়গার branch কোন commit-এ আছে, তা টেবিলে বদলাবে (hash-গুলো ওপরের আর পরের আউটপুট থেকে নেওয়া)।

৪ · Fork হালনাগাদ রাখা — upstream থেকে fetch, তারপর merge বা rebase

Fork তৈরির মুহূর্ত থেকেই সেটি পুরোনো হতে শুরু করে। Upstream-এ প্রতিদিন অন্যদের PR merge হয়, কিন্তু আপনার fork নিজে থেকে কিছু জানে না। আর সবচেয়ে বিভ্রান্তিকর ব্যাপার: আপনার local main “upstream branch” হিসেবে চেনে origin/main-কে, অর্থাৎ fork-কে, মূল repository-কে নয়। নিচে দেখুন — রহিম upstream-এ c5c366f যোগ করার পরে নাদিয়ার repository কী বলছে:

$ git fetch upstream
From ../upstream
 * [new branch]      main       -> upstream/main
$ git switch main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.
$ git status -sb
## main...origin/main
$ git rev-list --left-right --count main...upstream/main
0	1
$ git merge --ff-only upstream/main
Updating 714ea35..c5c366f
Fast-forward
 cart.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git push origin main
To ../fork.git
   714ea35..c5c366f  main -> main

নিচের মডেলে একই ঘটনা ছোট আকারে, প্রতিটি ধাপে দুই দিকের তুলনাসহ। এখানে commit-গুলোর নাম অক্ষর (A, B, C…), আর তিনটি repository শুধু “branch → tip” map:

// Fork sync model: three repositories, each a map of branch -> tip; parents shared.
const parentOf = { A: null, B: "A" };                      // commit -> its parent
const upstream = { main: "B" }, fork = { main: "B" }, local = { main: "B" };
const remoteRefs = {};                                     // local copies: origin/..., upstream/...
function commit(repo, branch, name) { parentOf[name] = repo[branch]; repo[branch] = name; }
function ancestry(c) { const s = new Set(); for (; c; c = parentOf[c]) s.add(c); return s; }
function aheadBehind(x, y) {                               // like git rev-list --left-right --count x...y
  const hx = ancestry(x), hy = ancestry(y);
  return [...hx].filter(c => !hy.has(c)).length + " ahead, " + [...hy].filter(c => !hx.has(c)).length + " behind";
}
function gitFetch(name, repo) { for (const b in repo) remoteRefs[name + "/" + b] = repo[b]; }
function report(step) {
  const up = remoteRefs["upstream/main"];
  console.log(step.padEnd(32) + "| main vs origin/main: " + aheadBehind(local.main, remoteRefs["origin/main"]) +
    " | vs upstream/main: " + (up ? aheadBehind(local.main, up) : "unknown"));
}
gitFetch("origin", fork); report("1 clone fork, add upstream");
local.feature = local.main; commit(local, "feature", "F1"); commit(local, "feature", "F2");
fork.feature = local.feature; report("2 commit F1,F2; push to fork");
commit(upstream, "main", "C"); commit(upstream, "main", "D");  // maintainers merge other PRs
report("3 upstream gets C,D (no fetch)");
gitFetch("upstream", upstream); report("4 git fetch upstream");
console.log("   feature vs upstream/main:", aheadBehind(local.feature, remoteRefs["upstream/main"]));
local.main = remoteRefs["upstream/main"]; report("5 merge --ff-only upstream/main");
fork.main = local.main; gitFetch("origin", fork); console.log("   fork main now", fork.main, "(pushed)");
// rebase feature: replay F1,F2 on top of the new main, getting new names F1', F2'
let base = local.main; const old = local.feature;
for (const c of ["F1", "F2"]) { parentOf[c + "'"] = base; base = c + "'"; }
local.feature = base;
console.log("6 rebase feature onto main".padEnd(32) + "| feature vs upstream/main:", aheadBehind(local.feature, remoteRefs["upstream/main"]));
console.log("   old tip", old, "-> new tip", local.feature, "; fork still has", fork.feature, "-> needs push --force-with-lease");

1 clone fork, add upstream      | main vs origin/main: 0 ahead, 0 behind | vs upstream/main: unknown
2 commit F1,F2; push to fork    | main vs origin/main: 0 ahead, 0 behind | vs upstream/main: unknown
3 upstream gets C,D (no fetch)  | main vs origin/main: 0 ahead, 0 behind | vs upstream/main: unknown
4 git fetch upstream            | main vs origin/main: 0 ahead, 0 behind | vs upstream/main: 0 ahead, 2 behind
   feature vs upstream/main: 2 ahead, 2 behind
5 merge --ff-only upstream/main | main vs origin/main: 2 ahead, 0 behind | vs upstream/main: 0 ahead, 0 behind
   fork main now D (pushed)
6 rebase feature onto main      | feature vs upstream/main: 2 ahead, 0 behind
   old tip F2 -> new tip F2' ; fork still has F2 -> needs push --force-with-lease

পুরোনো PR হালনাগাদ — merge না rebase?

PR অনেক দিন খোলা থাকলে (একে বলে stale PR) target branch অনেক এগিয়ে যায়। তখন দুটি সমস্যা: conflict-এর সম্ভাবনা বাড়ে, আর CI যে কোড পরীক্ষা করছে তা আজকের main-এর সাথে মেলানো অবস্থা নয়। দুটি উপায়:

• Upstream-এর main নিজের branch-এ merge: git merge upstream/main. History বদলায় না, force push লাগে না; কিন্তু PR-এ একটি “Merge branch 'main' into …” commit জমে। কিছু platform-এর “Update branch” বোতাম ঠিক এটাই করে (কোথাও rebase-এর বিকল্পও থাকে)।
• নতুন main-এর ওপর rebase: git rebase upstream/main, তারপর git push --force-with-lease. History সোজা থাকে, কিন্তু commit-গুলোর hash বদলায়, আর reviewer-দের আগের মন্তব্য কোন লাইনে ছিল তা কখনো কখনো “outdated” দেখায়।

আমাদের গল্পে নাদিয়া দ্বিতীয় পথ নিলেন:

$ git switch feature/coupon
Switched to branch 'feature/coupon'
Your branch is up to date with 'origin/feature/coupon'.
$ git rebase main
Successfully rebased and updated refs/heads/feature/coupon.
$ git push --force-with-lease
To ../fork.git
 + 3762e90...7e2341e feature/coupon -> feature/coupon (forced update)
$ git log --oneline --graph --all
* 7e2341e Limit coupon code to 12 characters
* e993824 Add coupon code field
* c5c366f Raise max items to 30
* 714ea35 Add README
* decee1a Add cart config

৫ · ভালো pull request-এর গঠন — ছোট পরিধি, শিরোনাম, বিবরণ আর linked issue

Reviewer আপনার মাথার ভেতরে ঢুকতে পারেন না। তিনি জানেন না কেন এই বদল, কী কী ভেবে দেখেছেন, কীভাবে পরীক্ষা করেছেন। PR-এর লেখাই তাঁর একমাত্র সূত্র। একটি ভালো PR-এর পাঁচটি অংশ:

1. ছোট পরিধি — এক PR, এক কাজ। Coupon-এর সুবিধা আর পুরো project-এর formatting একই PR-এ মেশালে reviewer আসল বদলটি খুঁজেই পাবেন না। Formatting বা নাম-বদলের মতো যান্ত্রিক কাজ আলাদা PR-এ দিন। বড় feature হলে কয়েকটি ধাপে ভাগ করুন — প্রতিটি নিজে চলার মতো আর test-সহ; অসম্পূর্ণ অংশ লুকিয়ে রাখতে feature flag (পর্ব ১৭ — Branching strategy).
2. শিরোনাম। এক লাইনে কী বদলাল, আদেশসূচক ক্রিয়া দিয়ে: Add coupon code to checkout — “fix”, “update”, “changes” নয়। অনেক দল squash merge-এর সময় শিরোনামকেই commit বার্তা বানায়, তাই এটি commit message-এর নিয়ম মেনে লেখা ভালো; Conventional Commits-এর feat:/fix: ধাঁচ পর্ব ১৮-এ (ভালো commit, tag আর release).
3. বিবরণ — কী, কেন, কীভাবে পরীক্ষা। নিচের ধরনের একটি PR template অনেক দল repository-তে রেখে দেয়, যাতে প্রতিটি নতুন PR-এ ঘরগুলো আগে থেকেই বসানো থাকে।
4. Linked issue. কোন issue বা কাজের অনুরোধ থেকে এই PR, তার নম্বর।
5. প্রস্তুতির অবস্থা। কাজ শেষ না হলে draft PR.

## কী বদলেছে
Checkout-এ coupon code লেখার ঘর যোগ হয়েছে; code-এর দৈর্ঘ্য সর্বোচ্চ 12 অক্ষর।

## কেন
Closes #42 — ঈদের অফারে দোকানগুলো coupon দিতে চায়।

## কীভাবে পরীক্ষা করা হয়েছে
- নতুন unit test: coupon_test.js (৬টি case, 0 থেকে 13 অক্ষর)
- হাতে: 12 অক্ষরের code গৃহীত, 13 অক্ষরের code প্রত্যাখ্যাত

## Screenshot
(checkout পাতা — আগে আর পরে)

## Reviewer-এর জন্য
cart.conf-এ নতুন key: coupon, coupon_max_length. পুরোনো কোনো key বদলায়নি।

Linked issue আর closing keyword: বিবরণে Closes #42, Fixes #42 বা Resolves #42 লিখলে অনেক platform PR merge হওয়ার সাথে সাথে issue #42 নিজে থেকে বন্ধ করে দেয়। তবে খুঁটিনাটি platform-ভেদে আলাদা: কোন শব্দগুলো গণ্য হয় (GitHub-এর তালিকায় close, fix, resolve-এর বিভিন্ন রূপ; GitLab-এর default তালিকা একটু বড় আর project-এ বদলানো যায়), সাধারণত শুধু default branch-এ merge হলেই কাজ করে, আর Bitbucket-এর মতো platform-এ issue প্রায়ই অন্য tool-এ (যেমন Jira) থাকে। লেখার সময়ের অবস্থা আপনার platform-এর documentation-এ মিলিয়ে নিন। শুধু উল্লেখ করতে চাইলে, বন্ধ নয় — Related to #42 বা শুধু #42.

Draft PR: কাজ অর্ধেক হলেও PR খুলে রাখা যায় “draft” হিসেবে — CI চলে, সহকর্মীরা আগেভাগে দিক নিয়ে মত দিতে পারেন, কিন্তু merge বোতাম বন্ধ আর reviewer-দের আনুষ্ঠানিক অনুরোধ যায় না। GitHub-এ “Draft pull request”, GitLab-এ “Draft” চিহ্ন (শিরোনামের শুরুতে Draft:); অন্য platform-এ সুবিধাটি ভিন্ন নামে বা না-ও থাকতে পারে। প্রস্তুত হলে “Ready for review”.

ছোট PR কেন দ্রুত এগোয় — গবেষণা আর একটি মডেল

অভিজ্ঞ দলগুলো প্রায় সবাই বলে “PR ছোট রাখুন”। এর পক্ষে কিছু প্রকাশিত প্রমাণ আছে, তবে সাবধানে পড়তে হয়। SmartBear-এর Jason Cohen-এর বই Best Kept Secrets of Peer Code Review (২০০৬)-এ Cisco-র একটি বড় code review সমীক্ষার কথা আছে, যার সুপারিশ ছিল একবারে কয়েকশো লাইনের বেশি review না করা — বেশি হলে ত্রুটি খুঁজে পাওয়ার হার কমে যায় বলে জানানো হয়েছে। এটি একটি কোম্পানির প্রকাশিত, একটি পরিবেশের ফল; সংখ্যাগুলো সব দলে খাটবে, এমন নয়। Google-এর প্রকাশ্য engineering practices নির্দেশিকাতেও (“Small CLs” অংশ) ছোট পরিবর্তনের পক্ষে যুক্তি দেওয়া আছে: দ্রুত review, বেশি মনোযোগী review, কম bug, সহজে revert. কোনো সর্বজনীন “আদর্শ লাইন-সংখ্যা” নেই।

কারণটির একটি অংশ queue-র গণিত, যা পর্ব ৬-এ (Kanban আর lean) Little’s law আর WIP-এ দেখেছেন। নিচের মডেলে একই পরিমাণ কাজ (৪০০ কর্মঘণ্টায় ঘণ্টায় ১০০ লাইন) বিভিন্ন আকারের PR-এ ভাগ করা হয়েছে। অনুমানগুলো কোডের শুরুতে লেখা — এগুলো মডেল, মাপা তথ্য নয়:

// PR review queue: same total work (100 changed lines per working hour, 400 hours),
// cut into PRs of different sizes. ASSUMPTIONS (a model, not measured data):
//  A1 one reviewer, first come first served; a review reads 200 lines per hour
//  A2 every 50 lines carry a 10% chance of a finding -> P(approve) = 0.9^(L/50)
//  A3 after "request changes" the author needs 0.5 h + L/100 h, then the PR re-enters
//     the queue; a re-review reads the whole PR again at half the time
function mulberry32(a) { return () => { a |= 0; 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; }; }
function simulate(L, seed) {
  const rnd = mulberry32(seed), n = Math.round(400 * 100 / L), gap = L / 100;
  let t = 0; const prs = [];
  for (let i = 0; i < n; i++) { t += -Math.log(1 - rnd()) * gap; prs.push({ open: t, ready: t, rounds: 0, wait: 0 }); }
  let free = 0, busy = 0, pending = prs.slice();
  while (pending.length) {
    pending.sort((a, b) => a.ready - b.ready);
    const p = pending.shift(), start = Math.max(free, p.ready);
    p.wait += start - p.ready; p.rounds++;
    const work = (L / 200) * (p.rounds === 1 ? 1 : 0.5); busy += work; free = start + work;
    if (rnd() < Math.pow(0.9, L / 50)) p.merged = free;
    else { p.ready = free + 0.5 + L / 100; pending.push(p); }
  }
  const avg = f => prs.reduce((s, p) => s + f(p), 0) / n;
  const sorted = prs.map(p => p.merged - p.open).sort((a, b) => a - b);
  return { n, rounds: avg(p => p.rounds), wait: avg(p => p.wait), med: sorted[Math.floor(n / 2)],
           p90: sorted[Math.floor(n * 0.9)], load: busy / 400 };
}
console.log("lines/PR  PRs  rounds  reviewer-load  queue-wait(h)  open->merged median / p90 (h)");
for (const L of [50, 100, 200, 400, 800]) {
  const r = simulate(L, 2026);
  console.log(String(L).padStart(8), String(r.n).padStart(4), r.rounds.toFixed(2).padStart(7), (Math.round(r.load * 100) + "%").padStart(14),
    r.wait.toFixed(2).padStart(14), (r.med.toFixed(1) + " / " + r.p90.toFixed(1)).padStart(20));
}

lines/PR  PRs  rounds  reviewer-load  queue-wait(h)  open->merged median / p90 (h)
      50  800    1.11            53%           0.18            0.3 / 1.4
     100  400    1.25            56%           0.53            0.9 / 3.1
     200  200    1.50            62%           1.32            1.9 / 9.5
     400  100    2.12            78%           3.63           8.2 / 27.5
     800   50    4.74           144%         101.23        131.5 / 300.1

৬ · Review, status check আর branch protection

Review-এর তিন রকম সিদ্ধান্ত

বেশিরভাগ platform-এ reviewer লাইনে লাইনে মন্তব্য লিখে শেষে একটি সামগ্রিক সিদ্ধান্ত জানান। GitHub-এর তিনটি নাম সবচেয়ে পরিচিত:

GitLab-এ মূলত “Approve” আর মন্তব্যের thread (নিয়ম চালু থাকলে প্রতিটি thread “resolve” করতে হয়); Bitbucket-এ approve আর changes চাওয়ার ব্যবস্থা — নাম আর আচরণ platform ও সংস্করণ-ভেদে আলাদা। কী দেখবেন আর কীভাবে মন্তব্য লিখবেন, তার পূর্ণ আলোচনা পর্ব ৪৪-এ (Code review).

Status check — যন্ত্রের review

PR খুললে বা নতুন commit push করলে platform CI চালায়: build, unit test, linter, নিরাপত্তা scan. প্রতিটির ফল PR-এর পাতায় একটি status check হয়ে দেখায় — সবুজ টিক, লাল ক্রস বা হলুদ “চলছে”। একটি গুরুত্বপূর্ণ সূক্ষ্মতা: CI সাধারণত পরীক্ষা করে PR-এর branch আর target-এর merge করা অবস্থা (অনেক platform একটি অস্থায়ী merge commit বানিয়ে তাতে চালায়) — কিন্তু target এগিয়ে গেলে পুরোনো সবুজ ফল আর আজকের অবস্থা বোঝায় না। এজন্য কোনো কোনো দল “merge-এর আগে branch হালনাগাদ থাকতে হবে” নিয়ম রাখে, বা merge queue ব্যবহার করে। Pipeline কীভাবে বানাবেন, তা পর্ব ৫৮-এ (Continuous integration).

Branch protection, বাধ্যতামূলক review আর CODEOWNERS

main-কে সুরক্ষিত রাখতে platform-এ branch protection নিয়ম বসানো যায় (GitHub-এ এখন “rulesets”-ও আছে, GitLab-এ “protected branches”, Bitbucket-এ “branch restrictions” বা “branch permissions” — লেখার সময়ের নাম, সংস্করণভেদে আলাদা)। সাধারণ নিয়মগুলো:

• সরাসরি push নিষেধ — সব বদল PR দিয়ে
• অন্তত ১ বা ২টি approval বাধ্যতামূলক; নতুন commit এলে পুরোনো approval বাতিল (ঐচ্ছিক)
• নির্দিষ্ট status check সবুজ হতেই হবে
• সব মন্তব্যের thread মীমাংসা হতে হবে
• Force push আর branch মোছা নিষেধ; কখনো signed commit বাধ্যতামূলক (পর্ব ৫৭)
• কোন merge পদ্ধতি চলবে (শুধু squash, বা শুধু linear history)

কোন ফাইল কে review করবেন, তা ঠিক করে CODEOWNERS ফাইল — GitHub আর GitLab দুটিতেই আছে (Bitbucket-এ সমতুল্য সুবিধা লেখার সময়ে ভিন্নভাবে)। প্রতিটি লাইনে একটি path-pattern আর মালিক; GitHub-এ ফাইলের শেষের দিকের মিলে-যাওয়া লাইনটি প্রাধান্য পায়:

# Default owners for everything in the repository
*                 @example/core-team

# Payment code needs the payments team
/src/payment/     @example/payments

# Database migrations need a database reviewer
*.sql             @example/db-reviewers

এখন কেউ src/payment/-এর কোনো ফাইল বদলালে platform নিজে থেকেই payments দলকে reviewer হিসেবে যোগ করে, আর “code owner-এর review বাধ্যতামূলক” নিয়ম চালু থাকলে তাঁদের approval ছাড়া merge হবে না। বড় monorepo-তে এটি বিশেষ কাজের (পর্ব ১৯ — বড় repository).

এবার একটি PR-এর পুরো জীবন ধাপে ধাপে দেখুন — ধরুন main-এ নিয়ম: ১টি approval, CI সবুজ, আর শুধু squash merge.

৭ · Review-এর মন্তব্য সামলানো — নতুন commit, fixup আর autosquash

Reviewer পরিবর্তন চাইলে দুটি প্রচলিত পথ:

• সাধারণ নতুন commit (Rename coupon_len) push করা। সহজ, force push লাগে না, আর reviewer ঠিক কী বদলাল আলাদা করে দেখতে পান। দল squash merge করলে শেষে সব এক commit হবে, তাই মাঝের commit-গুলো নিয়ে চিন্তা নেই।
• Fixup commit বানিয়ে পরে autosquash. দল যদি merge commit বা rebase-merge ব্যবহার করে (অর্থাৎ PR-এর প্রতিটি commit main-এ যাবে), তাহলে “typo ঠিক”, “review মেটানো” ধরনের commit history নোংরা করে। Fixup ঠিক যে commit-কে সংশোধন করছে, তার সাথে মিশে যায়।

$ git commit --fixup=7e2341e
[feature/coupon 101e41a] fixup! Limit coupon code to 12 characters
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git log --oneline main..
101e41a fixup! Limit coupon code to 12 characters
7e2341e Limit coupon code to 12 characters
e993824 Add coupon code field
$ git rebase -i --autosquash main
Successfully rebased and updated refs/heads/feature/coupon.
$ git log --oneline main..
a36d5d2 Limit coupon code to 12 characters
e993824 Add coupon code field
$ git push --force-with-lease
To ../fork.git
 + 7e2341e...a36d5d2 feature/coupon -> feature/coupon (forced update)

৮ · Merge-এর তিন পথ — merge commit, squash আর rebase

PR approve হলো। এবার merge বোতামের পাশের ছোট তীর চাপলে (GitHub-এ) repository-র সেটিংয়ে চালু থাকা বিকল্পগুলো দেখা যায় — সব চালু থাকলে তিনটি: Create a merge commit, Squash and merge আর Rebase and merge. GitLab-এ project-এর সেটিংয়ে merge পদ্ধতি বাছাই করা হয় (merge commit, semi-linear history-সহ merge commit, fast-forward) আর squash আলাদা একটি বিকল্প; Bitbucket-এও merge commit, squash আর fast-forward ধরনের কৌশল আছে — নাম আর ঠিক আচরণ platform ও সংস্করণ-ভেদে আলাদা, লেখার সময়ের documentation দেখে নিন। তিনটির পেছনের Git-কাজ কিন্তু একই, আর আপনি নিজের কম্পিউটারেই তা চালিয়ে দেখতে পারেন।

রহিম নাদিয়ার fork-কে remote হিসেবে যোগ করে branch-টি আনলেন। Merge-এর ঠিক আগে অবস্থা:

$ git remote add nadia ../fork.git
$ git fetch nadia
From ../fork
 * [new branch]      feature/coupon -> nadia/feature/coupon
 * [new branch]      main           -> nadia/main
$ git log --oneline --graph main nadia/feature/coupon
* 8fab4eb Fix typo in README
| * a36d5d2 Limit coupon code to 12 characters
| * e993824 Add coupon code field
|/
* c5c366f Raise max items to 30
* 714ea35 Add README
* decee1a Add cart config

Merge base c5c366f; main-এ একটি নতুন commit (8fab4eb), PR-এ দুটি। এই একই অবস্থার তিনটি হুবহু কপিতে তিনটি পদ্ধতি চালানো হলো।

১. Merge commit = git merge --no-ff

$ git merge --no-ff nadia/feature/coupon -m 'Merge pull request #7 from nadia/feature/coupon'
Merge made by the 'ort' strategy.
 cart.conf | 2 ++
 1 file changed, 2 insertions(+)
$ git log --oneline --graph
*   b96aa2e Merge pull request #7 from nadia/feature/coupon
|\
| * a36d5d2 Limit coupon code to 12 characters
| * e993824 Add coupon code field
* | 8fab4eb Fix typo in README
|/
* c5c366f Raise max items to 30
* 714ea35 Add README
* decee1a Add cart config

২. Squash and merge = git merge --squash + git commit

$ git merge --squash nadia/feature/coupon
Automatic merge went well; stopped before committing as requested
Squash commit -- not updating HEAD
$ git status -s
M  cart.conf
$ git commit --author='Nadia <nadia@example.com>' -m 'Add coupon code support (#7)'
[main 04dd1b1] Add coupon code support (#7)
 Author: Nadia <nadia@example.com>
 1 file changed, 2 insertions(+)
$ git log --oneline --graph
* 04dd1b1 Add coupon code support (#7)
* 8fab4eb Fix typo in README
* c5c366f Raise max items to 30
* 714ea35 Add README
* decee1a Add cart config
$ git log -1 --format='%h author %an, committer %cn'
04dd1b1 author Nadia, committer Rahim

৩. Rebase and merge = git rebase + fast-forward

$ git switch -c pr-7 nadia/feature/coupon
Switched to a new branch 'pr-7'
branch 'pr-7' set up to track 'nadia/feature/coupon'.
$ git rebase main
Successfully rebased and updated refs/heads/pr-7.
$ git switch main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.
$ git merge --ff-only pr-7
Updating 8fab4eb..aced851
Fast-forward
 cart.conf | 2 ++
 1 file changed, 2 insertions(+)
$ git log --oneline --graph
* aced851 Limit coupon code to 12 characters
* 2ba98d0 Add coupon code field
* 8fab4eb Fix typo in README
* c5c366f Raise max items to 30
* 714ea35 Add README
* decee1a Add cart config

তিনটি কপির শেষ অবস্থায় git rev-parse --short HEAD^{tree} চালালে প্রতিটিতে একই উত্তর আসে: b0db900. অর্থাৎ ফাইলের শেষ snapshot তিনটিতেই হুবহু এক (patch-এর পথে git am দিয়েও একই tree পাওয়া যায়) — পার্থক্য শুধু history-র আকারে। নিচের stepper-এ তিনটি পাশাপাশি দেখুন:

নিচের প্রোগ্রামে একই তিনটি পদ্ধতি একটি খেলনা commit-মডেলে। এখানে commit-এর id একটি ছোট hash ফাংশন (FNV-1a, Git-এর SHA-1-এর বদলে শুধু শেখানোর জন্য) দিয়ে parent, বার্তা আর পরিবর্তন থেকে হিসাব হয় — তাই আসল Git-এর মতোই parent বদলালে id বদলায়:

// Three platform merge methods on the same PR. A commit = {id, msg, parents, change}.
// ids come from FNV-1a 32-bit (a stand-in for Git's SHA-1), so a commit with a new
// parent gets a new id - exactly why rebased commits change their hashes.
function fnv(s) { let h = 0x811c9dc5; for (const c of s) h = Math.imul(h ^ c.charCodeAt(0), 0x01000193) >>> 0; return h.toString(16).padStart(8, "0").slice(0, 7); }
function mk(msg, parents, change) { const id = fnv(parents.join() + "|" + msg + "|" + change); return { id, msg, parents, change }; }
const A = mk("Raise max items to 30", [], "max_items");
const T = mk("Fix typo in README", [A.id], "readme");          // main moved on after the PR opened
const P1 = mk("Add coupon code field", [A.id], "coupon");
const P2 = mk("Limit coupon code to 12 characters", [P1.id], "coupon_len");
const pr = [P1, P2];
function show(name, commits) {                                  // newest first, like git log --oneline
  console.log("== " + name);
  for (const c of [...commits].reverse())
    console.log("  " + c.id + " " + c.msg + (c.parents.length > 1 ? "   <- 2 parents" : ""));
}
// 1) Merge commit (git merge --no-ff): PR commits kept as they are + one merge commit.
const M = mk("Merge pull request #7", [T.id, P2.id], "merge");
show("merge commit", [A, P1, P2, T, M]);
// 2) Squash and merge (git merge --squash + git commit): one new commit, all changes in it.
const S = mk("Add coupon code support (#7)", [T.id], pr.map(c => c.change).join("+"));
show("squash and merge", [A, T, S]);
// 3) Rebase and merge (git rebase + fast-forward): each PR commit replayed on top of T.
let base = T.id; const replayed = [];
for (const c of pr) { const n = mk(c.msg, [base], c.change); replayed.push(n); base = n.id; }
show("rebase and merge", [A, T, ...replayed]);
console.log("old PR ids:", pr.map(c => c.id).join(" "), "| after rebase:", replayed.map(c => c.id).join(" "));
const changes = l => l.map(c => c.change).filter(x => x !== "merge").join("+").split("+").sort().join(",");
console.log("same final changes?", changes([A, P1, P2, T]) === changes([A, T, S]) && changes([A, T, S]) === changes([A, T, ...replayed]));

== merge commit
  cb7a495 Merge pull request #7   <- 2 parents
  397fb8b Fix typo in README
  66688c3 Limit coupon code to 12 characters
  d1dcdb3 Add coupon code field
  1327aff Raise max items to 30
== squash and merge
  3d22fd6 Add coupon code support (#7)
  397fb8b Fix typo in README
  1327aff Raise max items to 30
== rebase and merge
  30f1e5f Limit coupon code to 12 characters
  6cdb3fa Add coupon code field
  397fb8b Fix typo in README
  1327aff Raise max items to 30
old PR ids: d1dcdb3 66688c3 | after rebase: 6cdb3fa 30f1e5f
same final changes? true

৯ · শিষ্টাচার আর যোগাযোগ — দলে PR-এর ভাষা

PR একটি প্রযুক্তিগত জিনিস, কিন্তু এর বেশিরভাগ সমস্যা মানুষের। দলীয় ক্রিকেট ম্যাচের কথা ভাবুন: ফিল্ডার ক্যাচ ফেললে অধিনায়ক যদি সবার সামনে চেঁচান, পরের বলে সে আরও ভয়ে থাকবে। আর অধিনায়ক যদি কিছুই না বলেন, একই ভুল বারবার হবে। ভালো অধিনায়ক নির্দিষ্ট করে, শান্তভাবে, ম্যাচের স্বার্থে বলেন। Review-ও তাই।

PR-এর লেখকের জন্য

• নিজের PR আগে নিজে review করুন — diff-এর প্রতিটি লাইন পড়ুন। Debug-এর console.log, মন্তব্য করে রাখা কোড, অপ্রাসঙ্গিক ফাইল প্রায়ই এখানেই ধরা পড়ে।
• Reviewer-এর প্রতিটি মন্তব্যের উত্তর দিন: “ঠিক করেছি (commit 101e41a)”, বা কেন একমত নন তার কারণ। চুপচাপ thread “resolve” করে দেওয়া এড়িয়ে চলুন।
• মন্তব্যকে ব্যক্তিগত আক্রমণ ভাববেন না — review হয় কোডের, মানুষের নয়।
• অনেক দিন উত্তর না এলে ভদ্রভাবে মনে করিয়ে দিন; দলের চ্যানেলে একটি লিংক আর এক লাইনের সারাংশ যথেষ্ট।

Reviewer-এর জন্য

• প্রশ্নের আকারে লিখুন, আদেশে নয়: “এখানে null এলে কী হবে?” — “এটা ভুল” নয়।
• কোনটি বাধ্যতামূলক আর কোনটি রুচির ব্যাপার, আলাদা করে বলুন। অনেক দল nit: (ছোট, ঐচ্ছিক), question:, suggestion: ধরনের উপসর্গ ব্যবহার করে — “Conventional Comments” নামে এর একটি প্রকাশিত প্রস্তাবও আছে। এ ধরনের ঐচ্ছিক মন্তব্যকে বলে nitpick.
• দ্রুত সাড়া দিন। সম্পূর্ণ review এখনই সম্ভব না হলে অন্তত জানান কখন দেখবেন। অংশ ৫-এর মডেল দেখিয়েছে, অপেক্ষাই PR-এর সবচেয়ে বড় খরচ।
• ভালো কাজের প্রশংসাও লিখুন — বিশেষ করে নতুন সহকর্মীর প্রথম PR-এ।

বাংলাভাষী দলে কয়েকটি বাস্তব কথা

আমাদের অনেক দলে কোডের কথা হয় ইংরেজি আর বাংলা মিশিয়ে, কখনো Banglish-এ। কোনোটিই ভুল নয়; দরকার হলো দলের সবাই যেন বুঝতে পারেন। কয়েকটি অভ্যাস কাজে দেয়:

• PR-এর শিরোনাম, commit বার্তা আর কোডের মন্তব্য একটি ভাষায় (সাধারণত ইংরেজি), কারণ ভবিষ্যতে দেশের বাইরের কেউ বা search tool এগুলো পড়বে। আলোচনার thread-এ যে ভাষায় সবাই স্বচ্ছন্দ, সেটি চলতে পারে।
• বয়স বা পদের সংকোচ: “ভাইয়া/আপু”-র কোডে প্রশ্ন তুলতে অনেক নতুন সদস্য দ্বিধা করেন। দলের নেতারা নিজে থেকে বলে দিলে ভালো: “আমার PR-এও প্রশ্ন করবেন, সেটাই কাজ।” Review-কে সম্মানের পরীক্ষা নয়, শেখার জায়গা হিসেবে দেখা জরুরি।
• লেখায় সুর বোঝা কঠিন। সামনাসামনি যে কথা হাসিমুখে বলতেন, লেখায় তা কড়া শোনাতে পারে। জটিল বা আবেগপ্রবণ আলোচনা দীর্ঘ হলে ছোট একটি call করে নিন, তারপর সিদ্ধান্তটি PR-এ লিখে রাখুন — যাতে পরে যে কেউ জানতে পারেন।
• সময় আর ছুটি: ঈদ বা পূজার আগে বড় PR না খোলাই ভালো; reviewer না থাকলে PR পুরোনো হয়ে conflict জমে।

১০ · AI-এর যুগে — PR-এর কাজে AI-কে যাচাই

AI এখন PR-এর বিবরণ লিখে দেয়, diff পড়ে review মন্তব্য দেয়, এমনকি conflict মেটানোর command সাজেস্ট করে। কাজের সহায়ক, কিন্তু এই বিষয়ে এর কিছু চেনা ভুল আছে:

AI-এর সাহায্যে PR — চেকলিস্ট

• বিবরণের প্রতিটি দাবি diff আর CI-এর ফলের সাথে মিলিয়েছি
• AI-এর দেওয়া প্রতিটি Git command git help দিয়ে যাচাই করেছি; history-বদলানো কিছু হলে আগে একটি throwaway clone-এ চালিয়েছি
• --force নয়, শুধু নিজের branch-এ --force-with-lease
• AI reviewer-এর মন্তব্য পড়ে নিজে বিচার করেছি; মানুষের review-এর বিকল্প ভাবিনি
• প্রম্পট থেকে password, token, গ্রাহকের তথ্য মুছেছি
• AI-এর লেখা কোড থাকলে তার license আর উৎস নিয়ে প্রশ্ন তুলেছি, আর PR-এ জানিয়েছি কোন অংশ AI-সহায়তায় লেখা (দলের নিয়ম অনুযায়ী)