Version control কী — centralized বনাম distributed, Git-এর জন্ম আর setup

১ · final_v2_real_final.docx — সমস্যাটা চিনে নিই

আপনার কম্পিউটারে কি এমন একটি ফোল্ডার আছে? report.docx, report_final.docx, report_final_v2.docx, report_final_v2_real_final.docx. প্রতিটি নাম একটি ছোট আশার গল্প: “এটাই শেষ।” কিন্তু এক সপ্তাহ পরে আর মনে থাকে না কোনটিতে কী বদলেছিলেন, আর কেন।

একা কাজ করলে এটা বিরক্তিকর, দলে কাজ করলে বিপজ্জনক। তিনজন মিলে কোড লিখছেন; কেউ ইমেইলে zip পাঠান, কেউ শেয়ার্ড ফোল্ডারে ফাইল রাখেন। তখন তিনটি প্রশ্নের উত্তর কেউ জানেন না: এখন আসল কপি কোনটি? গতকাল কে কী বদলেছেন? যে bug আজ দেখা দিল, সেটা কোন পরিবর্তনে এল?

নিচের স্টেপারে একটি কাল্পনিক অনলাইন বাজার অ্যাপের দুই developer, Rina আর Karim, একটি শেয়ার্ড ফোল্ডারে price.js ফাইলে কাজ করছেন। কোনো version control নেই। “পরে” চেপে দেখুন কাজ কীভাবে হারায়:

এখন একই ঘটনা একটু বড় করে দেখি। দুজন developer ১২ বার একই ১০ লাইনের ফাইল কপি করে কাজ করলেন; প্রতিবার দুজনে একটি করে লাইন বদলালেন। প্রথম পদ্ধতিতে শেষে যিনি save করেন, তাঁর ফাইলটাই থাকে। দ্বিতীয় পদ্ধতিতে একটি version control-এর মতো নিয়ম: save-এর আগে দেখা হয়, “আপনি কপি নেওয়ার পরে ফাইলটি কি বদলেছে?” বদলালে আলাদা লাইনের পরিবর্তন মিলিয়ে দেওয়া হয়, আর একই লাইন হলে থেমে মানুষকে জিজ্ঞেস করা হয়। কোন লাইন কে বদলাবেন, তা ঠিক হয় একটি seed-যুক্ত random সংখ্যা দিয়ে, তাই প্রতিবার একই ফল আসে:

// Two developers edit a 10-line shared file in 12 rounds. Each round both copy the file,
// each changes one random line, then they save back (Rina first, then Karim).
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; }; }
function simulate(useVcs) {
  const rnd = mulberry32(42);
  let file = Array.from({ length: 10 }, (_, i) => "line" + i);
  let kept = 0, lost = 0, merged = 0, conflicts = 0;
  for (let round = 1; round <= 12; round++) {
    const base = file.slice();                         // both start from the same copy
    const a = Math.floor(rnd() * 10), b = Math.floor(rnd() * 10);
    const rina = base.slice(); rina[a] = "R" + round;
    const karim = base.slice(); karim[b] = "K" + round;
    file = rina;                                       // Rina saves first: always fine
    if (!useVcs) {                                     // copy-overwrite: last save wins
      file = karim; kept++; lost++;                     // Rina's edit is silently gone
    } else if (a !== b) {                              // VCS sees the file changed since Karim's copy
      file = file.slice(); file[b] = karim[b]; kept += 2; merged++; // different lines: auto-merge
    } else {                                           // same line: stop and ask a human
      file = file.slice(); file[a] = "R" + round + "+K" + round; kept += 2; conflicts++;
    }
  }
  return { kept, lost, merged, conflicts, last: file.join(" ") };
}
const f = (r) => `edits kept ${r.kept}/24, lost ${r.lost}, auto-merged ${r.merged}, conflicts ${r.conflicts}`;
console.log("copy-overwrite :", f(simulate(false)));
const v = simulate(true);
console.log("with VCS check :", f(v));
console.log("final file (VCS):", v.last);

copy-overwrite : edits kept 12/24, lost 12, auto-merged 0, conflicts 0
with VCS check : edits kept 24/24, lost 0, auto-merged 11, conflicts 1
final file (VCS): K12 R8 R6 K7 K10 R12 R9+K9 R7 R11 line9

২ · Version control আসলে কী দেয়

Version control (বা version control system, সংক্ষেপে VCS; অনেকে source control-ও বলেন) হলো এমন একটি ব্যবস্থা, যা ফাইলের প্রতিটি পরিবর্তন সময়ের ক্রমে রেকর্ড করে, যাতে পরে যেকোনো পুরোনো অবস্থা দেখা বা ফিরিয়ে আনা যায়, আর অনেকে নিরাপদে একসাথে কাজ করতে পারেন। মূলত কোডের জন্য তৈরি, কিন্তু যেকোনো লেখা-ভিত্তিক ফাইলে কাজ করে — বই, গবেষণাপত্র, configuration, এমনকি এই ওয়েবসাইটের পাতাও।

প্রতিটি সংরক্ষিত পরিবর্তনকে Git-এ বলে commit: project-এর একটি মুহূর্তের ছবি, সাথে লেখকের নাম, সময় আর একটি বার্তা। এই commit-গুলো যেখানে জমা থাকে, তা হলো repository (সংক্ষেপে repo). এ দুটি শব্দ দিয়েই নিচের ছয়টি সুবিধা বোঝা যায়:

পর্ব ০৬-এ (Kanban আর lean) দেখেছেন, ভালো দল ভুলের পরে দোষী মানুষ নয়, দুর্বল প্রক্রিয়া খোঁজে; কাজ সহজে ফেরানো গেলে মানুষ পরীক্ষা করতেও ভয় পান না। মজার ব্যাপার, Git-এ একটি command-এর নামই git blame — প্রতিটি লাইন শেষবার কোন commit-এ বদলেছে, তা দেখায়। নামটি কঠিন শোনালেও কাজটি তদন্তের, শাস্তির নয়; পর্ব ৫৫-এ এটি আর bisect দেখবেন।

৩ · তিন প্রজন্ম — local, centralized আর distributed

Version control-এর ইতিহাস মোটামুটি তিনটি ধাপে ভাগ করা যায়। প্রতিটি ধাপ আগেরটির একটি বড় সীমাবদ্ধতা দূর করেছে।

প্রথম প্রজন্ম — local VCS

Local VCS একটি কম্পিউটারে, সাধারণত প্রতিটি ফাইলের পাশে একটি আলাদা ইতিহাস-ফাইলে পুরোনো version রাখে। Bell Labs-এর SCCS (Marc Rochkind, ১৯৭২-এর দিকে) আর Purdue বিশ্ববিদ্যালয়ের Walter Tichy-র RCS (১৯৮২-র দিকে প্রথম প্রকাশ; Tichy-র প্রবন্ধ ১৯৮৫) এই ধারার পরিচিত নাম। RCS প্রতিটি version পুরোটা না রেখে আগের version থেকে পার্থক্যটুকু (delta) রাখত, ফলে জায়গা বাঁচত। কিন্তু সীমাবদ্ধতা স্পষ্ট: ইতিহাস এক মেশিনে, এক একটি ফাইল ধরে; দলের কাজ ভাগ করার ব্যবস্থা প্রায় নেই।

দ্বিতীয় প্রজন্ম — centralized VCS

Centralized VCS-এ পুরো ইতিহাস থাকে একটি কেন্দ্রীয় server-এ। প্রত্যেক developer server থেকে checkout করে ফাইলের একটি working copy আনেন, কাজ করেন, তারপর commit করে পরিবর্তন সরাসরি server-এ পাঠান। CVS (Dick Grune ১৯৮৬ সালে RCS-এর ওপর shell script হিসেবে শুরু করেন; পরে C-তে নতুন করে লেখা হয়) আর Subversion (SVN; CollabNet-এর উদ্যোগে ২০০০ সালে শুরু, ১.০ প্রকাশ ২০০৪-এ, এখন Apache Software Foundation-এর project) এই ধারার সবচেয়ে প্রচলিত দুটি। Perforce-এর মতো বাণিজ্যিক tool-ও মূলত centralized.

সুবিধা অনেক: সবাই একই জায়গা দেখেন, অনুমতি নিয়ন্ত্রণ সহজ (কে কোন ফোল্ডারে লিখতে পারবেন), আর ব্যবস্থাটা বোঝা সহজ। কিন্তু server-টি একটি single point of failure. Server বা network বন্ধ থাকলে commit করা যায় না, এমনকি পুরোনো ইতিহাস দেখার উপায়ও থাকে না। আর server-এর disk নষ্ট হলে, ভালো backup না থাকলে, পুরো ইতিহাস হারায় — কারণ developer-দের কাছে আছে শুধু সর্বশেষ ফাইল।

দুজনে একই ফাইল বদলাতে চাইলে — locking নাকি merging?

Centralized যুগে দুটি দর্শন ছিল, আর দুটিই আজও প্রাসঙ্গিক:

CVS-এর নামের “Concurrent” শব্দটিই এই বিপ্লবের ইঙ্গিত: একাধিক মানুষ একই ফাইলে একসাথে কাজ করতে পারবেন। অভিজ্ঞতায় দেখা গেল, কোডের বেশিরভাগ সমান্তরাল পরিবর্তন ফাইলের আলাদা অংশে পড়ে — ঠিক যেমন অংশ ১-এর সিমুলেটরে ১২ দফার ১১টিতে।

তৃতীয় প্রজন্ম — distributed VCS

Distributed VCS-এ প্রত্যেক developer-এর কাছে থাকে পুরো repository — প্রতিটি commit, প্রতিটি branch, পুরো ইতিহাস। শুরু হয় একটি clone দিয়ে: অন্য একটি repository-র সম্পূর্ণ কপি। তারপর commit হয় নিজের কম্পিউটারেই, network ছাড়া। দলের সাথে ভাগ করতে চাইলে push (নিজের commit পাঠানো) আর pull (অন্যদের commit আনা)। যে server-এ সবাই push করেন, সেটি প্রযুক্তিগতভাবে আরেকটি কপি মাত্র; দল মিলে ঠিক করে সেটিকেই “আসল” ধরা হবে। এমন অন্য জায়গার repository-কে Git-এ বলে remote.

এই ধারার আদি নাম কয়েকটি: GNU arch, Monotone, darcs, আর বাণিজ্যিক BitKeeper. ২০০৫ সালে প্রায় একসাথে জন্ম নেয় দুটি: Git আর Mercurial (Matt Mackall, command-এর নাম hg). দুটোর জন্মের পেছনে একই ঘটনা — অংশ ৫-এ সেই গল্প।

৪ · Server বন্ধ হলে কী হয় — একটি commit-এর দুই রকম যাত্রা

পার্থক্যটা সবচেয়ে পরিষ্কার হয় খারাপ দিনে। ধরুন অফিসে লোডশেডিং চলছে, generator-এ শুধু কম্পিউটার চলছে, internet নেই। নিচে একই কাজ দুই ব্যবস্থায় পাশাপাশি দেখুন — ওপরের দুই সারি centralized (Subversion-এর মতো), নিচের দুই সারি distributed (Git-এর মতো):

একটি পুরো কর্মদিবসে কতটা পার্থক্য হয়? নিচের সিমুলেটরে সকাল ৯টা থেকে বিকেল ৫টা, ১০ মিনিটের ভাগে ভাগ করা। একটি “খারাপ দিন”: প্রতি ১০ মিনিটে ৮% সম্ভাবনায় server-এর বিভ্রাট শুরু হয়, চলে ১০ থেকে ৬০ মিনিট। তিনজন developer প্রত্যেকে প্রতি ৩০ মিনিটে একটি commit করতে চান (দিনে ১৬টি)। Centralized-এ সেই মুহূর্তে server না পেলে commit আটকে যায়; distributed-এ commit সবসময় নিজের কাছে হয়, আর server পাওয়া গেলেই না-পাঠানো সব commit push হয়:

// One workday (9:00-17:00) in 10-minute slots. The shared server has seeded outages.
// Each of 3 developers wants to commit every 30 minutes (16 times a day).
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 rnd = mulberry32(2005), SLOTS = 48, up = [];
for (let s = 0; s < SLOTS; ) {                       // outage starts with 8% chance per slot
  if (rnd() < 0.08) { const len = 1 + Math.floor(rnd() * 6); for (let k = 0; k < len && s < SLOTS; k++, s++) up.push(false); }
  else { up.push(true); s++; }
}
const fmt = (s) => String(9 + Math.floor(s / 6)).padStart(2, "0") + ":" + (s % 6) + "0";
const down = up.map((u, s) => (u ? "" : fmt(s))).filter(Boolean);
console.log("server down in", down.length, "slots:", down.join(" "));
for (let dev = 0; dev < 3; dev++) {
  let central = 0, blocked = 0, local = 0, pushed = 0, waiting = 0;
  for (let s = dev; s < SLOTS; s += 3) {             // dev's commit moments (offset 0/10/20 min)
    local++; waiting++;                                // distributed: commit always works offline
    if (up[s]) { central++; pushed += waiting; waiting = 0; }   // push everything not yet shared
    else blocked++;                                    // centralized: no server, no commit
  }
  console.log("dev" + (dev + 1), "| centralized: committed", central, "blocked", blocked,
    "| distributed: local", local, "pushed by 17:00", pushed, "waiting", waiting);
}

server down in 18 slots: 09:30 09:40 09:50 10:00 10:20 10:30 10:40 10:50 12:30 12:40 13:40 13:50 14:00 14:10 14:30 14:40 14:50 15:00
dev1 | centralized: committed 9 blocked 7 | distributed: local 16 pushed by 17:00 16 waiting 0
dev2 | centralized: committed 10 blocked 6 | distributed: local 16 pushed by 17:00 16 waiting 0
dev3 | centralized: committed 11 blocked 5 | distributed: local 16 pushed by 17:00 16 waiting 0

৫ · Git-এর জন্ম — BitKeeper, Linus Torvalds আর ২০০৫

নামটি নিয়ে একটি রসিকতা প্রচলিত: ব্রিটিশ অপভাষায় “git” মানে মোটামুটি “একগুঁয়ে, অপ্রিয় লোক”, আর Torvalds বলেছেন তিনি নিজের নামেই project-এর নাম রাখেন — প্রথমে Linux, তারপর Git.

নকশার পাঁচটি লক্ষ্য

Scott Chacon ও Ben Straub-এর বিনামূল্যের বই Pro Git-এ Git-এর মূল লক্ষ্যগুলো এভাবে তালিকা করা আছে। প্রতিটি লক্ষ্য BitKeeper-এর অভিজ্ঞতা আর kernel-এর বিশাল আকার থেকে এসেছে:

আরেকটি লক্ষ্য Torvalds বারবার জোর দিয়ে বলেছেন: data-র অখণ্ডতা. প্রতিটি ফাইল আর commit-এর নাম তার বিষয়বস্তুর cryptographic hash (ঐতিহ্যগতভাবে SHA-1), তাই disk-এর একটি bit বদলে গেলেও Git টের পায়; নীরবে ইতিহাস বিকৃত করা কঠিন। SHA-1-এর দুর্বলতা জানা যাওয়ার পর Git-এ SHA-256 ভিত্তিক repository-র বিকল্প যোগ হয়েছে (Git ২.২৯ থেকে, শুরুতে পরীক্ষামূলক হিসেবে); লেখার সময়ে বেশিরভাগ repository এখনো SHA-1 ব্যবহার করে। নিরাপত্তার দিকটি পর্ব ৫৭-এ।

৬ · Snapshot বনাম delta — Git কীভাবে মনে রাখে

RCS আর Subversion-এর মতো অনেক পুরোনো tool প্রতিটি ফাইলের ইতিহাসকে ভাবে পরিবর্তনের তালিকা হিসেবে: “version ১, তারপর এই লাইনগুলো যোগ, তারপর এগুলো বাদ…”। Git ভাবে ভিন্নভাবে: প্রতিটি commit হলো পুরো project-এর একটি snapshot — সেই মুহূর্তে সব ফাইল দেখতে কেমন ছিল। “তাহলে তো প্রতিবার সব ফাইলের কপি — জায়গা ফুরিয়ে যাবে না?” না, কারণ যে ফাইল বদলায়নি, Git সেটি নতুন করে রাখে না; আগের কপির দিকে নির্দেশ করে।

এই শেষ কৌশলটির নাম content-addressed storage: প্রতিটি ফাইলের বিষয়বস্তু থেকে একটি hash বানানো হয়, আর সেই hash-ই তার নাম। একই বিষয়বস্তু → একই hash → একবারই রাখা। নিচের প্রোগ্রাম একটি ছোট project-এর ৫টি version দুইভাবে রাখে: প্রতিবার পুরো ফোল্ডার কপি, আর hash-ভিত্তিক একটি snapshot store. Git ব্যবহার করে SHA-1 বা SHA-256; এখানে তার বদলে একটি সরল ৩২-bit hash (FNV-1a) — শেখার জন্য যথেষ্ট, নিরাপত্তার জন্য নয়। * চিহ্ন মানে নতুন object জমা হলো:

// Five versions of a tiny project: "copy the whole folder" vs a snapshot store.
// FNV-1a 32-bit stands in for Git's SHA-1/SHA-256 (a teaching hash, not secure).
function fnv1a(s) {
  let h = 0x811c9dc5;
  for (let i = 0; i < s.length; i++) { h ^= s.charCodeAt(i); h = Math.imul(h, 0x01000193) >>> 0; }
  return h.toString(16).padStart(8, "0");
}
const logo = "LOGO".repeat(500);                      // a 2000-byte file that never changes
const versions = [
  { "logo.txt": logo, "README": "Shop ledger v1", "hisab.txt": "chal 1200\n" },
  { "logo.txt": logo, "README": "Shop ledger v1", "hisab.txt": "chal 1200\ndal 300\n" },
  { "logo.txt": logo, "README": "Shop ledger v2", "hisab.txt": "chal 1200\ndal 300\n" },
  { "logo.txt": logo, "README": "Shop ledger v2", "hisab.txt": "chal 1250\ndal 300\n" },
  { "logo.txt": logo, "README": "Shop ledger v1", "hisab.txt": "chal 1200\n" } // back to v1
];
const objects = new Map();          // hash -> content (each distinct content stored once)
let copyBytes = 0;
versions.forEach((files, i) => {
  const snapshot = [];
  for (const [name, text] of Object.entries(files)) {
    copyBytes += text.length;                          // full-copy method: every file, every time
    const id = fnv1a(text);
    const isNew = !objects.has(id);
    if (isNew) objects.set(id, text);
    snapshot.push(name + ":" + id + (isNew ? "*" : ""));
  }
  console.log("v" + (i + 1), snapshot.join("  "));
});
let storeBytes = 0;
for (const text of objects.values()) storeBytes += text.length;
console.log("full copies :", copyBytes, "bytes");
console.log("snapshot store:", storeBytes, "bytes in", objects.size, "objects");
console.log("saved:", (100 * (1 - storeBytes / copyBytes)).toFixed(1) + "%");

v1 logo.txt:181291f5*  README:3b9e780b*  hisab.txt:9809e08c*
v2 logo.txt:181291f5  README:3b9e780b  hisab.txt:ab6e17ba*
v3 logo.txt:181291f5  README:3c9e799e*  hisab.txt:ab6e17ba
v4 logo.txt:181291f5  README:3c9e799e  hisab.txt:f30e5bb9*
v5 logo.txt:181291f5  README:3b9e780b  hisab.txt:9809e08c
full copies : 10144 bytes
snapshot store: 2074 bytes in 6 objects
saved: 79.6%

এটি ধারণা, পূর্ণ ছবি নয়। আসল Git প্রতিটি object zlib দিয়ে সংকুচিত করে, আর মাঝে মাঝে অনেক object একটি packfile-এ ভরে delta দিয়েও জায়গা বাঁচায়। অর্থাৎ Git-এর মডেল snapshot, কিন্তু disk-এ সংরক্ষণ আরও চতুর। ফোল্ডারের জন্য tree object আর commit-এর জন্য commit object কীভাবে এই hash-গুলো জুড়ে রাখে — পর্ব ৫২-এ (Git-এর ভেতরে) নিজের হাতে খুলে দেখবেন। Hash-এর সাধারণ ধারণা পড়তে চাইলে DSA কোর্সের Hash table পর্ব দেখুন।

৭ · Git আর GitHub এক নয় — tool, platform আর client

নতুনদের সবচেয়ে প্রচলিত বিভ্রান্তি: “আমি GitHub শিখছি” বলতে অনেকে আসলে Git বোঝান। পার্থক্যটা রান্না আর রেস্তোরাঁর মতো: Git হলো রান্নার পদ্ধতি আর চুলা, যা আপনার নিজের রান্নাঘরেই চলে; GitHub হলো একটি রেস্তোরাঁ-ভবন, যেখানে রান্না সবার সামনে রাখা যায়, অন্যরা মতামত দেন, অর্ডার নেওয়া হয়।

একটি repository একসাথে কয়েকটি platform-এ রাখা যায়, বা কোনো platform ছাড়াই — একটি অফিসের server-এ বা USB drive-এ একটি সাধারণ Git repository দিয়েও দল চলতে পারে। GitHub ২০১৮ সালে Microsoft কিনে নেয়; Bitbucket শুরুতে Mercurial-ও সমর্থন করত, ২০২০ সালে সেই সমর্থন বন্ধ করে। Platform-এর বৈশিষ্ট্য আর দাম বদলাতে পারে; বিস্তারিত তাদের নিজের documentation-এ দেখুন। Platform-এর কাজের ধারা — fork, pull request, review — আসবে পর্ব ১৬-এ, আর remote-এর সাথে clone, fetch, pull, push পর্ব ১৪-এ।

Command line, GUI আর IDE

Git ব্যবহারের তিনটি প্রধান পথ:

• Command line: terminal-এ git লিখে। এটিই Git-এর পূর্ণ রূপ; সব command, সব option এখানে আছে, আর ইন্টারনেটের প্রায় সব সাহায্য এই ভাষায় লেখা। Terminal নতুন হলে Operating Systems কোর্সের Linux terminal পর্বটি কাজে আসবে।
• GUI client: GitHub Desktop, Sourcetree, GitKraken, Fork-এর মতো প্রোগ্রাম, আর Git-এর সাথেই আসা gitk ও git gui. Commit-এর গাছ চোখে দেখা আর ফাইলের কিছু অংশ বেছে commit করা এখানে সহজ। কিছু client বিনামূল্যের, কিছু শর্তসাপেক্ষ; লাইসেন্স দেখে নিন।
• IDE-র ভেতরে: VS Code, IntelliJ IDEA, Android Studio, Visual Studio — সবগুলোতে Git-এর প্যানেল আছে: কোন ফাইল বদলেছে, পাশাপাশি diff, এক ক্লিকে commit.

৮ · Git install আর প্রথমবারের setup

নিচের command-গুলো উদাহরণ; installer আর package-এর নাম সময়ের সাথে বদলাতে পারে, তাই সন্দেহ হলে git-scm.com-এর download পাতা দেখুন। আপনার OS বেছে নিন:

winget install --id Git.Git -e --source winget

xcode-select --install
brew install git

sudo apt install git
sudo dnf install git

Install হলো কি না দেখতে একটি নতুন terminal খুলে version জিজ্ঞেস করুন। নিচের আউটপুট এই লেখার মেশিনে (Windows, Git ২.৫৩) চালিয়ে পাওয়া; Linux বা macOS-এ শেষের .windows.2 অংশ থাকবে না, আর নম্বরটি আপনার install অনুযায়ী আলাদা হবে:

$ git --version
git version 2.53.0.windows.2

Setup না করলে কী হয়

নতুন install-এ প্রথম commit করতে গেলেই Git থেমে যায়, কারণ প্রতিটি commit-এ লেখকের নাম আর email লিখতে হয়। নিচে একটি সম্পূর্ণ খালি configuration দিয়ে চালানো আসল আউটপুট (মেশিনের নামটি … দিয়ে ঢাকা):

$ git commit -m "Add the shop ledger"
Author identity unknown

*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got '…')

Git নিজেই সমাধান বলে দিচ্ছে। আর init.defaultBranch ঠিক না করে নতুন repository বানালে Git ২.৫৩ একটি লম্বা পরামর্শ দেখায় (মাঝের কিছু লাইন বাদ):

$ git init hisab
hint: Using 'master' as the name for the initial branch. This default branch name
hint: will change to "main" in Git 3.0. To configure the initial branch name
hint: to use in all of your new repositories, which will suppress this warning,
hint: call:
hint:
hint: 	git config --global init.defaultBranch <name>
…
Initialized empty Git repository in …/hisab/.git/

অর্থাৎ পুরোনো ডিফল্ট নাম master, আর Git-এর নিজের বার্তা অনুযায়ী ভবিষ্যতের Git ৩.০-তে ডিফল্ট হবে main. GitHub, GitLab-সহ বড় platform-গুলো নতুন repository-তে কয়েক বছর ধরেই main ব্যবহার করে, তাই এখনই main ঠিক করে নেওয়া সুবিধাজনক। এবার পুরো setup ধাপে ধাপে:

এই transcript-টি লেখার সময় আসল configuration না ছুঁয়ে একটি আলাদা পরীক্ষার ফাইলে চালানো হয়েছে (GIT_CONFIG_GLOBAL নামের environment variable দিয়ে Git-কে অন্য global ফাইল দেখানো যায়)। আপনি নিজের মেশিনে সাধারণভাবেই চালাবেন, নাম আর email নিজের দেবেন:

$ git config --global user.name "Rahim"
$ git config --global user.email "rahim@example.com"
$ git config --global init.defaultBranch main
$ git config --global core.editor "code --wait"
$ git config --global core.autocrlf true
$ git config --global --list
user.name=Rahim
user.email=rahim@example.com
init.defaultbranch=main
core.editor=code --wait
core.autocrlf=true
$ git config user.name
Rahim

Set করার command সফল হলে কিছুই ছাপে না; শেষ লাইনে একটি একক সেটিং পড়া হলো। এখন আগের ব্যর্থ commit আবার চেষ্টা করলে (লেখক আর সময় নির্দিষ্ট রাখা হয়েছে, তাই hash a8f8516; আপনার মেশিনে সময় আলাদা বলে hash-ও আলাদা হবে):

$ git init hisab
Initialized empty Git repository in …/hisab/.git/
$ cd hisab
$ printf 'chal 1200\ndal 300\n' > hisab.txt
$ git add hisab.txt
$ git commit -m "Add the shop ledger"
[main (root-commit) a8f8516] Add the shop ledger
 1 file changed, 2 insertions(+)
 create mode 100644 hisab.txt

এবার কোনো hint নেই, branch-এর নাম main, আর commit হয়েছে। root-commit মানে এটি এই repository-র প্রথম commit, যার কোনো পূর্বসূরি নেই। init, add, commit আর এর পেছনের তিনটি এলাকা (working tree, staging area, repository) — পুরোটা পর্ব ০৮-এ। Config-এর তিনটি স্তর (system, global, local), কোনটি কাকে ছাপিয়ে যায়, আর repository-ভিত্তিক সেটিং — পর্ব ১০-এ।

৯ · সাহায্য, প্রথম শব্দগুলো আর সামনের পথ

Git-এর সবচেয়ে নির্ভরযোগ্য সাহায্য তার নিজের ভেতরেই। git help <command> (বা git <command> --help) সেই command-এর পূর্ণ manual খোলে; Windows-এ সাধারণত browser-এ। শুধু option-গুলোর ছোট তালিকা চাইলে git <command> -h. আর সব command-এর তালিকা:

$ git help -a | head -14
See 'git help <command>' to read about a specific subcommand

Main Porcelain Commands
   add                     Add file contents to the index
   am                      Apply a series of patches from a mailbox
   archive                 Create an archive of files from a named tree
   backfill                Download missing objects in a partial clone
   bisect                  Use binary search to find the commit that introduced a bug
   branch                  List, create, or delete branches
   bundle                  Move objects and refs by archive
   checkout                Switch branches or restore working tree files
   cherry-pick             Apply the changes introduced by some existing commits
   citool                  Graphical alternative to git-commit
   clean                   Remove untracked files from the working tree

“Porcelain” শব্দটি খেয়াল করুন। Git-এর ভাষায় মানুষের প্রতিদিনের ব্যবহারের command হলো porcelain (বাথরুমের চকচকে বাইরের অংশ), আর ভেতরের নিচু-স্তরের command হলো plumbing (দেয়ালের ভেতরের পাইপ)। তালিকার নিচে plumbing-ও আছে; পর্ব ৫২-এ সেগুলো ব্যবহার করবেন। git help -g দিলে আসে Git-এর ধারণা-নির্দেশিকার তালিকা (যেমন everyday, glossary). AI বা কোনো blog যে flag বলছে, তা সত্যিই আছে কি না যাচাইয়ের সবচেয়ে দ্রুত পথও এই manual.

চারটি শব্দ, যা সামনে প্রতিদিন লাগবে

Git-এর তিনটি মডিউল — রোডম্যাপ

এই কোর্সে Git আসবে তিন ধাপে, প্রতিটি আগেরটির ওপর:

• মডিউল ২ — Git-এর মৌলিক (পর্ব ০৭–১৩): এই পর্বের পর প্রথম repository (০৮), history আর diff (০৯), .gitignore আর config (১০), ভুল শোধরানো (১১), branch (১২) আর merge ও conflict (১৩)। একা নিজের কম্পিউটারে আত্মবিশ্বাসের সাথে Git.
• মডিউল ৩ — Git দিয়ে দলগত কাজ (পর্ব ১৪–১৯): remote আর clone-push-pull, rebase, pull request আর fork, branching strategy (Git Flow, trunk-based), ভালো commit বার্তা, tag আর release, আর বড় repository.
• মডিউল ৯ — উন্নত Git আর automation (পর্ব ৫২–৫৮): Git-এর ভেতরের object, reflog দিয়ে উদ্ধার, merge-এর ভেতরের কৌশল, bisect আর blame, stash ও worktree-র মতো হাতিয়ার, নিরাপত্তা, আর continuous integration.

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

AI assistant এখন Git-এর প্রশ্নের প্রথম ঠিকানা হয়ে উঠছে, আর বেশিরভাগ সময় কাজের উত্তরই দেয়। কিন্তু Git এমন একটি tool, যেখানে একটি ভুল command কয়েক দিনের কাজ মুছে দিতে পারে। এই পর্বের বিষয়ে AI-এর পরিচিত ভুলগুলো:

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

• প্রতিটি command-এর flag আর config key git help বা -h-এ নিজে খুঁজে পেয়েছি
• যে command ফাইল মুছতে বা ইতিহাস বদলাতে পারে, তা আগে একটি পরীক্ষার clone-এ চালিয়ে দেখেছি
• চালানোর আগে আর পরে git status দেখে বুঝেছি কী বদলাল
• উত্তরটি আমার Git version আর OS-এর জন্য খাটে কি না মিলিয়েছি
• Prompt-এ কোনো token, password, গোপন URL বা কোম্পানির কোড দিইনি
• ইতিহাস বা “standard” নিয়ে AI-এর দাবি একটি নির্ভরযোগ্য উৎসে যাচাই করেছি