Git ইন্টারভিউ — ধারণা, পরিস্থিতিভিত্তিক সমস্যা আর command-এর অনুশীলন

উত্তর: Commit হলো পুরো project-এর একটি snapshot — সেই মুহূর্তে সব file কেমন ছিল — সাথে metadata: লেখক, committer, সময়, বার্তা আর parent commit-এর ID (প্রথম commit-এ কোনো parent নেই, merge commit-এ দুই বা বেশি). যুক্তির দিক থেকে এটি diff নয়; git show যে diff দেখায়, Git তা parent-এর snapshot-এর সাথে তুলনা করে তখনই বানায়। Commit-এর ID তার সব বিষয়বস্তুর hash, তাই কোনো কিছু বদলালে ID-ও বদলায় — commit কখনো “সম্পাদনা” হয় না, নতুন commit তৈরি হয়।

ফলো-আপ: (ক) “প্রতিটি snapshot কি পুরো file কপি করে?” — না; একই বিষয়বস্তুর file একবারই সংরক্ষিত হয় (অংশ ৪-এর প্র ১৯), আর packfile delta দিয়ে জায়গা বাঁচায়। (খ) “ভালো commit কেমন?” — একটি যুক্তিসংগত বদল, test পাস, বার্তায় “কেন” (পর্ব ১৮)।

উত্তর: Working tree (আপনার folder-এর আসল file), index বা staging area (পরের commit-এর খসড়া) আর repository (.git-এর ভেতরে commit-এর ইতিহাস)। git add working tree থেকে index-এ তোলে; git commit index-এর অবস্থাকে নতুন commit বানায় আর branch-কে সেখানে সরায়। পরীক্ষার খাতার খসড়া আর ফেয়ার কপির মতো: খসড়ায় যত খুশি কাটাকুটি, ফেয়ার কপিতে শুধু যা বেছে তুলেছেন।

git status --short-এর দুই কলাম এই এলাকাগুলোরই তুলনা: প্রথম কলাম index বনাম HEAD, দ্বিতীয়টি working tree বনাম index. M মানে staged, M মানে শুধু folder-এ, MM মানে দুটোই।

ফলো-আপ: “Index কেন দরকার, সরাসরি commit কেন নয়?” — একই file-এর কিছু অংশ বেছে commit (git add -p), merge conflict-এর সময় একাধিক রূপ রাখা, আর ছোট, যুক্তিসংগত commit বানানো। Staged আর unstaged diff আলাদা দেখতে git diff --staged আর git diff.

উত্তর: Branch হলো একটি commit-এর দিকে নির্দেশ করা নাম — একটি ছোট file (.git/refs/heads/main), যাতে শুধু ৪০ অক্ষরের একটি commit ID লেখা। নতুন branch মানে নতুন file, কোনো কোড কপি হয় না; তাই মুহূর্তে তৈরি হয়। নতুন commit করলে বর্তমান branch-এর pointer নিজে থেকে নতুন commit-এ সরে যায়। পুরোনো centralized system-এ (যেমন Subversion) branch মানে server-এ folder-এর একটি “সস্তা কপি”; বানানো দ্রুত হলেও প্রতিটি কাজে server লাগত, আর merge-এর হিসাব রাখা কঠিন ছিল — Git-এ সবই local আর হালকা (পর্ব ৭, পর্ব ১২)।

ফলো-আপ: (ক) “Branch মুছলে commit মুছে যায়?” — না, শুধু নামটি যায়; অন্য কোনো branch থেকে পৌঁছানো না গেলে commit কিছুদিন reflog-এ থাকে, পরে garbage collection মুছতে পারে। (খ) “Tag আর branch-এর পার্থক্য?” — tag একটি নির্দিষ্ট commit-এ স্থির থাকে, নতুন commit-এ সরে না।

উত্তর: HEAD মানে “আপনি এখন কোথায়”। সাধারণত HEAD একটি branch-এর নাম ধরে রাখে (.git/HEAD-এ লেখা ref: refs/heads/main), আর সেই branch একটি commit ধরে রাখে। কোনো tag, পুরোনো commit বা remote branch সরাসরি checkout করলে (git switch --detach v1.0) HEAD সরাসরি একটি commit-এ বসে — এটাই detached HEAD.

দেখা বা পরীক্ষা করার জন্য এটি একেবারে নিরাপদ। ঝুঁকি একটাই: এই অবস্থায় নতুন commit করে অন্য branch-এ চলে গেলে সেই commit-গুলোর কোনো নাম থাকে না — Git সতর্ক করে, আর reflog থেকে উদ্ধার করা যায় (পরিস্থিতি ৬)। সমাধান: কাজ রাখার ইচ্ছা হলে আগেই git switch -c <নাম>.

ফলো-আপ: “HEAD~2 আর HEAD^2-এর পার্থক্য?” — ~2 মানে প্রথম parent ধরে দুই ধাপ পেছনে; ^2 মানে merge commit-এর দ্বিতীয় parent.

উত্তর: বর্তমান branch যদি অন্য branch-এর সরাসরি পূর্বপুরুষ হয় — অর্থাৎ বর্তমান branch আলাদা হওয়ার পরে নিজে কোনো commit পায়নি — তাহলে Git শুধু pointer-টি সামনে সরিয়ে দেয়; নতুন commit হয় না। এটাই fast-forward. দুই দিকেই নতুন commit থাকলে Git তিনটি snapshot তুলনা করে — দুই branch-এর মাথা আর তাদের merge base (সবচেয়ে কাছের সাধারণ পূর্বপুরুষ) — আর দুই parent-ওয়ালা একটি merge commit বানায়। একই লাইন দুই দিকে আলাদাভাবে বদলালে conflict.

ফলো-আপ: (ক) “--no-ff কেন?” — fast-forward সম্ভব হলেও merge commit রেখে দেখানো যে এই commit-গুলো একটি feature হিসেবে এসেছিল। (খ) “--ff-only?” — fast-forward না হলে থেমে যায়, অজান্তে merge commit হয় না। অংশ ৩-এর প্রথম simulator-এ (প্র ১০-এর নিচে) নিজে অনুমান করে যাচাই করুন।

উত্তর: Reset বর্তমান branch-কে অন্য commit-এ সরায় — ইতিহাস বদলায়। --soft শুধু branch সরায়; index আর working tree আগের মতো, তাই বাদ পড়া commit-গুলোর বদল staged অবস্থায় থাকে। --mixed (ডিফল্ট) branch আর index দুটোই সরায়; বদলগুলো working tree-তে unstaged থাকে। --hard তিনটিকেই সরায় — commit না করা বদল চিরতরে যায়। Revert ইতিহাস বদলায় না; একটি নতুন commit বানায়, যা পুরোনো commit-এর উল্টো বদল আনে।

নিয়ম: push হয়নি এমন নিজের commit গোছাতে reset; push হয়ে গেলে, বিশেষত shared branch-এ, revert (পরিস্থিতি ৮)।

ফলো-আপ: (ক) “reset --hard-এ হারানো commit ফেরে?” — হ্যাঁ, reflog থেকে (পরিস্থিতি ২); কিন্তু কখনো commit বা add না করা লেখা ফেরে না। (খ) “--keep?” — reset --keep --hard-এর মতো সরায়, কিন্তু local বদল হারানোর ঝুঁকি থাকলে থেমে যায় (অংশ ৮)। (গ) “Merge commit revert?” — git revert -m 1 <merge>; -m ছাড়া Git ২.৫৩ বলে “is a merge but no -m option was given”.

উত্তর: Fetch remote থেকে নতুন commit নামায় আর শুধু remote-tracking branch (origin/main) আপডেট করে — আপনার branch বা file ছোঁয় না, তাই সবসময় নিরাপদ। Pull = fetch + আপনার branch-এ সেটি মেলানো (merge, বা config থাকলে rebase). দুই দিকে আলাদা commit থাকলে (diverged) আর কোনো পছন্দ ঠিক করা না থাকলে নতুন Git সরাসরি থেমে যায়:

$ git pull
hint: You have divergent branches and need to specify how to reconcile them.
hint: You can do so by running one of the following commands sometime before
hint: your next pull:
hint:
hint:   git config pull.rebase false  # merge
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only
hint:
hint: You can replace "git config" with "git config --global" to set a default
hint: preference for all repositories. You can also pass --rebase, --no-rebase,
hint: or --ff-only on the command line to override the configured default per
hint: invocation.
fatal: Need to specify how to reconcile divergent branches.

অর্থাৎ Git চায় আপনি নিজে ঠিক করুন: merge, rebase, না শুধু fast-forward. অনেক দল pull.ff only রাখে, যাতে অজান্তে merge commit না হয়।

ফলো-আপ: “নিরাপদ অভ্যাস?” — আগে git fetch, তারপর git log --oneline HEAD..origin/main দেখে সিদ্ধান্ত।

উত্তর: না। main আপনার local branch; origin/main হলো “শেষবার fetch বা push-এর সময় server-এর main কোথায় ছিল” তার স্থানীয় স্মৃতি — আপনি সরাসরি এতে commit করেন না। এটি নিজে থেকে আপডেট হয় না; fetch না করলে পুরোনো খবর দেখায়। Ahead/behind হলো দুটি range-এর মাপ: ahead = origin/main..main (আপনার কাছে আছে, server-এ নেই), behind = main..origin/main. একসাথে: git rev-list --left-right --count origin/main...main.

ফলো-আপ: “Upstream কী?” — local branch যে remote branch-কে অনুসরণ করে (git push -u বা git branch -u দিয়ে ঠিক হয়); @{u} লিখে তাকে বোঝানো যায়।

উত্তর: Conventional Commits ১.০.০ হলো commit বার্তার একটি প্রচলিত ধাঁচ: type(scope): বর্ণনা, যেমন feat(cart): add coupon, fix(pay): read key from environment; ভাঙনধরা বদলে feat!: বা footer-এ BREAKING CHANGE:. SemVer ২.০.০-এ version MAJOR.MINOR.PATCH: ভাঙনধরা API বদলে MAJOR, পেছনের দিকে সামঞ্জস্যপূর্ণ নতুন সুবিধায় MINOR, শুধু bug fix-এ PATCH. সংযোগ: tool বার্তা পড়ে পরের version আর changelog স্বয়ংক্রিয়ভাবে বানাতে পারে — শেষ release থেকে শুধু fix থাকলে PATCH, অন্তত একটি feat থাকলে MINOR, ভাঙন থাকলে MAJOR (পর্ব ১৮)।

ফলো-আপ: (ক) “1.4.0 থেকে শুধু একটি fix গেলে?” — 1.4.1 (পরিস্থিতি ১৫-এ ঠিক তাই)। (খ) “0.x?” — SemVer-এ শুরুর উন্নয়ন পর্যায়, যেকোনো সময় যেকোনো কিছু বদলাতে পারে। (গ) “সব project কি SemVer মানে?” — না; অনেকে calendar versioning (যেমন 2026.01) ব্যবহার করে — দুই ধারার উদ্দেশ্য আলাদা।

উত্তর: দুটিই দুই branch-এর কাজ মেলায়, কিন্তু ইতিহাস আলাদাভাবে রাখে। Merge দুই ইতিহাস যেমন আছে রেখে একটি merge commit যোগ করে — কী আসলে ঘটেছিল, তার সৎ ছবি। Rebase আপনার branch-এর commit-গুলো (upstream..HEAD) একে একে নতুন ভিত্তির ওপর আবার চালায় (replay); বদল একই, কিন্তু parent আলাদা বলে প্রতিটি commit-এর ID নতুন — ফলে ইতিহাস এক সরলরেখা।

সোনালি নিয়ম (golden rule): যে commit অন্যরা ইতিমধ্যে নিয়েছেন বা যার ওপর কাজ শুরু করেছেন, তা rebase করবেন না — তাঁদের কাছে পুরোনো ID থেকে যায়, আর পরের merge-এ একই বদল দুবার আসে। নিজের, এখনো একা ব্যবহার করা feature branch-এ rebase নিরাপদ; push করা থাকলে তারপর --force-with-lease লাগে (পরিস্থিতি ১৩)।

ফলো-আপ: (ক) “Rebase-এর conflict-এ ‘ours’ কে?” — উল্টো! Rebase-এর সময় HEAD হলো নতুন ভিত্তি (যেমন main), আর replay হওয়া commit-টি “theirs” (পরিস্থিতি ৩-এর marker দেখুন)। (খ) “Squash merge?” — platform-এর বিকল্প, পুরো branch একটি commit হয়ে main-এ যায়; ইতিহাস পরিষ্কার, কিন্তু branch-এর ভেতরের commit হারায়।

উত্তর: সাধারণ push শুধু fast-forward গ্রহণ করে — server-এর branch আপনার নতুন commit-এর পূর্বপুরুষ হতে হবে। --force এই শর্ত বাদ দেয়: server-এ যা-ই থাকুক, মুছে আপনার ইতিহাস বসায়। --force-with-lease একটি শর্ত যোগ করে: “server-এর branch এখনো সেখানেই থাকলে তবেই, যেখানে আমার origin/main বলছে”। মাঝে কেউ push করে থাকলে প্রত্যাখ্যান — “stale info”. পরিস্থিতি ১২-এর Karim-এর আসল আউটপুট:

$ git push --force-with-lease origin main
To ../s10srv.git
 ! [rejected]        main -> main (stale info)
error: failed to push some refs to '../s10srv.git'

ফাঁক: Karim যদি আগে git fetch করতেন (কিন্তু Rahim-এর commit দেখে মেলাতেন না), তাহলে তাঁর origin/main আপডেট হয়ে যেত, আর lease পাস করত — Rahim-এর কাজ মুছত। --force-if-includes (Git ২.৩০ থেকে) এটাও ধরে: remote-tracking ref-এর নতুন অবস্থা আপনার local branch-এর ইতিহাসে আছে কি না দেখে। একই অবস্থায় Git ২.৫৩:

$ git push --force-with-lease --force-if-includes origin main
To ../j4srv.git
 ! [rejected]        main -> main (remote ref updated since checkout)
error: failed to push some refs to '../j4srv.git'
hint: Updates were rejected because the tip of the remote-tracking branch has
hint: been updated since the last checkout. If you want to integrate the
hint: remote changes, use 'git pull' before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

ফলো-আপ: “তাহলে শুধু flag-ই যথেষ্ট?” — না; আসল সুরক্ষা server-এ: main-এ force push নিষেধ (protected branch, platform-ভেদে নাম আলাদা)।

উত্তর: git log commit-এর parent ধরে ইতিহাস দেখায় — “এই commit কোথা থেকে এল”। Reflog প্রতিটি ref-এর (HEAD, প্রতিটি branch) নিজের খাতা — “এই নামটি কবে কোন commit-এ ছিল”: commit, checkout, reset, rebase, merge সব লেখা থাকে। তাই reset বা rebase-এ যে commit log থেকে “হারিয়ে” যায়, সেটি reflog-এ HEAD@{1}-এর মতো নামে খুঁজে পাওয়া যায় (পরিস্থিতি ২)।

ডিফল্টে reflog entry ৯০ দিন রাখা হয়, আর যে entry-র commit কোনো ref থেকে পৌঁছানো যায় না তার জন্য ৩০ দিন (gc.reflogExpire, gc.reflogExpireUnreachable); তারপর garbage collection object মুছতে পারে (পর্ব ৫৩)।

ফলো-আপ: (ক) “Reflog কি push হয়?” — না, সম্পূর্ণ local; নতুন clone-এ থাকে না। তাই সহকর্মীর হারানো কাজ তাঁর নিজের reflog-এ খুঁজতে হয়। (খ) “Reflog-ও না থাকলে?” — git fsck --unreachable বা --lost-found (পরিস্থিতি ৭)।

উত্তর: Stash অর্ধেক কাজ (working tree আর index-এর বদল) তুলে রেখে folder পরিষ্কার করে — branch বদলে জরুরি কাজ সেরে ফিরে আসার জন্য। এটি একটি stack: নতুনটি stash@{0}. ভেতরে প্রতিটি entry সাধারণ commit (working tree-র W, index-এর I, আর -u দিলে untracked-এর U), যা refs/stash-এ ঝোলে। apply বদল বসায় কিন্তু entry রাখে; pop বসায় আর সফল হলে মোছে — conflict হলে মোছে না। ডিফল্টে untracked file নেয় না, তাই git stash push -u -m "…".

কখন ভুল: কয়েক দিনের কাজ রাখতে — stash push হয় না, নম্বর বদলায়, নাম থাকে না। তখন WIP branch-এ commit করে push, পরে গুছিয়ে নিন; আর একসাথে দুটি কাজ চললে worktree (প্র ১৬)।

ফলো-আপ: “ভুল করে drop করলে?” — পরিস্থিতি ৭।

উত্তর: একটি commit তার parent-এর তুলনায় যা বদলেছিল, সেই বদল বর্তমান branch-এর মাথায় নতুন commit হিসেবে বসায়। বার্তা আর লেখক একই থাকে, কিন্তু parent আলাদা, তাই ID আলাদা। সবচেয়ে প্রচলিত ব্যবহার backport: main-এর একটি fix পুরোনো release branch-এ নেওয়া, -x দিয়ে উৎস লিখে (পরিস্থিতি ১৫)।

এড়াবেন: পুরো branch-এর কাজ আনতে অনেকগুলো cherry-pick — merge-ই ঠিক পথ; একই বদল দুই ID-তে থাকলে পরে merge-এ বিভ্রান্তি আর conflict. আর কোনো fix যদি আগের কোনো refactor-এর ওপর নির্ভর করে, শুধু fix-টি pick করলে ভুল আচরণ হতে পারে — release branch-এ test চালাতেই হবে।

ফলো-আপ: (ক) “git cherry-pick A..B-তে A আসে?” — না, A বাদ; A-সহ চাইলে A^..B (Git ২.৫৩-এ যাচাই করা)। (খ) “Merge commit pick?” — -m 1 দিয়ে কোন parent-এর সাপেক্ষে diff, তা বলতে হয়।

উত্তর: Bisect হলো ইতিহাসের ওপর binary search. আপনি একটি “bad” (bug আছে) আর একটি “good” (bug নেই) commit বলেন; Git মাঝখানের একটি commit checkout করে, আপনি test করে good বা bad বলেন, আর প্রতি ধাপে সন্দেহের পরিসর মোটামুটি অর্ধেক হয়। N টি সন্দেহজনক commit-এ প্রায় ⌈log₂ N⌉ ধাপ — ১০০০-এ প্রায় ১০টি (২¹⁰ = ১০২৪)। Merge-ভরা ইতিহাসে সংখ্যা একটু বেশি হতে পারে।

git bisect run <script> পুরো কাজটি স্বয়ংক্রিয় করে: script-এর exit code ০ মানে good, ১২৫ মানে “এটি পরীক্ষা করা যায় না, বাদ দিন”, ১ থেকে ১২৭-এর বাকিগুলো bad (পরিস্থিতি ১০)।

ফলো-আপ: (ক) “Test flaky হলে?” — bisect ভুল commit দেখাবে; আগে test নির্ভরযোগ্য করুন বা কয়েকবার চালিয়ে সিদ্ধান্ত। (খ) “কোন লাইন কে বদলেছেন?” — git blame -L; “কোন commit কোনো লেখা যোগ বা মুছেছে?” — git log -S.

উত্তর: এক repository, একাধিক working folder: git worktree add -b hotfix/vat ../hotfix main একটি নতুন folder খোলে নতুন branch-এ, কিন্তু object আর ref ভাগ করে (Git ২.৫, ২০১৫ থেকে)। মাঝপথের feature না ছুঁয়ে hotfix বা review করা যায়। Git ২.৫৩-এ আসল আউটপুট:

$ git worktree add -b hotfix/vat ../hotfix main
Preparing worktree (new branch 'hotfix/vat')
HEAD is now at 9082124 Merge branch 'feature'

তুলনা: stash হালকা কিন্তু এক সময়ে একটিই কাজ খোলা আর ফেরাতে conflict-এর ঝুঁকি; দ্বিতীয় clone পুরো আলাদা, কিন্তু ইতিহাস দুবার নামে আর commit আনতে push-fetch লাগে; worktree মাঝামাঝি — সেকেন্ডে তৈরি, এক ইতিহাস।

ফলো-আপ: “একই branch দুই worktree-তে?” — ডিফল্টে Git দেয় না (বলে 'main' is already used by worktree); একটি branch একসাথে একটি worktree-তেই checkout থাকে। কাজ শেষে git worktree remove ../hotfix.

উত্তর: Hook হলো Git-এর নির্দিষ্ট মুহূর্তে চলা script: client-side-এ pre-commit (commit-এর আগে, যেমন format বা secret scan), commit-msg (বার্তা যাচাই), pre-push; server-side-এ pre-receive, update, post-receive. Exit code শূন্য না হলে কাজ থামে (post-* hook ছাড়া)।

Client-side hook নিশ্চয়তা দেয় না: .git/hooks clone-এ আসে না (নিরাপত্তার কারণে — নইলে clone করামাত্র অচেনা কোড চলত), প্রত্যেককে core.hooksPath বা একটি framework দিয়ে চালু করতে হয়, আর --no-verify এগুলো এড়ায়। তাই একই নিয়ম আবার server-side hook বা protected branch-এর বাধ্যতামূলক CI-তে (পর্ব ৫৮)। Local hook দ্রুত feedback, CI নিশ্চয়তা।

ফলো-আপ: “pre-commit hook ধীর হলে?” — মানুষ --no-verify-এ অভ্যস্ত হন; local অংশ কয়েক সেকেন্ডে রাখুন, ভারী test CI-তে।

উত্তর: Git Flow (Vincent Driessen-এর ২০১০ সালের লেখা থেকে জনপ্রিয়): দীর্ঘস্থায়ী main আর develop, সাথে feature, release আর hotfix branch. একসাথে কয়েকটি version রক্ষণাবেক্ষণ করতে হয় এমন software-এ (যেমন install করা app, library) কাজে লাগে, কিন্তু merge বেশি আর feedback ধীর। GitHub Flow: একটি main, ছোট feature branch, pull request, review আর merge — প্রায়ই deploy হওয়া web app-এর জন্য সরল। Trunk-based development: সবাই খুব ছোট বদল ঘন ঘন (দিনে অন্তত একবার) main-এ মেলান, অসম্পূর্ণ কাজ feature flag-এর পেছনে; ভালো CI আর test ছাড়া চলে না।

Forsgren, Humble আর Kim-এর Accelerate (২০১৮) বইয়ের গবেষণায় trunk-based ধাঁচের অনুশীলনের সাথে ভালো delivery performance-এর সম্পর্ক পাওয়া গেছে বলে জানানো হয় — তবে সম্পর্ক মানেই কারণ নয় (পর্ব ১৭, পর্ব ৫৯)।

ফলো-আপ: “দীর্ঘস্থায়ী feature branch-এর সমস্যা?” — integration দেরিতে, বড় conflict, review কঠিন; উপায় ছোট pull request আর branch by abstraction.

উত্তর: Git একটি content-addressed key-value store: প্রতিটি object-এর নাম তার বিষয়বস্তুর hash (type size\0content-এর SHA-1). Blob-এ শুধু file-এর বিষয়বস্তু — নাম নেই। Tree-তে একটি folder-এর তালিকা: mode, type, ID আর নাম। Commit-এ একটি root tree, parent-গুলো, লেখক, committer আর বার্তা। তাই file-এর নাম tree-তে থাকে; rename মানে শুধু tree বদল, blob একই। একটি ছোট repository-তে Git ২.৫৩:

$ git cat-file -p HEAD
tree 1f01aec9f1ec93ab2f1615d5df75bd003e587cdf
author Rahim <rahim@example.com> 1768449660 +0600
committer Rahim <rahim@example.com> 1768449660 +0600

feat: cart
$ git cat-file -p HEAD^{tree}
100644 blob 2ed6330246dfcb27bdee07aec6d59673c9c39bae	cart.js
040000 tree 90ac27eb6de108975ed6fc01587a572fb9fbf49a	docs
$ git cat-file -p HEAD:docs
100644 blob 2ed6330246dfcb27bdee07aec6d59673c9c39bae	copy.js
$ printf "function total() {}\n" | git hash-object --stdin
2ed6330246dfcb27bdee07aec6d59673c9c39bae
$ git count-objects -v | head -2
count: 4
size: 0

cart.js আর docs/copy.js-এর বিষয়বস্তু একই, তাই দুই tree-তেই একই blob 2ed6330 — একবারই সংরক্ষিত, মোট object ৪টি (commit, দুটি tree, একটি blob). hash-object দেখায়, Git-এ না রেখেও বিষয়বস্তু থেকে ID হিসাব করা যায়।

ফলো-আপ: (ক) “Commit-এর তারিখ বদলালে ID?” — বদলায়, কারণ তারিখ commit object-এর অংশ; এজন্যই এই পাতায় তারিখ স্থির রাখা হয়েছে। (খ) “Annotated tag?” — চতুর্থ object type, নিজের বার্তা ও লেখকসহ।

উত্তর: Git-এ (২০০৫) hash-এর মূল কাজ ছিল অখণ্ডতা: প্রতিটি commit তার tree আর parent-এর ID ধরে রাখে, তাই ইতিহাসের যেকোনো byte বদলালে পরের সব ID বদলে যায় — একটি Merkle-ধাঁচের শৃঙ্খল। ২০১৭ সালে Google আর CWI Amsterdam-এর গবেষকেরা প্রথম ব্যবহারিক SHA-1 collision (“SHAttered”) প্রকাশ করেন। Git-এর সাড়া: Git ২.১৩ (২০১৭) থেকে ডিফল্টে “hardened SHA-1” (SHA-1DC), যা এ ধরনের collision আক্রমণের চিহ্ন hash করার সময়ই ধরে; আর দীর্ঘমেয়াদে SHA-256 object format — Git ২.২৯ (২০২০) থেকে git init --object-format=sha256, শুরুতে পরীক্ষামূলক।

সতর্কতা: SHA-1 আর SHA-256 repository-র মধ্যে আদান-প্রদান এখনো সীমিত, আর hosting platform ও tool-এর সমর্থন অসমান (লেখার সময়ে); ভবিষ্যৎ বড় version-এ SHA-256-কে ডিফল্ট করার পরিকল্পনার কথা Git-এর নিজের নথিতে আছে — release note দেখে নিন (পর্ব ৫২, ৫৭)।

ফলো-আপ: “Hash collision হলে signed commit-এর কী?” — signature commit object-এর ওপর, যা hash দিয়ে tree আর parent-কে বাঁধে; তাই hash দুর্বল হলে signature-এর নিশ্চয়তাও দুর্বল হয়।

উত্তর: তিন স্তরে বাঁচানো হয়। এক, deduplication: অপরিবর্তিত file-এর blob আর অপরিবর্তিত folder-এর tree নতুন commit-এ আবার ব্যবহৃত হয় (প্র ১৯)। দুই, প্রতিটি “loose” object zlib দিয়ে সংকুচিত। তিন, git gc (আর push/fetch) object-গুলোকে packfile-এ ভরে, যেখানে অনেক object অন্য একটি মিলের object-এর সাপেক্ষে delta হিসেবে থাকে — কোনটির সাপেক্ষে, তা Git type, নাম আর আকার দেখে heuristic-এ বাছে, অবশ্যই “আগের version” নয়। .idx file দ্রুত খোঁজার সূচি। যুক্তিতে snapshot, ডিস্কে delta.

দেখতে: git count-objects -vH (পরিস্থিতি ১১-এ size-pack 3.00 MiB থেকে 1.97 KiB), git verify-pack -v. Random binary file (zip, ভিডিও) প্রায় সংকুচিত হয় না, delta-ও কাজে আসে না — তাই সেগুলোর জন্য Git LFS.

ফলো-আপ: “বড় repository clone দ্রুত করতে?” — shallow clone (--depth 1), partial clone (--filter=blob:none), আর sparse checkout.

উত্তর: “Reuse recorded resolution”. git config rerere.enabled true চালু থাকলে Git প্রতিটি conflict-এর আকৃতি (দুই দিকের লেখা) আর আপনার সমাধান .git/rr-cache-এ লিখে রাখে; পরে হুবহু একই conflict আবার এলে সমাধানটি নিজেই বসায়। কাজে লাগে যখন একই conflict বারবার আসে: দীর্ঘস্থায়ী branch বারবার rebase, একটি merge বাতিল করে আবার চেষ্টা, বা integration branch-এ নিয়মিত test merge.

ঝুঁকি: একবার ভুল সমাধান লিখে রাখলে সেটিও বারবার বসবে, নিঃশব্দে। তাই rerere বসানোর পরেও file দেখে নিজে git add করুন (ডিফল্টে Git আপনার জন্য stage করে না), test চালান, আর ভুল হলে git rerere forget <path> (পর্ব ৫৪)।

ফলো-আপ: “Conflict কম করতে আর কী?” — merge.conflictStyle diff3 বা zdiff3 (base-ও দেখায়), ছোট ও ঘন ঘন merge, আর formatter-এর ঐকমত্য।

উত্তর: না — user.name আর user.email যে-কেউ যা খুশি লিখতে পারেন; এই পাতার Rahim আর Karim-ও শুধু config-এর দুটি লাইন। Signed commit-এ commit object-এর ওপর একটি cryptographic স্বাক্ষর যুক্ত হয় — GPG, SSH key (Git ২.৩৪, ২০২১ থেকে, gpg.format ssh) বা X.509. git commit -S বা commit.gpgsign true; যাচাই git log --show-signature, git verify-commit; SSH-এর জন্য gpg.ssh.allowedSignersFile. Platform-গুলো যাচাই হলে “Verified”-ধাঁচের চিহ্ন দেখায় (platform-ভেদে আলাদা)।

প্রমাণ করে: এই key-এর মালিক এই নির্দিষ্ট commit (tree, parent, বার্তা) সই করেছেন, পরে কিছু বদলায়নি। করে না: কোডটি নিরাপদ, review হয়েছে, বা key চুরি হয়নি। Rebase বা amend করলে নতুন commit — আবার সই লাগে।

ফলো-আপ: “Tag সই?” — git tag -s; release-এর জন্য বেশি গুরুত্বপূর্ণ, কারণ মানুষ tag দেখে download করেন।

উত্তর: Submodule মূল repository-তে অন্য একটি repository-র একটি নির্দিষ্ট commit-এর রেফারেন্স রাখে (tree-তে mode 160000-এর একটি “gitlink”, সাথে .gitmodules-এ URL). সুবিধা: আলাদা ইতিহাস, আলাদা অধিকার, নির্দিষ্ট version-এ বাঁধা। ফাঁদ: clone-এ --recurse-submodules ভুলে যাওয়া (খালি folder), submodule-এর ভেতরে detached HEAD-এ কাজ করে হারানো, ভেতরে commit করে বাইরের pointer আপডেট না করা, আর CI-তে আলাদা credential. Subtree অন্য project-এর file (চাইলে ইতিহাসসহ) একটি sub-folder-এ সরাসরি কপি করে — ব্যবহারকারীর জন্য সহজ, ফেরত পাঠানো কঠিন।

Monorepo-তে অনেক project এক repository-তে: এক commit-এ কয়েকটি project জুড়ে বদল (atomic change), এক CI, সহজ refactor; কিন্তু আকার বাড়লে tooling লাগে — sparse checkout, partial clone, বদলানো অংশ বুঝে build ও test, আর CODEOWNERS-এর মতো মালিকানা নিয়ম। সিদ্ধান্তের মূল প্রশ্ন: project-গুলো কি একসাথে বদলায় আর release হয়? (পর্ব ১৯)

ফলো-আপ: “বড় binary?” — Git LFS: repository-তে ছোট pointer file, আসল file আলাদা server-এ।

উত্তর: ধরে নিন key ফাঁস হয়ে গেছে — কেউ clone করে থাকতে পারেন, স্বয়ংক্রিয় bot public repository স্ক্যান করে। তাই ক্রম: (১) Revoke — যে service-এর key, সেখানে key বাতিল; (২) Rotate — নতুন key বানিয়ে secret manager বা environment variable-এ, কোডে নয়; (৩) ব্যবহারের log দেখে অপব্যবহার হয়েছে কি না যাচাই; (৪) তারপর ইতিহাস পরিষ্কার — নতুন clone-এ git filter-repo (বা BFG), force push, দলকে নতুন করে clone করতে বলা; (৫) প্রতিরোধ — .gitignore-এ .env, commit-এর আগে secret scanner, platform-এর push protection, CI-তে আবার scan.

কেন আগে বাতিল: ইতিহাস পরিষ্কার করতে সময় লাগে, আর সব কপি মোছা যায় না — অন্যদের clone, fork, platform-এর cache বা pull request-এর ref. বাতিল করা key history-তে থাকলেও মূল্যহীন (পরিস্থিতি ৯, পর্ব ৫৭)।

ফলো-আপ: “শুধু একটি নতুন commit-এ key মুছে দিলে?” — key পুরোনো commit-এ থেকেই যায়; git log -S দিয়ে যে-কেউ খুঁজে পান।

ভাবনা: commit দুটি ঠিকই আছে, শুধু ভুল নামফলকের নিচে। সমাধান মানে লেবেল সরানো: যেখানে commit-গুলো আছে সেখানে নতুন branch-এর নাম বসানো, আর main-কে origin/main-এ ফিরিয়ে নেওয়া। কোনো commit কপি বা নতুন করে তৈরি করতে হয় না।

$ git status -sb
## main...origin/main [ahead 2]
$ git log --oneline --graph --decorate --all
* 3094561 (HEAD -> main) feat(coupon): apply 10% off
* d44ecb6 feat(coupon): add coupon constant
* 8599541 (origin/main) feat: cart total
$ git branch feature/coupon
$ git reset --keep origin/main
$ git switch feature/coupon
Switched to branch 'feature/coupon'
$ git log --oneline --graph --decorate --all
* 3094561 (HEAD -> feature/coupon) feat(coupon): apply 10% off
* d44ecb6 feat(coupon): add coupon constant
* 8599541 (origin/main, main) feat: cart total
$ git status -sb
## feature/coupon

কেন কাজ করে: git branch feature/coupon বর্তমান commit 3094561-এ নতুন নাম বসায় — এখন দুই commit দুই branch থেকেই পৌঁছানো যায়, তাই পরের ধাপে কিছুই হারায় না। git reset --keep origin/main main-কে 8599541-এ ফেরায়; --hard-এর বদলে --keep নিয়েছি, কারণ commit না করা কোনো বদল থাকলে এটি মুছে না দিয়ে থেমে যায়। শেষ log-এ commit-গুলোর ID একই — শুধু লেবেল বদলেছে (নিচের ছবি)।

ফলো-আপ: (ক) “feature/coupon আগে থেকেই থাকলে, আর তাতে অন্য commit থাকলে?” — সেটিতে switch করে git cherry-pick d44ecb6^..3094561, তারপর main-এ ফিরে git reset --keep origin/main. (খ) “Push হয়ে গিয়ে থাকলে?” — shared main-এ reset নয়; branch থেকে কাজ চালিয়ে যান আর main-এ git revert (পরিস্থিতি ৮), বা দলের সাথে কথা বলে সিদ্ধান্ত।

ভাবনা: reset commit মোছে না, শুধু branch-এর pointer সরায়। হারানো commit-গুলো object store-এ আছে, আর HEAD-এর reflog-এ লেখা আছে reset-এর ঠিক আগে HEAD কোথায় ছিল।

$ git log --oneline
9fc0cfd test(search): add trim test
d0c4649 feat(search): trim the query
6bbbcfb feat(search): add search stub
25ae777 feat: cart skeleton
$ git reset --hard HEAD~3
HEAD is now at 25ae777 feat: cart skeleton
$ git log --oneline
25ae777 feat: cart skeleton
$ git reflog -5
25ae777 HEAD@{0}: reset: moving to HEAD~3
9fc0cfd HEAD@{1}: commit: test(search): add trim test
d0c4649 HEAD@{2}: commit: feat(search): trim the query
6bbbcfb HEAD@{3}: commit: feat(search): add search stub
25ae777 HEAD@{4}: checkout: moving from main to feature/search
$ git branch rescue/search HEAD@{1}
$ git log --oneline rescue/search
9fc0cfd test(search): add trim test
d0c4649 feat(search): trim the query
6bbbcfb feat(search): add search stub
25ae777 feat: cart skeleton
$ git reset --hard rescue/search
HEAD is now at 9fc0cfd test(search): add trim test
$ git branch -d rescue/search
Deleted branch rescue/search (was 9fc0cfd).
$ git log --oneline
9fc0cfd test(search): add trim test
d0c4649 feat(search): trim the query
6bbbcfb feat(search): add search stub
25ae777 feat: cart skeleton
$ git reflog -3
9fc0cfd HEAD@{0}: reset: moving to rescue/search
25ae777 HEAD@{1}: reset: moving to HEAD~3
9fc0cfd HEAD@{2}: commit: test(search): add trim test

কেন কাজ করে: reflog-এর সবচেয়ে নতুন entry HEAD@{0} হলো reset নিজে; তার ঠিক আগের HEAD@{1} = 9fc0cfd, শেষ commit. সরাসরি reset না করে আগে একটি rescue/search branch বানালাম, যাতে যাচাইয়ের সময়ও commit-গুলো একটি নামে বাঁধা থাকে; তারপর branch-টিকে সেখানে ফিরিয়ে rescue মুছে দিলাম (-d রাজি হলো, কারণ সবকিছু এখন merged). শেষ reflog দেখায় উদ্ধারটিও একটি নতুন entry — reflog কখনো পেছনে লেখে না, শুধু যোগ করে।

ফলো-আপ: (ক) “Reset-এর আগে commit না করা বদল ছিল?” — সেটি ফেরে না, কারণ কখনো object হয়নি; শুধু git add করা থাকলে git fsck --lost-found-এ blob হিসেবে পাওয়া যেতে পারে। (খ) “ORIG_HEAD?” — reset নিজেই ORIG_HEAD লিখে রাখে, তাই ঠিক পরের মুহূর্তে git reset --hard ORIG_HEAD-ও কাজ করত।

ভাবনা: main-এ label()-এর লাইনে দুই দশমিক যোগ হয়েছে, আর feature-এর প্রথম commit একই লাইনে “(VAT incl.)” যোগ করেছে। Rebase commit-গুলো একে একে চালায়, তাই conflict হবে প্রথম commit-এ, আর থামবে মাঝপথে।

$ git log --oneline --graph --decorate --all
* ee44e89 (main) fix(cart): show 2 decimals
| * 51ef1c3 (HEAD -> feature/badge) feat(cart): add badge style
| * 3fc5c8d feat(cart): mention VAT in label
|/
* 304691b feat: cart label
$ git rebase main
Auto-merging cart.js
CONFLICT (content): Merge conflict in cart.js
error: could not apply 3fc5c8d... feat(cart): mention VAT in label
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Could not apply 3fc5c8d... # feat(cart): mention VAT in label
$ git status --short
UU cart.js
$ cat cart.js
const VAT = 0.15;
function label(t) {
<<<<<<< HEAD
  return "Total: " + t.toFixed(2);
=======
  return "Total: " + t + " (VAT incl.)";
>>>>>>> 3fc5c8d (feat(cart): mention VAT in label)
}
$ # keep both changes, remove the markers
$ git add cart.js
$ git rebase --continue
[detached HEAD c8b9567] feat(cart): mention VAT in label
 1 file changed, 1 insertion(+), 1 deletion(-)
Successfully rebased and updated refs/heads/feature/badge.
$ git log --oneline --graph --decorate --all
* c2edcb2 (HEAD -> feature/badge) feat(cart): add badge style
* c8b9567 feat(cart): mention VAT in label
* ee44e89 (main) fix(cart): show 2 decimals
* 304691b feat: cart label

কেন কাজ করে: marker-এর লেবেল লক্ষ করুন — HEAD-এর দিকে main-এর লেখা (toFixed(2)), আর নিচে 3fc5c8d, অর্থাৎ replay হওয়া আপনার commit. Rebase-এ “ours” মানে নতুন ভিত্তি, merge-এর ঠিক উল্টো। দুটি বদলই রেখে marker মুছে git add, তারপর git rebase --continue (editor খোলে commit বার্তা নিয়ে; এখানে না বদলে সংরক্ষণ করা হয়েছে)। দ্বিতীয় commit conflict ছাড়াই বসেছে। শেষে সরলরেখা, আর দুটি commit-ই নতুন ID পেয়েছে (c8b9567, c2edcb2). (চলার সময় Git একই লাইনে Rebasing (1/2)-ধাঁচের অগ্রগতি দেখায় আর পরে মুছে দেয়; এখানে চূড়ান্ত পর্দা।)

ফলো-আপ: (ক) “মাঝপথে সব বাতিল?” — git rebase --abort, branch আগের অবস্থায়। (খ) “এই commit-টি আর দরকার নেই?” — git rebase --skip. (গ) “একই conflict বারবার?” — rerere (প্র ২২)।

ভাবনা: commit-টি ভেঙে বদলগুলো আবার working tree-তে ফিরিয়ে আনা, তারপর অংশ অংশ করে stage আর commit. শেষ commit হলে --mixed reset-ই যথেষ্ট।

$ git show --stat --oneline HEAD
cb28318 wip: total and docs
 README.md | 1 +
 cart.js   | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
$ git reset HEAD~1
Unstaged changes after reset:
M	README.md
M	cart.js
$ git status --short
 M README.md
 M cart.js
$ git add cart.js
$ git commit -m "feat(cart): sum item prices"
[main 5d7fe9d] feat(cart): sum item prices
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git add README.md
$ git commit -m "docs: how to run"
[main 88c45a3] docs: how to run
 1 file changed, 1 insertion(+)
$ git log --oneline
88c45a3 docs: how to run
5d7fe9d feat(cart): sum item prices
9e5888e feat: cart skeleton

কেন কাজ করে: git reset HEAD~1 (ডিফল্ট --mixed) commit-টি বাদ দেয় কিন্তু বদল folder-এ রাখে — Git নিজেই “Unstaged changes after reset” তালিকা দেখায়। তারপর file ধরে আলাদা commit. একই file-এর ভেতরে দুই কাজ মিশে থাকলে git add -p দিয়ে hunk বেছে নিন।

ফলো-আপ: “Commit-টি শেষেরটি না হয়ে তিন commit আগের হলে?” — git rebase -i HEAD~3, সেই commit-এর লাইনে pick-এর বদলে edit; rebase সেখানে থামলে ঠিক ওপরের মতো git reset HEAD~1, ভাগ করে commit, তারপর git rebase --continue.

ভাবনা: তিনটির মোট বদল হবে একটি commit-এর বদল; ভিত্তি 88c45a3 একই থাকবে। পথ ১: interactive rebase-এ ২য় আর ৩য়টিকে fixup (বার্তা ফেলে মেলানো; squash হলে বার্তাও মেলে)। পথ ২: reset --soft করে একবারে commit.

$ git log --oneline
8954a6d default qty to 1
02f0755 fix typo
ce6963c feat(cart): multiply by qty
88c45a3 docs: how to run
5d7fe9d feat(cart): sum item prices
9e5888e feat: cart skeleton
$ git rebase -i HEAD~3
Successfully rebased and updated refs/heads/main.

Editor-এ খোলা todo আর বদলানোর পরের রূপ (মন্তব্যের লাইন বাদ দিয়ে):

pick ce6963c # feat(cart): multiply by qty
pick 02f0755 # fix typo
pick 8954a6d # default qty to 1
# ---- বদলে করা হলো ----
pick ce6963c # feat(cart): multiply by qty
fixup 02f0755 # fix typo
fixup 8954a6d # default qty to 1

$ git log --oneline
48ce2b8 feat(cart): multiply by qty
88c45a3 docs: how to run
5d7fe9d feat(cart): sum item prices
9e5888e feat: cart skeleton
$ git show --stat --oneline HEAD
48ce2b8 feat(cart): multiply by qty
 cart.js | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git diff --quiet ORIG_HEAD HEAD && echo "same content"
same content
$ git switch -q -c try/soft ORIG_HEAD
$ git reset --soft HEAD~3
$ git status --short
M  cart.js
$ git commit -q -m "feat(cart): multiply by qty"
$ git log --oneline -2
dd88c74 feat(cart): multiply by qty
88c45a3 docs: how to run

কেন কাজ করে: rebase প্রথম commit চালিয়ে তার ওপর বাকি দুটির বদল একই commit-এ যোগ করেছে; ORIG_HEAD (rebase-এর আগের মাথা 8954a6d) আর নতুন 48ce2b8-এর file হুবহু এক — “same content”. পথ ২-এ reset --soft HEAD~3 তিনটি বদলকেই staged রেখে branch পেছায় (M cart.js), আর একটি commit-ই যথেষ্ট। দুই পথের ফল একই বিষয়বস্তু, কিন্তু ID আলাদা (48ce2b8 বনাম dd88c74): fixup প্রথম commit-এর লেখকের সময় রাখে, নতুন commit নতুন সময় নেয়।

ফলো-আপ: “আগে থেকেই পরিকল্পনা করে?” — git commit --fixup=<hash>, পরে git rebase -i --autosquash main; todo নিজেই সাজানো থাকে।

ভাবনা: tag checkout মানে detached HEAD; সেখানে commit হয়, কিন্তু কোনো branch নামের নিচে নয়। Switch করলে HEAD সরে যায়, আর commit দুটি নামহীন হয়ে পড়ে — তবে মুছে যায় না।

$ git switch --detach v1.0
HEAD is now at 724e420 feat: cart
$ git commit -q -am "try: old behaviour"
$ git commit -q -am "try: second idea"
$ git status | head -1
HEAD detached from v1.0
$ git switch main
Warning: you are leaving 2 commits behind, not connected to
any of your branches:

  8a665bf try: second idea
  6103f73 try: old behaviour

If you want to keep them by creating a new branch, this may be a good time
to do so with:

 git branch <new-branch-name> 8a665bf

Switched to branch 'main'
$ git reflog -2
90061cc HEAD@{0}: checkout: moving from 8a665bf650f6816b78f2bfe57da2b14e45933737 to main
8a665bf HEAD@{1}: commit: try: second idea
$ git branch try/old-behaviour 8a665bf
$ git log --oneline --graph --decorate --all
* 8a665bf (try/old-behaviour) try: second idea
* 6103f73 try: old behaviour
| * 90061cc (HEAD -> main) fix: total returns 0
|/
* 724e420 (tag: v1.0) feat: cart

কেন কাজ করে: Git নিজেই সতর্ক করেছে (“you are leaving 2 commits behind”) আর ঠিক কোন command চালাতে হবে তাও বলেছে — git branch <new-branch-name> 8a665bf. বার্তাটি চলে গেলেও reflog-এ HEAD@{1} একই commit দেখায়। নাম বসানোর পরে graph-এ দেখা যায় পরীক্ষার branch v1.0 থেকে আলাদা হয়েছে।

ফলো-আপ: “ভবিষ্যতে?” — পুরোনো version-এ কাজ করার পরিকল্পনা থাকলে শুরুতেই git switch -c try/old v1.0. আর git status-এর প্রথম লাইন “HEAD detached from v1.0” দেখলেই সতর্ক হোন।

ভাবনা: stash entry একটি commit; drop শুধু refs/stash-এর reflog থেকে তাকে সরায়। Commit object এখনো আছে, কিন্তু কোনো ref বা reflog থেকে পৌঁছানো যায় না — অর্থাৎ unreachable. git fsck এমন object খুঁজে দেয়।

$ git stash push -m "discount: half-done badge"
Saved working directory and index state On main: discount: half-done badge
$ git stash list
stash@{0}: On main: discount: half-done badge
$ git stash drop
Dropped refs/stash@{0} (97c075e9d39347366116c1afffc8fd8efa9042a5)
$ git stash list
$ # terminal closed; the hash above is gone from view
$ git fsck --no-reflogs --unreachable | grep commit
unreachable commit 0d4ae7023f9e2e1a6e2b38ed59c8a5c624c66f8f
unreachable commit 97c075e9d39347366116c1afffc8fd8efa9042a5
$ git log --oneline --no-walk 0d4ae70 97c075e
0d4ae70 index on main: 724e420 feat: cart
97c075e On main: discount: half-done badge
$ git stash apply -q 97c075e
$ git status --short
 M cart.js

কেন কাজ করে: drop-এর বার্তায় বন্ধনীর hash-টিই stash commit (97c075e) — দেখা থাকলে সরাসরি git stash apply 97c075e. Hash হারালে git fsck --no-reflogs --unreachable দুটি commit দেখায়: stash-এর W আর তার index-অংশ I. বার্তা দেখে চেনা যায় — “index on main: …” হলো I, “On main: discount: half-done badge” হলো W. W-কে apply করলেই কাজ ফেরত।

ফলো-আপ: (ক) “কতদিন পর্যন্ত?” — garbage collection unreachable object-কে ডিফল্টে দুই সপ্তাহের বেশি পুরোনো হলে মুছতে পারে (gc.pruneExpire), তাই দেরি না করাই ভালো। (খ) “অনেক unreachable commit হলে?” — git log --oneline --no-walk $(git fsck --no-reflogs --unreachable | awk '/commit/ {print $3}') দিয়ে সব একসাথে দেখুন, আর “WIP on” / “On <branch>:” বার্তা খুঁজুন।

ভাবনা: push হওয়া shared branch-এ reset করলে সবার ইতিহাস ভেঙে যায়। তাই উল্টো বদলের একটি নতুন commit — revert. পরের commit (README) অক্ষত থাকবে।

$ git log --oneline --decorate
d51da66 (HEAD -> main, origin/main) docs: add README
058b956 feat: free shipping for all
b1f5392 feat: add config
$ git revert --no-edit HEAD~1
[main fd4d001] Revert "feat: free shipping for all"
 Date: Thu Jan 15 10:04:00 2026 +0600
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git log --oneline --decorate
fd4d001 (HEAD -> main) Revert "feat: free shipping for all"
d51da66 (origin/main) docs: add README
058b956 feat: free shipping for all
b1f5392 feat: add config
$ git show --stat --format="%h %s%n%n%b" HEAD
fd4d001 Revert "feat: free shipping for all"

This reverts commit 058b956b4cf277c8005cf5947ed51ed4da29ecfe.


 config.js | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
$ cat config.js
const VAT = 0.15;
const SHIPPING = 60;
$ git push origin main
To ../s02srv.git
   d51da66..fd4d001  main -> main

কেন কাজ করে: git revert HEAD~1 শুধু 058b956-এর বদল উল্টায় — SHIPPING আবার 60 — আর বার্তায় লেখে কোন commit উল্টানো হলো। ইতিহাস শুধু সামনে বেড়েছে, তাই push সাধারণ fast-forward (d51da66..fd4d001); কারও কপি ভাঙেনি।

ফলো-আপ: (ক) “পরে feature-টি আবার চালু করতে?” — revert commit-টিকেই revert করুন (git revert fd4d001); পুরোনো branch আবার merge করলে Git ভাবে ওই বদল আগেই এসেছে। (খ) “Merge commit বাতিল?” — git revert -m 1 <merge>. (গ) “একসাথে কয়েকটি?” — git revert --no-commit A^..B, তারপর একটি commit.

ভাবনা: পরের commit key মুছলেও আগের commit-এ সেটি আছে। তাই প্রথমে key বাতিল আর নতুন key (Git-এর বাইরের কাজ, এখানে দেখানো নেই), তারপর কোন commit-এ আছে খোঁজা, তারপর ইতিহাস পরিষ্কার। (এই key কাল্পনিক, FAKE_ দিয়ে শুরু।)

$ git log --oneline
5cca787 fix(pay): read key from environment
c667265 feat(pay): connect payment sandbox
e0ea449 feat: add config
$ git log --oneline -S FAKE_sk_test --all
5cca787 fix(pay): read key from environment
c667265 feat(pay): connect payment sandbox
$ git grep -n FAKE_sk_test $(git rev-list --all)
c66726554c9c9d02eb4a3273850971efe2f68943:config.js:2:const PAY_KEY = "FAKE_sk_test_9fQ2xLm4Rt7Vb1Nz";

git log -S দেখায় কোন commit লেখাটি যোগ বা মুছেছে (c667265 যোগ, 5cca787 মুছেছে), আর git grep … $(git rev-list --all) দেখায় কোন commit-এর snapshot-এ এখনো আছে। এবার একটি নতুন clone-এ, একটি replacement file দিয়ে (regex:FAKE_sk_test_[A-Za-z0-9]+==>REDACTED):

$ git clone -q s07srv.git s07clean
$ git filter-repo --replace-text ../replacements.txt
NOTICE: Removing 'origin' remote; see 'Why is my origin removed?'
        in the manual if you want to push back there.
        (was ../s07srv.git)
Parsed 3 commits
HEAD is now at 58cd9c7 fix(pay): read key from environment

New history written in 0.16 seconds; now repacking/cleaning...
Repacking your repo and cleaning out old unneeded objects
Completely finished after 0.32 seconds.
$ git log --oneline
58cd9c7 fix(pay): read key from environment
53b0e30 feat(pay): connect payment sandbox
e0ea449 feat: add config
$ git log --oneline -S FAKE_sk_test --all
$ git show HEAD~1:config.js
const VAT = 0.15;
const PAY_KEY = "REDACTED";
$ git remote -v
$ git remote add origin ../s07srv.git
$ git push --force --all origin
To ../s07srv.git
 + 5cca787...58cd9c7 main -> main (forced update)
$ git push --force --tags origin
Everything up-to-date

কেন কাজ করে: filter-repo প্রতিটি commit-এর blob-এ লেখাটি বদলেছে; যে commit বদলেছে তার আর তার পরের সবার ID নতুন (c667265 → 53b0e30), কিন্তু প্রথম commit e0ea449-এ key ছিল না, তাই সেটি একই। ভুল জায়গায় push ঠেকাতে filter-repo নিজেই origin সরায়; আমরা ইচ্ছা করে আবার যোগ করে --force push করেছি। (অগ্রগতির লাইনগুলো একসাথে এক লাইনে ছাপা হয়, আর সময় প্রতিবার আলাদা।)

ফলো-আপ: “এতেই কি শেষ?” — না। সবাইকে নতুন করে clone করতে বলুন (পুরোনো clone থেকে push হলে key ফিরে আসবে); platform-এ fork, pull request-এর ref বা cache-এ কপি থাকতে পারে — platform-এর নিয়ম দেখে তাদের সাহায্য চাইতে হতে পারে। এজন্যই বাতিল প্রথম কাজ।

ভাবনা: good = v1.0, bad = HEAD, আর একটি ছোট script যা ১১৫ পেলে exit 0, না পেলে শূন্য ছাড়া কিছু দেয় — তাহলে git bisect run নিজেই binary search চালাবে।

$ git log --oneline
a4b9c61 docs: note 7
ea4bdd0 docs: note 6
70e078e docs: note 5
096faf0 docs: note 4
41d99a1 refactor(price): round total up
70f3c70 docs: note 3
578c54e docs: note 2
815d0cc docs: note 1
7b57e89 feat: price with VAT
$ cat test.sh
r=$(node -e "console.log(require(\"./price.js\")(100))")
[ "$r" = "115" ]
$ sh test.sh; echo "exit=$?"
exit=1
$ git bisect start HEAD v1.0
Bisecting: 3 revisions left to test after this (roughly 2 steps)
[41d99a17a460f0aeb79b00e1e023a16950f76627] refactor(price): round total up
$ git bisect run sh test.sh
running 'sh' 'test.sh'
Bisecting: 1 revision left to test after this (roughly 1 step)
[578c54e00235f7635796682de9f5d4f89a7d8e10] docs: note 2
running 'sh' 'test.sh'
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[70f3c70ef42f9c5b353dd364d3eed3747817a297] docs: note 3
running 'sh' 'test.sh'
41d99a17a460f0aeb79b00e1e023a16950f76627 is the first bad commit
commit 41d99a17a460f0aeb79b00e1e023a16950f76627
Author: Rahim <rahim@example.com>
Date:   Thu Jan 15 10:05:00 2026 +0600

    refactor(price): round total up

 price.js | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
bisect found first bad commit
$ git bisect log | grep -v "^#"
git bisect start 'HEAD' 'v1.0'
git bisect bad 41d99a17a460f0aeb79b00e1e023a16950f76627
git bisect good 578c54e00235f7635796682de9f5d4f89a7d8e10
git bisect good 70f3c70ef42f9c5b353dd364d3eed3747817a297
$ git bisect reset
Previous HEAD position was 70f3c70 docs: note 3
Switched to branch 'main'
$ git show --format=%h 41d99a1 -- price.js | tail -3
-function withVat(p) { return p + p * 15 / 100; }
+function withVat(p) { return Math.ceil(p + p * 15 / 100 + 0.01); }
 module.exports = withVat;

কেন কাজ করে: সন্দেহের তালিকায় আটটি commit (v1.0-এর পরের সব)। Git প্রথমে মাঝখানের 41d99a1 পরীক্ষা করেছে — bad; তারপর 578c54e — good; তারপর 70f3c70 — good; তিনটি পরীক্ষাতেই উত্তর, ⌈log₂ ৮⌉ = ৩-এর সাথে মেলে। ধরা পড়া commit-টির diff-এ দেখা যায় Math.ceil আর + 0.01 যোগ হয়েছে — ১১৫.০১-কে ১১৬ বানাচ্ছে। শেষে git bisect reset আপনাকে আগের branch-এ ফেরায়।

ফলো-আপ: (ক) “এই test-টি পরে কী হবে?” — regression test হিসেবে test suite-এ রাখুন, যাতে bug ফিরে না আসে। (খ) “কিছু commit build-ই হয় না?” — script সেখানে exit 125 দিলে Git সেটি বাদ দেয়। (গ) “Bug যোগ না হয়ে ‘ঠিক হয়েছে’ এমন commit খুঁজতে?” — git bisect start --term-old=broken --term-new=fixed.

ভাবনা: পরের commit-এ মুছলে শুধু সর্বশেষ snapshot থেকে যায়, পুরোনো commit তো file-টি ধরে রাখে — তাই clone-এর আকার কমে না। দরকার প্রতিটি commit থেকে path-টি বাদ দিয়ে ইতিহাস নতুন করে লেখা, তারপর দলের সাথে সমন্বয় করে force push.

$ git clone -q --no-local s09srv.git s09clean
$ git log --oneline --stat
fdc5210 feat: cart v2
 cart.js | 1 +
 1 file changed, 1 insertion(+)
94803e5 build: add release zip
 build/app.zip | Bin 0 -> 3145728 bytes
 cart.js       |   1 +
 2 files changed, 1 insertion(+)
724e420 feat: cart
 cart.js | 1 +
 1 file changed, 1 insertion(+)
$ git count-objects -vH | grep size-pack
size-pack: 3.00 MiB
$ git filter-repo --invert-paths --path build/app.zip
NOTICE: Removing 'origin' remote; see 'Why is my origin removed?'
        in the manual if you want to push back there.
        (was ../s09srv.git)
Parsed 3 commits
HEAD is now at 43a23ed feat: cart v2

New history written in 0.17 seconds; now repacking/cleaning...
Repacking your repo and cleaning out old unneeded objects
Completely finished after 0.32 seconds.
$ git log --oneline --stat
43a23ed feat: cart v2
 cart.js | 1 +
 1 file changed, 1 insertion(+)
939fe6c build: add release zip
 cart.js | 1 +
 1 file changed, 1 insertion(+)
724e420 feat: cart
 cart.js | 1 +
 1 file changed, 1 insertion(+)
$ git count-objects -vH | grep size-pack
size-pack: 1.97 KiB
$ echo "build/" > .gitignore
$ git add .gitignore
$ git commit -q -m "chore: ignore build output"
$ git remote add origin ../s09srv.git
$ git push --force origin main
To ../s09srv.git
 + fdc5210...1c08a31 main -> main (forced update)

কেন কাজ করে: --invert-paths --path build/app.zip মানে “এই path ছাড়া বাকি সব রাখা হোক”। যে commit-এ zip ছিল (94803e5) সেটি আর তার পরের সব নতুন ID পেয়েছে; প্রথম 724e420 অপরিবর্তিত। Pack-এর আকার 3.00 MiB থেকে 1.97 KiB. Clone-টি --no-local দিয়ে নেওয়া হয়েছে, যাতে object pack হিসেবে আসে আর মাপ তুলনা করা যায়; filter-repo নিজেও একটি “fresh clone” চায়, যাতে ভুল repository-তে চলে না যায়। শেষে .gitignore-এ build/, যাতে আবার না ঘটে।

ফলো-আপ: (ক) “Server-এর জায়গা কি সাথে সাথে কমবে?” — server-এর নিজের garbage collection-এর ওপর নির্ভর করে; platform-ভেদে আলাদা। (খ) “পুরোনো পথ git filter-branch?” — এখনো Git-এর সাথে আসে, কিন্তু Git নিজেই চালানোর সময় সতর্ক করে আর filter-repo সুপারিশ করে (অংশ ৮)। (গ) “বড় file যদি সত্যিই দরকার?” — Git LFS.

ভাবনা: server-এ commit হারালেও Rahim-এর local main-এ তা আছে। Rahim fetch করলে দেখবেন server-এর ইতিহাস “forced update” হয়েছে; তাঁর কাজ Karim-এর নতুন commit-এর ওপর আবার বসিয়ে সাধারণ push করলেই হলো। প্রথমে Karim-এর দিক:

$ git push origin main
To ../s10srv.git
 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to '../s10srv.git'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. This is usually caused by another repository pushing to
hint: the same ref. If you want to integrate the remote changes, use
hint: 'git pull' before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
$ git push --force-with-lease origin main
To ../s10srv.git
 ! [rejected]        main -> main (stale info)
error: failed to push some refs to '../s10srv.git'
$ git push --force origin main
To ../s10srv.git
 + dcba3db...d467cc1 main -> main (forced update)

সাধারণ push “fetch first” বলে থেমেছে; --force-with-lease থেমেছে “stale info” বলে — এটিই সুরক্ষা কাজ করার মুহূর্ত। Karim তবু --force দিলেন। এবার Rahim:

$ git fetch origin
From ../s10srv
 + dcba3db...d467cc1 main       -> origin/main  (forced update)
$ git status -sb
## main...origin/main [ahead 1, behind 1]
$ git log --oneline --graph --decorate --all
* d467cc1 (origin/main, origin/HEAD) docs: README
| * dcba3db (HEAD -> main) feat(cart): add tax()
|/
* 724e420 feat: cart
$ git reflog -3 origin/main
d467cc1 refs/remotes/origin/main@{0}: fetch origin: forced-update
dcba3db refs/remotes/origin/main@{1}: update by push
724e420 refs/remotes/origin/main@{2}: update by push
$ git rebase origin/main
Successfully rebased and updated refs/heads/main.
$ git log --oneline --graph --decorate --all
* 7af6ce9 (HEAD -> main) feat(cart): add tax()
* d467cc1 (origin/main, origin/HEAD) docs: README
* 724e420 feat: cart
$ git push origin main
To ../s10srv.git
   d467cc1..7af6ce9  main -> main

কেন কাজ করে: fetch-এর + … (forced update) আর status-এর “ahead 1, behind 1” বলে দেয় ইতিহাস লেখা-বদল হয়েছে। origin/main-এর নিজের reflog দেখায় আগে সেটি dcba3db-এ ছিল — Rahim-এর local main না থাকলে এটিই উদ্ধারের সূত্র হতো (git branch rescue origin/main@{1})। git rebase origin/main Rahim-এর একমাত্র নিজের commit-টিকে Karim-এর README-র ওপর চালাল (7af6ce9), তারপর সাধারণ push — কোনো force লাগেনি, Karim-এর কাজও মোছেনি।

ফলো-আপ: “ভবিষ্যতে ঠেকাবেন কীভাবে?” — main-এ force push নিষেধ (protected branch); ব্যক্তিগত branch-এ শুধু --force-with-lease (দরকারে --force-if-includes); আর blameless আলোচনা — কেন Karim ভেবেছিলেন force দরকার।

ভাবনা: দুটি বৈধ পথ। দলের নিয়ম সরল ইতিহাস চাইলে: fetch, origin/main-এর ওপর rebase, তারপর --force-with-lease (branch-টি শুধু আপনার)। ইতিহাস না বদলাতে চাইলে: git merge origin/main আর সাধারণ push — একটি merge commit বাড়ে। এখানে প্রথম পথ:

$ git fetch -q origin
$ git rev-list --left-right --count origin/main...feature/search
2	2
$ git log --oneline --graph --decorate --all
* cf3a1cb (origin/main, origin/HEAD) fix(cart): total returns 0
* a287782 docs: README
| * 8ede6fa (HEAD -> feature/search, origin/feature/search) test(search): trim test
| * a06f4b9 feat(search): add search
|/
* 724e420 (main) feat: cart
$ git rebase origin/main
Successfully rebased and updated refs/heads/feature/search.
$ git rev-list --left-right --count origin/main...feature/search
0	2
$ git log --oneline --graph --decorate --all
* b287559 (HEAD -> feature/search) test(search): trim test
* ad09c8a feat(search): add search
* cf3a1cb (origin/main, origin/HEAD) fix(cart): total returns 0
* a287782 docs: README
| * 8ede6fa (origin/feature/search) test(search): trim test
| * a06f4b9 feat(search): add search
|/
* 724e420 (main) feat: cart
$ git push origin feature/search
To ../s11srv.git
 ! [rejected]        feature/search -> feature/search (non-fast-forward)
error: failed to push some refs to '../s11srv.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. If you want to integrate the remote changes,
hint: use 'git pull' before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
$ git push --force-with-lease origin feature/search
To ../s11srv.git
 + 8ede6fa...b287559 feature/search -> feature/search (forced update)

কেন কাজ করে: rebase-এর আগে 2 2 — main-এ আপনার কাছে না থাকা দুটি, আপনার দুটি main-এ নেই; পরে 0 2 — শুধু আপনার দুটি, main-এর সবকিছু ভিত্তিতে। Rebase-এর পরে commit-গুলোর ID নতুন (a06f4b9 → ad09c8a), আর server-এ পুরোনো দুটি আছে, তাই সাধারণ push “non-fast-forward” বলে থেমেছে। Lease-সহ force push নিরাপদে সেগুলো বদলেছে — মাঝে অন্য কেউ এই branch-এ push করলে থামত।

ফলো-আপ: “Reviewer যদি আগের commit-এ মন্তব্য করে থাকেন?” — rebase-এর পরে কিছু platform মন্তব্যকে “পুরোনো” দেখায়; বড় review চলাকালীন অনেক দল merge পছন্দ করে, বা শেষে একবারই rebase. git range-diff দিয়ে আগের আর নতুন commit-সারির পার্থক্যও দেখানো যায়।

ভাবনা: package.json মানুষের লেখা — হাতে মেলানো যায়: দুটি dependency-ই রাখুন। Lockfile tool-এর তৈরি, হাজার লাইনের হতে পারে, আর ভেতরের hash ও version একে অপরের সাথে বাঁধা — হাতে মেলানো ঝুঁকিপূর্ণ। নিয়ম: এক দিকের lockfile নিন, তারপর tool দিয়ে আবার তৈরি করুন। (এখানে library দুটি ছোট local folder, যাতে network ছাড়াই npm চালানো যায়।)

$ git switch -q feature/money
$ git merge main
Auto-merging package-lock.json
CONFLICT (content): Merge conflict in package-lock.json
Auto-merging package.json
CONFLICT (content): Merge conflict in package.json
Automatic merge failed; fix conflicts and then commit the result.
$ git status --short
UU package-lock.json
UU package.json
$ git diff --name-only --diff-filter=U
package-lock.json
package.json
$ sed -n "1,12p" package.json
{
  "name": "bazar",
  "version": "1.0.0",
  "private": true,
  "dependencies": {
<<<<<<< HEAD
    "money": "file:../s13libs/money"
=======
    "dates": "file:../s13libs/dates"
>>>>>>> main
  }
}
$ # package.json by hand: keep both dependencies
$ git checkout --theirs package-lock.json
Updated 1 path from the index
$ npm install --package-lock-only

up to date in 219ms
$ grep -c "node_modules/" package-lock.json
2
$ git add package.json package-lock.json
$ git commit --no-edit
[feature/money 2abf6ee] Merge branch 'main' into feature/money
$ git log --oneline --graph
*   2abf6ee Merge branch 'main' into feature/money
|\
| * 2a00fdb feat: add dates lib
* | 1cba94a feat: add money lib
|/
* 5ad2a6e chore: npm init

কেন কাজ করে: merge-এর সময় --ours = আপনার বর্তমান branch, --theirs = যে branch মেলাচ্ছেন (এখানে main) — rebase-এর সময় ঠিক উল্টো। main-এর lockfile নিয়ে npm install --package-lock-only চালালে npm হাতে মেলানো package.json দেখে আপনার library-টিও যোগ করে; lockfile-এ এখন দুটি package (node_modules/-এর দুটি entry). তারপর দুটি file add করে merge commit. (npm-এর সময়ের সংখ্যা প্রতিবার আলাদা।)

ফলো-আপ: (ক) “Lockfile-এ conflict কম করতে?” — dependency-র বদল ছোট আর আলাদা pull request-এ, আর main থেকে ঘন ঘন আপডেট। (খ) “CI-তে কী যাচাই?” — npm ci, যা lockfile আর package.json না মিললে ব্যর্থ হয়। অন্য ecosystem-এর lockfile-এও (যেমন Python, Rust) নীতি একই, command আলাদা।

ভাবনা: পুরো main merge করলে coupon-ও চলে আসবে। দরকার শুধু একটি commit-এর বদল — cherry-pick, -x দিয়ে উৎস লিখে; তারপর SemVer অনুযায়ী patch version.

$ git log --oneline --decorate --all
32ef04c (HEAD -> main) fix(cart): round VAT to 2 decimals
c1bd507 feat(cart): add coupon flag
28dd5c3 (tag: v1.4.0, release/1.4) feat: first release of the cart
$ git switch release/1.4
Switched to branch 'release/1.4'
$ git cherry-pick -x 32ef04c
[release/1.4 8be521e] fix(cart): round VAT to 2 decimals
 Date: Thu Jan 15 10:03:00 2026 +0600
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git log --oneline --decorate --all --graph
* 8be521e (HEAD -> release/1.4) fix(cart): round VAT to 2 decimals
| * 32ef04c (main) fix(cart): round VAT to 2 decimals
| * c1bd507 feat(cart): add coupon flag
|/
* 28dd5c3 (tag: v1.4.0) feat: first release of the cart
$ git log -1 --format=%B
fix(cart): round VAT to 2 decimals

(cherry picked from commit 32ef04c14a5c155b1a523ea058af9a78a2d5be8c)

$ ls
cart.js
$ git cherry -v main release/1.4
- 8be521e71461bf4a4ae2a00d12d35c747f8efd43 fix(cart): round VAT to 2 decimals
$ git tag -a v1.4.1 -m "v1.4.1"
$ git describe
v1.4.1

কেন কাজ করে: নতুন commit 8be521e একই বদল আর বার্তা বহন করে, কিন্তু parent v1.4.0, তাই ID আলাদা; বার্তার শেষে “(cherry picked from commit 32ef04c…)”. ls-এ coupon.js নেই — feature আসেনি। git cherry -v main release/1.4-এর - চিহ্ন বলে এই বদলের সমতুল্য commit main-এ আগেই আছে (patch-id মিলিয়ে)। শুধু fix, তাই 1.4.0 → 1.4.1.

ফলো-আপ: (ক) “Fix আগে release-এ, পরে main-এ?” — উল্টো ক্রম ঝুঁকিপূর্ণ: পরের release-এ bug ফিরে আসে; “upstream first”. (খ) “Pick-এ conflict?” — আমাদের প্রথম চেষ্টায় সত্যিই হয়েছিল, যখন coupon-এর লাইন cart.js-এর ঠিক পরের লাইনে ছিল — পাশাপাশি লাইনের বদলও conflict ঘটায়; সমাধান, git add, git cherry-pick --continue. (গ) Release branch-এ CI চালানো বাধ্যতামূলক।