Git — শূন্য থেকে এক্সপার্ট

ফরম্যাট: ১৩টা Phase, ৩৯টা Module। প্রতিটা মডিউলে কয়েকটা কনটেন্ট leaf (What/How/Why), তারপর একটা ল্যাব (Do), একটা ইন্টারভিউ-প্রশ্ন leaf (পরীক্ষা), আর একটা কর্নার-কেস leaf।

স্কোপ

Git-এর প্রতিটা পোরসেলিন ও প্লাম্বিং কমান্ড কভার করা হয়েছে — বেসিক commit/push/pull থেকে শুরু করে object model, refs, packfiles, rebase/reflog ইন্টার্নালস, worktree/submodule, hooks, সিকিউরিটি (signing/credentials/secret removal), আর GitHub-স্পেসিফিক ওয়ার্কফ্লো (fork/PR/branch protection/Actions) পর্যন্ত। লক্ষ্য: এই জার্নি শেষ করার পর Git নিয়ে যেন কোনো প্রশ্ন অজানা না থাকে — বিগিনার থেকে প্রোডাকশন-লেভেল ট্রাবলশুটার পর্যন্ত।

মার্কার

⭐ (strength) = হ্যান্ডস-অন ল্যাব। 🔑 (gate) = Phase-শেষের চেকপয়েন্ট — পরের Phase-এ যাওয়ার আগে নিজেকে যাচাই করার জায়গা। শেষ Module 39-এ একটা চূড়ান্ত ক্যাপস্টোন আছে যেখানে পুরো জার্নির সব দক্ষতা একসাথে প্রয়োগ করতে হবে।

Git শেখার আগে বোঝা দরকার এটা কেন এভাবে ডিজাইন করা হয়েছে — এটা শুধু "কমান্ড মুখস্থ করা" বিষয় না, এটা একটা মেন্টাল মডেল। Linus Torvalds ২০০৫ সালে Git বানিয়েছিলেন BitKeeper-এর বিকল্প হিসেবে, আর সেই ডিজাইনের প্রতিটা সিদ্ধান্তের পেছনে একটা যুক্তি আছে: distributed হতে হবে, snapshot-ভিত্তিক হতে হবে, আর দ্রুত হতে হবে। এই Phase-এ দুইটা Module — প্রথমটা ইতিহাস ও তিনটা এলাকার (working directory/staging/repo) মানসিক মডেল তৈরি করবে, দ্বিতীয়টা Git-এর configuration সিস্টেম শেখাবে যা পুরো বইয়ের বাকি অংশে বারবার কাজে লাগবে। এই দুটো মডিউল ছাড়া বাকি সব মডিউল "কেন" প্রশ্নের উত্তর ছাড়াই মুখস্থ কমান্ডের তালিকা হয়ে যাবে।

Git-কে গভীরভাবে বোঝার প্রথম ধাপ হলো এটা কোন সমস্যার সমাধান হিসেবে জন্ম নিয়েছে সেটা বোঝা। এই মডিউলে কভার হবে: centralized বনাম distributed VCS-এর পার্থক্য ও SVN-এর সীমাবদ্ধতা, Git বনাম GitHub/GitLab-এর পার্থক্য (টুল বনাম হোস্টিং সার্ভিস), প্রথম ইনস্টলেশন ও config, working directory/staging area/repository — এই তিনটা এলাকা ও তাদের মধ্যে ডেটা-প্রবাহ, এবং snapshot মডেল কেন delta/diff মডেলের চেয়ে শক্তিশালী।

সমস্যাটা কী ছিল

Git-এর আগে version control মানে ছিল CVS আর SVN (Subversion)-এর মতো centralized VCS (CVCS)। এই মডেলে একটা মাত্র central সার্ভার পুরো প্রজেক্টের ইতিহাস রাখত, আর প্রতিটা ডেভেলপারের মেশিনে থাকত শুধু current snapshot — পুরো ইতিহাস না।

এতে সমস্যা কী হতো

• সিঙ্গেল পয়েন্ট অফ ফেইলিওর — central সার্ভার ডাউন হলে কেউ commit করতে পারত না, এমনকি নিজের লোকাল history দেখতেও পারত না।
• নেটওয়ার্ক নির্ভরতা — svn log, svn diff (পুরনো রিভিশনের সাথে) সব সময় সার্ভারে রাউন্ড-ট্রিপ লাগত। অফলাইনে কাজ প্রায় অসম্ভব।
• Branch করা ছিল ভারী — SVN-এ branch মানে পুরো ডিরেক্টরি সার্ভার-সাইড কপি করা, merge করা ছিল কষ্টকর আর error-prone।

Git-এর সমাধান: Distributed VCS (DVCS)

Git-এ প্রতিটা ক্লোন একটা সম্পূর্ণ রিপোজিটরি — পুরো ইতিহাস, সব branch, সব commit, লোকাল মেশিনে থাকে। কোনো "central" সার্ভার আবশ্যক না — যেকোনো ক্লোনকে "central" হিসেবে ট্রিট করা যায় (এই জন্যই GitHub একটা hosting service মাত্র, Git-এর অংশ না)।

রিয়েল-লাইফ প্রভাব

অফলাইনে ফ্লাইটে বসে পুরো প্রজেক্ট ইতিহাস browse করা, commit করা, branch বানানো — সব সম্ভব, ইন্টারনেট লাগবে শুধু sync (push/pull/fetch) করার সময়। টিমে একজনের মেশিন নষ্ট হলেও যেকোনো clone থেকে পুরো history restore করা যায় — এটাই distributed মডেলের সবচেয়ে বড় ব্যবহারিক সুবিধা।

মনে রাখার শর্টকাট: SVN = একটা লাইব্রেরির একমাত্র বই, সবাই সেটা পড়তে লাইব্রেরিতে যেতে হয়। Git = প্রতিটা পাঠকের কাছে পুরো বইয়ের কপি।

সবচেয়ে সাধারণ কনফিউশন

নতুন ডেভেলপাররা প্রায়ই "Git" আর "GitHub" শব্দ দুটো একই জিনিস মনে করে ব্যবহার করেন। বাস্তবে এরা সম্পূর্ণ ভিন্ন স্তরের জিনিস।

পার্থক্য

Git হলো একটা command-line টুল/প্রোটোকল — আপনার লোকাল মেশিনে ইনস্টল হওয়া সফটওয়্যার, যেটা version control-এর আসল কাজ (commit, branch, merge, history tracking) করে। এটা সম্পূর্ণভাবে ইন্টারনেট বা কোনো নির্দিষ্ট কোম্পানির উপর নির্ভরশীল না।

GitHub, GitLab, Bitbucket হলো hosting service — এরা Git রিপোজিটরি হোস্ট করে ইন্টারনেটে, আর তার উপর অতিরিক্ত ফিচার যোগ করে যেগুলো Git নিজে দেয় না: Pull Request/Merge Request UI, Issue tracker, CI/CD pipeline, code review workflow, access control।

কীভাবে বুঝবেন এই আলাদা স্তরটা

# এটা pure Git — কোনো GitHub লাগে না
git init my-project
git add .
git commit -m "প্রথম কমিট"
git log

# এটা GitHub-নির্দিষ্ট — শুধু তখনই দরকার যখন রিমোট হোস্ট আছে
git remote add origin https://github.com/user/repo.git
git push origin main

উপরের প্রথম চারটা কমান্ড ইন্টারনেট ছাড়াই, GitHub অ্যাকাউন্ট ছাড়াই সম্পূর্ণ কাজ করে। শুধু শেষ দুটো লাইনে "GitHub" প্রাসঙ্গিক হয়।

রিয়েল-লাইফ প্রভাব

একটা কোম্পানি চাইলে GitHub একেবারেই ব্যবহার না করে নিজস্ব সার্ভারে শুধু git init --bare দিয়ে একটা রিপো হোস্ট করতে পারে (self-hosted), অথবা GitLab CE ইনস্টল করে নিজস্ব ইনফ্রাস্ট্রাকচারে চালাতে পারে — Git প্রোটোকল একই থাকে। এই জন্য "GitHub শিখব" আর "Git শিখব" — দুটো ভিন্ন লক্ষ্য, আর এই পুরো জার্নি মূলত দ্বিতীয়টার উপর ফোকাস করে।

Git-এর সবচেয়ে গুরুত্বপূর্ণ মেন্টাল মডেল

Git-এ প্রতিটা ফাইল তিনটা সম্ভাব্য এলাকার একটায় থাকে, আর এই তিনটা এলাকার মধ্যে ডেটার প্রবাহ বোঝাই Git বোঝার মূল ভিত্তি।

ডেটা কীভাবে একটা থেকে আরেকটায় যায়

# working directory-তে একটা ফাইল এডিট করলাম
echo "hello" > app.py

# staging area-য় তোলা হলো (index-এ যোগ হলো)
git add app.py

# repository-তে permanent snapshot হিসেবে সেভ হলো
git commit -m "add app.py"

কেন staging area আলাদা করে রাখা হলো

এটাই Git-কে অনেক পুরনো VCS থেকে আলাদা করে দেয়। staging area থাকার কারণে আপনি একাধিক ফাইল এডিট করেও শুধু নির্দিষ্ট কিছু ফাইল/অংশ commit করতে পারেন — বাকিগুলো working directory-তেই থেকে যায়, পরের commit-এর জন্য অপেক্ষা করে। এটা git add -p দিয়ে আরও গ্র্যানুলার হয় — একই ফাইলের ভেতরের নির্দিষ্ট hunk-ও আলাদা করে stage করা যায়।

রিয়েল-লাইফ উদাহরণ

ধরুন আপনি একসাথে একটা bug fix আর একটা unrelated refactor করে ফেলেছেন একই সেশনে। staging area ব্যবহার করে bug fix-এর ফাইলগুলো আলাদাভাবে git add করে একটা পরিষ্কার, ফোকাসড commit বানানো যায়, refactor-টা আলাদা commit-এ যায় — ইতিহাস পরিষ্কার থাকে, git bisect বা git revert পরে সহজ হয়।

দুই ধরনের VCS ডিজাইন দর্শন

পুরনো VCS (SVN, CVS, Mercurial-এর কিছু অংশ) সাধারণত delta-based storage ব্যবহার করে — প্রতিটা কমিটে শুধু আগের ভার্সনের সাথে পার্থক্যটুকু (diff) সংরক্ষণ করা হয়। পুরো ফাইল পুনর্গঠন করতে হলে শুরু থেকে সব delta ক্রমান্বয়ে apply করতে হয়।

Git সম্পূর্ণ ভিন্ন পথ নেয়: snapshot-based storage। প্রতিটা commit-এ Git পুরো প্রজেক্টের একটা সম্পূর্ণ "ছবি" (snapshot) রাখে — প্রতিটা ফাইলের পূর্ণ কন্টেন্টের রেফারেন্স, ডিফ না।

কীভাবে এটা efficient হয় (স্পয়লার: dedup)

শুনে মনে হতে পারে এটা জায়গা নষ্ট করবে, কিন্তু Git একটা চালাকি করে: যদি একটা ফাইল দুই commit-এর মধ্যে না বদলায়, তাহলে দুই commit-এর tree একই blob hash-কে পয়েন্ট করে — নতুন কপি তৈরি হয় না। শুধু বদলে যাওয়া ফাইলের জন্যই নতুন blob object তৈরি হয় (Phase 2-তে বিস্তারিত)।

# একই কন্টেন্ট = একই hash, তা যতবারই বা যে ফাইলেই থাকুক না কেন
git hash-object README.md
git hash-object docs/copy-of-readme.md   # কন্টেন্ট identical হলে একই hash আসবে

কেন এটা গুরুত্বপূর্ণ

• দ্রুত branch switching — নতুন snapshot বানাতে delta chain apply করার দরকার নেই, শুধু tree pointer বদলে যায়।
• নির্ভরযোগ্য integrity check — প্রতিটা commit স্বয়ংসম্পূর্ণ, তাই history-র কোনো অংশ দুর্নীতিগ্রস্ত (corrupt) হলে সহজে ধরা পড়ে (SHA hash mismatch)।
• merge আর diff computation lazy — Git diff on-demand কম্পিউট করে (দুটো snapshot তুলনা করে), স্টোরেজে diff জমিয়ে রাখে না।

সারসংক্ষেপ টেবিল

ইনস্টলেশন

# Fedora/RHEL
sudo dnf install git

# Debian/Ubuntu
sudo apt install git

# ভার্সন চেক
git --version

প্রথম দুটো config — বাধ্যতামূলক

Git-এর প্রতিটা commit-এ একজন author আর committer থাকে (Phase 2-এ কমিট অবজেক্টের গঠনে বিস্তারিত)। এই তথ্য না দিলে Git commit করতেই দেয় না।

git config --global user.name "Rakib Hasan"
git config --global user.email "rakib@example.com"

এই তথ্য কোথায় সংরক্ষিত হয়

--global ফ্ল্যাগ ব্যবহার করলে এই কনফিগ লেখা হয় ~/.gitconfig ফাইলে, একটা প্লেইন-টেক্সট INI ফরম্যাটে:

[user]
    name = Rakib Hasan
    email = rakib@example.com

এই ফাইলটা যেকোনো টেক্সট এডিটর দিয়ে সরাসরি এডিট করা যায় — git config কমান্ড আসলে শুধু এই ফাইল ম্যানিপুলেট করার একটা সুবিধাজনক CLI wrapper।

যাচাই করা

git config --global --list
# user.name=Rakib Hasan
# user.email=rakib@example.com

রিয়েল-লাইফ সমস্যা যা এটা এড়ায়

কোম্পানির টিমে commit history দেখে বোঝা যায় কে কোন কোড লিখেছে (git blame, git log --author)। ভুল email দিলে GitHub-এ commit আপনার প্রোফাইলের সাথে link হবে না (attribution ভেঙে যাবে) — এই জন্য প্রজেক্ট-নির্দিষ্ট email আলাদা রাখার দরকার হয়, যেটা পরের মডিউলে includeIf দিয়ে সমাধান করা হবে।

লক্ষ্য

একটা নতুন Git রিপো বানিয়ে .git ফোল্ডারের ভেতরের গঠন হাতে-কলমে দেখা — যেটা Phase 2-তে গভীরভাবে ব্যাখ্যা হবে, এখানে শুধু প্রাথমিক পরিচয়।

ধাপ ১ — রিপো তৈরি

mkdir git-lab-01 && cd git-lab-01
git init

আউটপুট: Initialized empty Git repository in /path/git-lab-01/.git/

ধাপ ২ — .git এক্সপ্লোর করা

ls -la .git

দেখবেন এরকম কিছু এন্ট্রি:

HEAD          config        description   hooks/
info/         objects/      refs/

ধাপ ৩ — প্রতিটার সংক্ষিপ্ত পরিচয়

cat .git/HEAD
# ref: refs/heads/main   ← HEAD একটা branch-কে পয়েন্ট করছে

cat .git/config
# [core] section — এই রিপোর লোকাল কনফিগারেশন

ls .git/refs
# heads/  tags/   ← এখনো খালি, কারণ কোনো commit হয়নি

ধাপ ৪ — objects/ ফোল্ডার এখনো খালি কেন

find .git/objects -type f
# কিছুই আসবে না

কারণ এখনো কোনো git add বা git commit হয়নি — কোনো object তৈরি হয়নি। এটা প্রমাণ করে যে Git ফাইল ট্র্যাক শুরু করে শুধু আপনি explicitly add করলেই।

ধাপ ৫ — একটা ফাইল add করে পার্থক্য দেখা

echo "# আমার প্রথম প্রজেক্ট" > README.md
git add README.md
find .git/objects -type f

এবার একটা নতুন ফাইল দেখা যাবে .git/objects/xx/yyyy... প্যাটার্নে — এটাই আপনার প্রথম blob object, Phase 2-এ যেটা নিয়ে বিস্তারিত আলোচনা হবে।

চ্যালেঞ্জ

git init --bare test.git চালিয়ে দেখুন --bare রিপোতে working directory না থাকায় গঠন কীভাবে ভিন্ন (কোনো working tree ফাইল নেই, .git-এর কন্টেন্ট সরাসরি রুটে থাকে)।

প্র.১ — Git-কে "distributed" VCS বলা হয় কেন? উত্তর: কারণ প্রতিটা ক্লোনে পুরো প্রজেক্টের সম্পূর্ণ ইতিহাস থাকে, কোনো central সার্ভারের প্রয়োজন নেই। SVN-এর মতো centralized VCS-এ শুধু সার্ভারে পূর্ণ history থাকে, ক্লায়েন্টে শুধু current snapshot।

প্র.২ — Git আর GitHub-এর মধ্যে পার্থক্য কী? উত্তর: Git একটা version control টুল/প্রোটোকল যা লোকালি চলে ও ইন্টারনেট ছাড়াই কাজ করে। GitHub একটা hosting service যা Git রিপো হোস্ট করে এবং অতিরিক্ত ফিচার (PR, Issue, CI/CD) যোগ করে। Git ছাড়া GitHub অচল, কিন্তু GitHub ছাড়া Git পুরোপুরি চলে।

প্র.৩ — Working directory, staging area, আর repository — এই তিনটার পার্থক্য কী? উত্তর: Working directory হলো ডিস্কে আপনার এডিটেবল ফাইল। Staging area (index) হলো পরের commit-এ কী যাবে তার প্রস্তাব। Repository (.git) হলো permanent commit history। git add staging-এ তোলে, git commit সেটাকে repository-তে স্থায়ী করে।

প্র.৪ — Git snapshot-based স্টোরেজ ব্যবহার করে, তবু কীভাবে জায়গা বাঁচায়? উত্তর: প্রতিটা commit-এ প্রতিটা ফাইলের সম্পূর্ণ snapshot রাখা হয়, কিন্তু যদি একটা ফাইল দুই commit-এর মধ্যে অপরিবর্তিত থাকে, তাহলে দুটো commit-এর tree একই blob object-কে reference করে — নতুন কপি বানায় না (content-addressable storage-এর মাধ্যমে dedup)।

প্র.৫ — git config কমান্ড কোন ফাইল ম্যানিপুলেট করে? উত্তর: --global ফ্ল্যাগ দিলে ~/.gitconfig, --local (ডিফল্ট) দিলে .git/config, --system দিলে সিস্টেম-ওয়াইড config ফাইল — এগুলো সবই প্লেইন-টেক্সট INI ফরম্যাট, git config আসলে একটা CLI wrapper মাত্র।

প্র.৬ — SVN-এর তুলনায় Git-এ branch করা সহজ কেন? উত্তর: SVN-এ branch মানে সার্ভার-সাইড পুরো ডিরেক্টরি কপি করা (ভারী অপারেশন)। Git-এ branch মানে শুধু একটা ৪১-বাইট টেক্সট ফাইল (একটা commit hash ধরে রাখা ref) তৈরি করা — তাৎক্ষণিক ও সস্তা অপারেশন।

• **git config ছাড়া commit করার চেষ্টা করলে Git আপনাকে আটকাবে না চিরতরে — বরং প্রথমবার একটা fallback identity (hostname-ভিত্তিক) ব্যবহার করে warning দেবে, অনেক নতুন ইউজার সেই warning উপেক্ষা করে ভুল author info নিয়ে commit করে ফেলেন। সবসময় প্রথম কাজ হিসেবে user.name/user.email সেট করা উচিত।

• .git ফোল্ডার ডিলিট করলে পুরো ইতিহাস চিরতরে হারিয়ে যায়, কিন্তু working directory-র ফাইল অক্ষত থাকে — অনেকে ভাবেন .git ডিলিট করলে সব ফাইল মুছে যাবে, বাস্তবে শুধু ভার্সন-হিস্ট্রি মুছে যায়, বর্তমান ফাইলগুলো একদম প্লেইন ফোল্ডার হিসেবে থেকে যায়।

• --bare রিপোতে সরাসরি ফাইল এডিট বা git add করা যায় না — কারণ এতে কোনো working directory নেই, শুধু .git-এর ভেতরের কন্টেন্ট। এগুলো শুধু push/pull-এর জন্য central hosting point হিসেবে ব্যবহার করার জন্য ডিজাইন করা, ডেভেলপমেন্টের জন্য না।

• Windows-এ ইনস্টল করা Git for Windows-এর core.autocrlf ডিফল্ট আচরণ Linux/Mac থেকে আলাদা — line-ending কনভার্সন নিয়ে cross-platform টিমে প্রথম দিকেই বিভ্রান্তি তৈরি করে (একই ফাইলে অকারণ পুরো-ফাইল diff দেখা যায়), যেটা .gitattributes দিয়ে সমাধান করতে হয়।

Git-এর configuration সিস্টেম একটা layered মডেল অনুসরণ করে — system, global, local, আর worktree, প্রতিটার নিজস্ব precedence। এই মডিউলে কভার হবে: চার লেভেলের precedence, git config কমান্ডের বিভিন্ন ফ্ল্যাগ (--list --show-origin, --get, --get-regexp, --unset, --edit), গুরুত্বপূর্ণ config key (core.editor, init.defaultBranch, pull.rebase, push.default), includeIf দিয়ে কনটেক্সট-ভিত্তিক কনফিগারেশন, গ্লোবাল .gitignore, আর git help/man git-<command> কীভাবে ব্যবহার করবেন।

চারটা লেভেল

Git কনফিগারেশন চারটা ফাইলে ছড়িয়ে থাকতে পারে, প্রতিটা ভিন্ন স্কোপে:

Precedence — কোনটা জেতে

Specificity বেশি যার, সে জেতে: worktree > local > global > system। অর্থাৎ একই key (যেমন user.email) যদি global আর local — দুই জায়গাতেই সেট থাকে, তাহলে local জিতবে সেই নির্দিষ্ট রিপোর জন্য।

# গ্লোবালি পার্সোনাল ইমেইল
git config --global user.email "personal@gmail.com"

# শুধু এই রিপোর জন্য কোম্পানির ইমেইল (local জিতবে)
cd ~/work/company-project
git config --local user.email "rakib@company.com"

কেন এই লেয়ারিং দরকার

এটা একই সাথে কনভেনিয়েন্স (global-এ একবার সেট করলেই সব রিপোতে কাজ করে) আর ফ্লেক্সিবিলিটি (যেকোনো নির্দিষ্ট রিপোর জন্য override করা যায়) দেয়। System-level কনফিগ সাধারণত sysadmin ব্যবহার করে shared মেশিনে সব ইউজারের জন্য default policy সেট করতে (যেমন core.autocrlf)।

রিয়েল-লাইফ উদাহরণ

একজন ফ্রিল্যান্স ডেভেলপার হিসেবে আপনার গ্লোবাল ইমেইল পার্সোনাল, কিন্তু ~/work/ এর ভেতরের প্রতিটা রিপোতে কোম্পানির ইমেইল ব্যবহার করতে চান — প্রতিটা রিপোতে ম্যানুয়ালি --local সেট করা ঝামেলার, এর জন্য includeIf (এই মডিউলেই পরে) স্বয়ংক্রিয় সমাধান দেয়।

কোন config কোথা থেকে এলো, তা দেখা

একাধিক লেভেলে config ছড়িয়ে থাকলে confusion হতেই পারে — কোন value আসলে effective, আর সেটা কোন ফাইল থেকে এসেছে।

git config --list --show-origin
# file:/home/rakib/.gitconfig    user.name=Rakib Hasan
# file:.git/config               user.email=rakib@company.com

এখানে user.email local ফাইল থেকে এসেছে বোঝা যাচ্ছে সরাসরি — precedence-জনিত কনফিউশন দূর করতে এটাই সবচেয়ে দ্রুত ডায়াগনস্টিক কমান্ড।

নির্দিষ্ট একটা key পড়া

git config --get user.email
# rakib@company.com   (effective value — সবচেয়ে specific লেভেল থেকে)

Pattern দিয়ে একাধিক key খোঁজা

git config --get-regexp "^user\."
# user.name Rakib Hasan
# user.email rakib@company.com

এটা কাজে লাগে যখন একটা প্রিফিক্স (যেমন সব alias.* বা url.*) দিয়ে সব সেটিং একসাথে দেখতে চান।

একটা key মুছে ফেলা

git config --unset core.editor
# --local (ডিফল্ট স্কোপ) থেকে মুছবে; --global দিলে global থেকে

সরাসরি এডিটরে config ফাইল খোলা

git config --global --edit
# core.editor-এ সেট করা এডিটরে ~/.gitconfig খুলবে

রিয়েল-লাইফ ব্যবহার

একটা CI স্ক্রিপ্টে যদি অদ্ভুত user.email দিয়ে commit হচ্ছে দেখেন, প্রথম ডায়াগনস্টিক ধাপ হওয়া উচিত git config --list --show-origin | grep email — এটা সাথে সাথে বলে দেবে কোন লেভেলের কনফিগ culprit।

চারটা key যা প্রতিদিনের ওয়ার্কফ্লো বদলে দেয়

core.editor

Commit message লেখার সময় (যখন -m ফ্ল্যাগ দেননি) Git একটা এডিটর খোলে। ডিফল্ট প্রায়ই vi/vim, যা নতুনদের আটকে ফেলে (:wq না জানলে বের হতেই পারবে না)।

git config --global core.editor "nano"
# বা VS Code:
git config --global core.editor "code --wait"

init.defaultBranch

পুরনো Git ভার্সনে নতুন রিপোর ডিফল্ট branch নাম ছিল master। আধুনিক প্র্যাক্টিসে main প্রেফার করা হয়।

git config --global init.defaultBranch main

pull.rebase

git pull আসলে git fetch + merge (অথবা rebase) — এই বিহেভিয়ার নিয়ন্ত্রণ করে এই key।

git config --global pull.rebase true

push.default

git push (কোনো আর্গুমেন্ট ছাড়া) কী করবে তা নিয়ন্ত্রণ করে।

git config --global push.default simple
# simple = শুধু current branch-কে একই নামের upstream branch-এ push করে (আধুনিক ডিফল্ট)

রিয়েল-লাইফ প্রভাব

একটা টিমে সবাই pull.rebase = true সেট না করলে কিছু ডেভেলপারের history-তে অহেতুক merge commit ("Merge branch 'main' of ...") জমতে থাকে, যা git log --graph কে অগোছালো করে তোলে — এই একটামাত্র কনফিগ পুরো টিমের history-র "পরিচ্ছন্নতা" নির্ধারণ করে দেয়।

সমস্যা: একই মেশিনে একাধিক পরিচয়

ধরুন আপনার পার্সোনাল প্রজেক্ট আর কোম্পানির প্রজেক্ট একই মেশিনে, কিন্তু commit-এ ভিন্ন ইমেইল ব্যবহার করতে চান — প্রতিটা রিপোতে ম্যানুয়ালি --local সেট করা ভুলে যাওয়ার সম্ভাবনা থাকে।

সমাধান: includeIf

~/.gitconfig-এ একটা conditional include যোগ করুন যা পাথের উপর ভিত্তি করে অন্য একটা config ফাইল লোড করে:

# ~/.gitconfig
[user]
    name = Rakib Hasan
    email = personal@gmail.com

[includeIf "gitdir:~/work/"]
    path = ~/.gitconfig-work

# ~/.gitconfig-work
[user]
    email = rakib@company.com

এখন ~/work/ পাথের ভেতরের যেকোনো রিপোতে স্বয়ংক্রিয়ভাবে কোম্পানির ইমেইল ব্যবহার হবে, বাকি জায়গায় পার্সোনাল ইমেইল — কোনো ম্যানুয়াল স্টেপ ছাড়াই।

যাচাই

cd ~/work/company-project
git config user.email
# rakib@company.com

cd ~/personal-project
git config user.email
# personal@gmail.com

গ্লোবাল .gitignore

প্রতিটা রিপোতে আলাদা .gitignore-এ .DS_Store, *.swp, IDE ফোল্ডার (.vscode/, .idea/) যোগ করা বিরক্তিকর — এগুলো একবার গ্লোবালি সেট করা যায়:

git config --global core.excludesFile ~/.gitignore_global
echo ".DS_Store" >> ~/.gitignore_global
echo "*.swp" >> ~/.gitignore_global

এই এন্ট্রিগুলো কোনো রিপোর .gitignore-এ কমিট হয় না — এটা সম্পূর্ণ লোকাল, পার্সোনাল-প্রেফারেন্স-লেভেলের ইগনোর নিয়ম, টিমের বাকিদের সাথে শেয়ার হয় না।

Git-এর built-in ডকুমেন্টেশন

প্রতিটা Git সাব-কমান্ডের জন্য একটা সম্পূর্ণ man-page-স্টাইল ডকুমেন্টেশন বিল্ট-ইন আছে — অনলাইনে সার্চ করার আগে এটাই প্রথম রিসোর্স হওয়া উচিত।

git help commit
# অথবা সমতুল্য:
man git-commit

দুটোই একই ডকুমেন্টেশন খোলে — git help <cmd> আসলে ভেতরে man git-<cmd> (বা কনফিগার করা অন্য ভিউয়ার) কল করে।

দ্রুত রেফারেন্সের জন্য শর্ট ভার্সন

git commit -h
# শুধু ফ্ল্যাগগুলোর সংক্ষিপ্ত তালিকা, পুরো man page না

সব উপলব্ধ কমান্ডের তালিকা

git help -a
# porcelain (দৈনন্দিন) ও plumbing (লো-লেভেল) — দুই ধরনের কমান্ডই লিস্ট হয়

Guide-স্টাইল ডকুমেন্টেশন

Git-এ কমান্ড-নির্দিষ্ট না এমন কিছু concept guide-ও আছে:

git help gitignore     # .gitignore প্যাটার্ন সিনট্যাক্স
git help gitattributes # .gitattributes সিনট্যাক্স
git help revisions     # HEAD~2, HEAD^, branch@{upstream} ইত্যাদি রেফারেন্স সিনট্যাক্স

কেন এটা গুরুত্বপূর্ণ

Stack Overflow-এর অনেক পুরনো উত্তর ভুল বা deprecated flag সাজেস্ট করে। git help <cmd> সবসময় আপনার লোকালি ইনস্টল করা এক্স্যাক্ট ভার্সনের সাথে ম্যাচ করা ডকুমেন্টেশন দেখায় — git --version চেক করে নিশ্চিত হওয়া যায় কোন ভার্সনের ডক পড়ছেন।

রিয়েল-লাইফ অভ্যাস

একটা নতুন ফ্ল্যাগ বা কমান্ড শেখার সময় git help <cmd> চালিয়ে EXAMPLES সেকশন খুঁজে পড়া — প্রায় প্রতিটা man page-এর শেষে রিয়েল-ওয়ার্ল্ড উদাহরণ থাকে যা ব্লগ পোস্টের চেয়ে বেশি নির্ভরযোগ্য, কারণ এটা সরাসরি Git মেইনটেইনারদের লেখা।

লক্ষ্য

includeIf ব্যবহার করে দুটো ভিন্ন ফোল্ডারে দুটো ভিন্ন Git identity স্বয়ংক্রিয়ভাবে কাজ করানো, ও তা যাচাই করা।

ধাপ ১ — ফোল্ডার স্ট্রাকচার তৈরি

mkdir -p ~/gitlab-test/work ~/gitlab-test/personal

ধাপ ২ — গ্লোবাল (পার্সোনাল) identity সেট করা

git config --global user.name "Rakib Hasan"
git config --global user.email "personal@gmail.com"

ধাপ ৩ — work-নির্দিষ্ট config ফাইল বানানো

cat > ~/.gitconfig-work << 'EOF'
[user]
    email = rakib@company.com
EOF

ধাপ ৪ — includeIf যোগ করা

git config --global --edit

এডিটরে নিচের ব্লক যোগ করুন (পাথ absolute হতে হবে, শেষে / বাধ্যতামূলক):

[includeIf "gitdir:~/gitlab-test/work/"]
    path = ~/.gitconfig-work

ধাপ ৫ — যাচাই

cd ~/gitlab-test/work
git init sub-project && cd sub-project
git config user.email
# আশা করা আউটপুট: rakib@company.com

cd ~/gitlab-test/personal
git init sub-project2 && cd sub-project2
git config user.email
# আশা করা আউটপুট: personal@gmail.com

ধাপ ৬ — একটা টেস্ট commit করে প্রমাণ করা

cd ~/gitlab-test/work/sub-project
touch test.txt && git add test.txt
git commit -m "test commit"
git log --format="%an <%ae>"
# Rakib Hasan <rakib@company.com>

চ্যালেঞ্জ

gitdir: এর বদলে gitdir/i: ব্যবহার করে দেখুন (case-insensitive matching) — Windows-এর মতো case-insensitive ফাইলসিস্টেমে এটা কখন দরকার হতে পারে ভাবুন।

প্র.১ — Git config-এর চারটা লেভেলের precedence অর্ডার কী? উত্তর: worktree > local > global > system। সবচেয়ে specific স্কোপ (worktree) সবার আগে জেতে, সবচেয়ে সাধারণ (system) সবার শেষে প্রযোজ্য হয় যদি অন্য কোথাও override না থাকে।

প্র.২ — একটা config value কোন ফাইল থেকে এসেছে তা কীভাবে বের করবেন? উত্তর: git config --list --show-origin চালিয়ে — এটা প্রতিটা key-value-এর পাশে ঠিক কোন ফাইল থেকে সেটা এসেছে তা দেখায়, যা precedence-জনিত confusion দ্রুত সমাধানে সাহায্য করে।

প্র.৩ — pull.rebase কনফিগারেশন কী নিয়ন্ত্রণ করে, এবং true সেট করলে কী পরিবর্তন হয়? উত্তর: এটা নিয়ন্ত্রণ করে git pull fetch-এর পর merge করবে নাকি rebase করবে। true সেট করলে merge commit তৈরি না হয়ে local commit গুলো remote-এর উপরে rebase হয়, ফলে history লিনিয়ার থাকে।

প্র.৪ — একজন ফ্রিল্যান্সার একই মেশিনে দুইটা ইমেইল (পার্সোনাল ও কোম্পানি) ব্যবহার করতে চান, প্রতিটা রিপোতে ম্যানুয়ালি সেট না করে। কীভাবে সমাধান করবেন? উত্তর: ~/.gitconfig-এ includeIf "gitdir:<path>/" ব্লক ব্যবহার করে একটা নির্দিষ্ট ফোল্ডারের জন্য আলাদা config ফাইল include করে, যেখানে ভিন্ন user.email সেট থাকবে — এটা পাথের ভিত্তিতে স্বয়ংক্রিয়ভাবে কাজ করে।

প্র.৫ — গ্লোবাল .gitignore (core.excludesFile) আর প্রজেক্ট-লোকাল .gitignore-এর মধ্যে পার্থক্য কী? উত্তর: গ্লোবাল .gitignore সম্পূর্ণ লোকাল, পার্সোনাল প্রেফারেন্স (যেমন .DS_Store, IDE ফোল্ডার), কমিট হয় না, টিমের সাথে শেয়ার হয় না। প্রজেক্ট-লোকাল .gitignore রিপোর ভেতরে কমিট হয়, পুরো টিম শেয়ার করে (যেমন node_modules/, .env)।

প্র.৬ — git help commit আর git commit -h-এর পার্থক্য কী? উত্তর: git help commit (= man git-commit) পূর্ণ ডকুমেন্টেশন, উদাহরণসহ, দেখায়। git commit -h শুধু ফ্ল্যাগগুলোর সংক্ষিপ্ত usage তালিকা দেখায়, দ্রুত রেফারেন্সের জন্য।

• includeIf "gitdir:" পাথে ট্রেইলিং স্ল্যাশ (/) বাদ দিলে ম্যাচ নাও হতে পারে — gitdir:~/work (স্ল্যাশ ছাড়া) সবসময় ঠিকভাবে prefix-match নাও করতে পারে; সঠিক ফরম্যাট সবসময় gitdir:~/work/।

• git config --unset একটা key-এর একাধিক ভ্যালু থাকলে (যেমন multi-value key) error দেয়, চুপচাপ প্রথমটা মুছে ফেলে না — সেক্ষেত্রে --unset-all ব্যবহার করতে হয়, নাহলে "warning: has multiple values" এরর আসবে।

• --local config সেট করার আগে রিপোর ভেতরে থাকতে হবে, নাহলে "error: could not lock config file" — .git/config ফাইল অস্তিত্বহীন কোনো ডিরেক্টরিতে --local চালানো ব্যর্থ হবে, এটা --global/--system-এর থেকে ভিন্ন যা যেকোনো জায়গা থেকে চালানো যায়।

• core.editor সেট না থাকলে Git $EDITOR/$VISUAL এনভায়রনমেন্ট ভ্যারিয়েবল দেখে, তারপরও কিছু না পেলে সিস্টেম ডিফল্ট (vi) ব্যবহার করে — অনেকে core.editor সেট না করেও অভিযোগ করেন "Git ভুল এডিটর খুলছে", আসলে সমস্যা $EDITOR এনভায়রনমেন্ট ভ্যারিয়েবলে।

Phase 0-এ মেন্টাল মডেল আর কনফিগারেশন তৈরি হয়েছে, এখন দৈনন্দিন Git ব্যবহারের তিনটা মূল স্তম্ভে যাওয়ার পালা: রিপো তৈরি/ক্লোন করা, staging area ম্যানেজ করা, আর commit করা। এই Phase শেষ হলে একজন ডেভেলপার একা একটা প্রজেক্টে সম্পূর্ণ স্বাচ্ছন্দ্যে দৈনন্দিন কাজ (edit → stage → commit) করতে পারবেন — branching/merging এখনো আসেনি, সেটা পরের ফেজে। তিনটা মডিউল: Module 3 (init/clone), Module 4 (staging — status/add/diff/restore/rm/mv), Module 5 (commit — message, amend, ফ্ল্যাগ)।

এই মডিউলে কভার হবে git init (normal ও --bare, --initial-branch=), git clone (প্লেইন, নির্দিষ্ট ফোল্ডারে, --branch, --single-branch), আর shallow clone (--depth)-এর প্রাথমিক পরিচিতি — একটা রিপো "শুরু করার" সব সম্ভাব্য পথ।

কী করে

git init একটা বিদ্যমান ডিরেক্টরিকে Git রিপোজিটরিতে রূপান্তর করে — নতুন প্রজেক্ট শুরু করার সবচেয়ে সাধারণ পথ।

mkdir my-app && cd my-app
git init

ভেতরে কী ঘটে

Git একটা .git/ সাব-ডিরেক্টরি তৈরি করে যার ভেতরে থাকে খালি objects/, refs/heads/, refs/tags/, একটা HEAD ফাইল (ref: refs/heads/main কনটেন্ট সহ — এখনো কোনো branch বাস্তবে তৈরি হয়নি, শুধু HEAD একটা ভবিষ্যৎ branch-কে পয়েন্ট করছে), আর একটা ডিফল্ট config ফাইল। এই মুহূর্তে কোনো commit নেই, তাই refs/heads/main ফাইলটাও এখনো অস্তিত্বহীন — প্রথম commit না হওয়া পর্যন্ত।

init.defaultBranch প্রভাব

git config --global init.defaultBranch main
git init
git branch --show-current
# main

আগে সেট না থাকলে পুরনো Git ভার্সনে ডিফল্ট ছিল master।

বিদ্যমান প্রজেক্টে init

cd existing-project
git init
# ইতিমধ্যে থাকা সব ফাইল working directory-তে থেকে যায়, কিন্তু কিছুই ট্র্যাক করা হয়নি এখনো — সব untracked দেখাবে `git status`-এ

রিয়েল-লাইফ দৃশ্যপট

একটা লিগ্যাসি প্রজেক্ট যেটা কখনো version control-এ ছিল না, তাতে git init চালিয়ে, তারপর .gitignore লিখে, তারপর git add -A && git commit -m "initial import" করলে পুরো প্রজেক্টের ইতিহাস ট্র্যাকিং শুরু হয় — এটাই সবচেয়ে সাধারণ "onboarding" মুহূর্ত।

--bare কী

একটা normal রিপোতে working directory + .git — দুটোই থাকে। একটা bare রিপোতে শুধু .git-এর কন্টেন্টটাই থাকে, সরাসরি রুট লেভেলে — কোনো working directory নেই, কোনো checkout করা ফাইল নেই।

git init --bare project.git
ls project.git
# HEAD  config  description  hooks/  info/  objects/  refs/

কেন bare দরকার

Bare রিপো কখনো সরাসরি এডিট করার জন্য না — এটা শুধু push/pull করার জন্য একটা কেন্দ্রীয় বিনিময়-বিন্দু (exchange point) হিসেবে ডিজাইন করা। GitHub/GitLab-এর সার্ভারে থাকা প্রতিটা রিপো আসলে একটা bare রিপো।

# সার্ভারে (bare)
git init --bare /srv/git/project.git

# ডেভেলপার মেশিনে (non-bare)
git clone user@server:/srv/git/project.git

--initial-branch= দিয়ে branch নাম নির্দিষ্ট করা

git init --initial-branch=trunk my-repo
git -C my-repo branch --show-current
# trunk

এটা init.defaultBranch config-এর চেয়ে বেশি priority পায় (এক্সপ্লিসিট ফ্ল্যাগ সবসময় config override করে) — একবারের জন্য ভিন্ন নাম দরকার হলে কাজে লাগে।

bare vs non-bare — সারসংক্ষেপ

রিয়েল-লাইফ দৃশ্যপট

নিজস্ব প্রাইভেট Git সার্ভার সেটআপ করতে চাইলে (GitHub ছাড়া) একটা VPS-এ git init --bare /srv/git/myproject.git চালিয়ে, তারপর SSH দিয়ে সেই পাথ থেকে clone করা যায় — এটাই সবচেয়ে সহজ self-hosted Git সার্ভার।

clone কী করে

git clone একটা বিদ্যমান রিপোর সম্পূর্ণ কপি (পুরো history, সব branch/tag by default) লোকাল মেশিনে ডাউনলোড করে, স্বয়ংক্রিয়ভাবে একটা origin নামের remote সেট করে দেয়।

git clone https://github.com/user/project.git
# 'project' নামের ফোল্ডার তৈরি হবে (URL থেকে অনুমান করা নাম)

নির্দিষ্ট ফোল্ডার নামে ক্লোন

git clone https://github.com/user/project.git my-local-name

--branch দিয়ে নির্দিষ্ট branch/tag চেকআউট করা

ডিফল্টে remote-এর default branch (সাধারণত main) checkout হয়। ভিন্ন branch দরকার হলে:

git clone --branch develop https://github.com/user/project.git
# clone-এর পরপরই 'develop' branch checked out অবস্থায় থাকবে

--single-branch — শুধু একটা branch-এর history আনা

ডিফল্টে clone সব branch-এর ref আনে (যদিও শুধু একটা checkout করা থাকে)। বড় রিপোতে অপ্রয়োজনীয় ডেটা এড়াতে:

git clone --single-branch --branch develop https://github.com/user/project.git
# শুধু 'develop' branch-এর history আসবে, অন্য branch-এর ref/objects আসবে না

ভেতরে কী ঘটে

Clone আসলে তিনটা কাজ একসাথে করে: (১) পুরো .git অবজেক্ট ডেটাবেজ ডাউনলোড করে (Phase 2-এ যেটা বিস্তারিত হবে), (২) refs/remotes/origin/* তৈরি করে প্রতিটা রিমোট branch ট্র্যাক করার জন্য, (৩) working directory-তে ডিফল্ট branch-এর ফাইলগুলো checkout করে।

রিয়েল-লাইফ দৃশ্যপট

একটা বিশাল মনোরেপো (কয়েক GB history) থেকে শুধু একটা feature branch নিয়ে কাজ করতে চাইলে --single-branch --branch feature/payment দিয়ে ডাউনলোড সময় ও ডিস্ক স্পেস — দুটোই উল্লেখযোগ্যভাবে কমানো যায়।

সমস্যা

কিছু রিপোতে বছরের পর বছরের history — লক্ষ লক্ষ commit, বিশাল object database। শুধু বর্তমান কোড দরকার হলে, পুরো history ডাউনলোড করা অপচয়।

সমাধান: --depth

git clone --depth 1 https://github.com/torvalds/linux.git

এটা শুধু সর্বশেষ ১টা commit (এবং তার সাথে সংশ্লিষ্ট tree/blob object) ডাউনলোড করে — পুরো ইতিহাস না। ফলাফল: অনেক দ্রুত clone, অনেক কম ডিস্ক স্পেস।

ট্রেড-অফ

git log
# fatal: your current branch 'main' does not have any commits yet
# (বা মাত্র ১টা commit দেখাবে — বাকি history নেই)

Shallow clone-এ git log পুরনো commit দেখাতে পারবে না, git blame সীমিত হয়ে যায়, আর branch/tag operation-এ (push করার চেষ্টা) সমস্যা হতে পারে কারণ history-র সংযোগ (parent chain) অসম্পূর্ণ।

কোথায় ব্যবহার হয়

• CI/CD pipeline — বিল্ড/টেস্টের জন্য শুধু সর্বশেষ কোড দরকার, পুরো history অপ্রয়োজনীয়। প্রায় সব CI টুল (GitHub Actions, GitLab CI) ডিফল্টে shallow clone ব্যবহার করে।
• Docker image বিল্ড — image সাইজ ছোট রাখতে।

পরে বিস্তারিত

Shallow clone-কে পরে গভীর করা যায় (git fetch --unshallow), আর এর সাথে --depth-এর পুরো ব্যাকগ্রাউন্ড মেকানিজম, .git/shallow ফাইল, আর কীভাবে এটা partial clone (--filter=blob:none)-এর সাথে সম্পর্কিত — এসব পরবর্তী ফেজে (networking/remotes) বিস্তারিতভাবে কভার হবে। এখানে শুধু concept-টা পরিচিত করানোই লক্ষ্য।

এক লাইনে

Shallow clone = "আমাকে শুধু বর্তমান অবস্থা দাও, পুরো ইতিহাস না" — গতি ও স্পেসের বিনিময়ে history-নির্ভর অপারেশন ত্যাগ করা।

লক্ষ্য

একটা লোকাল bare "সার্ভার" রিপো বানিয়ে, সেটাকে normal ও shallow — দুইভাবে ক্লোন করে পার্থক্য দেখা (কোনো GitHub লাগবে না, সম্পূর্ণ লোকাল)।

ধাপ ১ — একটা "সার্ভার" রিপো বানানো (bare)

mkdir -p ~/gitlab-03/server && cd ~/gitlab-03/server
git init --bare project.git

ধাপ ২ — একটা ডেভেলপার কপি বানিয়ে কিছু commit করা

cd ~/gitlab-03
git clone server/project.git dev-copy
cd dev-copy
for i in 1 2 3 4 5; do
  echo "line $i" >> notes.txt
  git add notes.txt
  git commit -m "add line $i"
done
git push origin main

ধাপ ৩ — সাধারণ ক্লোন

cd ~/gitlab-03
git clone server/project.git full-clone
cd full-clone && git log --oneline
# ৫টা commit-ই দেখা যাবে

ধাপ ৪ — shallow clone দিয়ে পার্থক্য দেখা

cd ~/gitlab-03
git clone --depth 1 server/project.git shallow-clone
cd shallow-clone && git log --oneline
# শুধু সর্বশেষ ১টা commit দেখাবে ("add line 5")

ধাপ ৫ — shallow ক্লোনে পুরনো history নেই তা যাচাই

git log --oneline --all
# একইভাবে মাত্র ১টা commit — বাকি ৪টা আনা হয়নি
cat .git/shallow
# সেই boundary commit-এর hash দেখাবে

ধাপ ৬ — --single-branch টেস্ট

cd ~/gitlab-03/dev-copy
git checkout -b experimental
git push origin experimental

cd ~/gitlab-03
git clone --single-branch --branch main server/project.git single-branch-clone
cd single-branch-clone
git branch -a
# শুধু main-ই দেখাবে, experimental দেখাবে না

চ্যালেঞ্জ

git -C shallow-clone fetch --unshallow চালিয়ে shallow ক্লোনকে পূর্ণ history-তে রূপান্তর করুন, তারপর git log --oneline চালিয়ে যাচাই করুন সব ৫টা commit এসেছে কিনা।

প্র.১ — git init চালানোর সাথে সাথেই কি একটা commit তৈরি হয়ে যায়? উত্তর: না। git init শুধু .git/ ডিরেক্টরি স্ট্রাকচার (খালি objects/, refs/heads/, refs/tags/, HEAD ফাইল) তৈরি করে। HEAD একটা ভবিষ্যৎ branch-কে পয়েন্ট করে থাকে, কিন্তু সেই branch ref আসলে অস্তিত্বহীন থাকে প্রথম commit না হওয়া পর্যন্ত।

প্র.২ — Bare রিপো আর normal রিপোর মধ্যে পার্থক্য কী, এবং GitHub-এর সার্ভারে কোনটা থাকে? উত্তর: Bare রিপোতে কোনো working directory নেই, শুধু .git-এর কন্টেন্ট সরাসরি রুটে থাকে — সরাসরি এডিট করা যায় না, শুধু push/pull-এর exchange point হিসেবে কাজ করে। GitHub/GitLab-এর সার্ভারে থাকা প্রতিটা রিপো একটা bare রিপো।

প্র.৩ — git clone চালালে কয়টা কাজ ভেতরে ভেতরে ঘটে? উত্তর: তিনটা — (১) সম্পূর্ণ object database ডাউনলোড, (২) প্রতিটা remote branch-এর জন্য refs/remotes/origin/* তৈরি, (৩) ডিফল্ট branch-এর ফাইল working directory-তে checkout। পাশাপাশি একটা origin নামের remote স্বয়ংক্রিয়ভাবে সেট হয়।

প্র.৪ — --single-branch কখন ব্যবহার করবেন? উত্তর: যখন একটা বড় মাল্টি-branch রিপোর শুধু একটা নির্দিষ্ট branch (যেমন একটা feature branch) নিয়ে কাজ করতে চান এবং বাকি branch-এর history/objects অপ্রয়োজনীয় — এটা ডাউনলোড সময় ও ডিস্ক স্পেস কমায়।

প্র.৫ — Shallow clone (--depth 1)-এর প্রধান ট্রেড-অফ কী? উত্তর: দ্রুত clone ও কম ডিস্ক স্পেসের বিনিময়ে পুরনো commit history অনুপস্থিত থাকে — git log সীমিত history দেখায়, git blame অসম্পূর্ণ হয়, আর branch chain অসম্পূর্ণ থাকায় কিছু অপারেশনে সমস্যা হতে পারে।

প্র.৬ — CI/CD pipeline-এ shallow clone কেন কমন প্র্যাক্টিস? উত্তর: CI বিল্ড/টেস্টের জন্য শুধু বর্তমান কোড দরকার, পুরো history অপ্রয়োজনীয়। শুধু সর্বশেষ commit আনলে clone দ্রুত হয় ও রানার রিসোর্স বাঁচে — বেশিরভাগ CI টুল এই কারণে ডিফল্টে shallow clone ব্যবহার করে।

• একটা বিদ্যমান, non-empty ডিরেক্টরিতে git clone চালানো যায় না — clone সবসময় একটা নতুন ফোল্ডার তৈরি করে (অথবা বর্তমান ডিরেক্টরি সম্পূর্ণ খালি হতে হবে)। বিদ্যমান প্রজেক্টে Git যোগ করতে হলে git init ব্যবহার করতে হয়, git clone না।

• Shallow clone-এ push করার চেষ্টা করলে অনেক সময় সার্ভার-সাইড রিফিউজ করতে পারে — কিছু Git hosting policy shallow repository থেকে push গ্রহণ করে না কারণ history chain অসম্পূর্ণ থাকে; git fetch --unshallow করে পূর্ণ history আনার পরই নিরাপদে push করা উচিত।

• git init একটা বিদ্যমান .git ফোল্ডারযুক্ত ডিরেক্টরিতে আবার চালালে এরর দেয় না, বরং idempotent — বিদ্যমান কনফিগ/history অক্ষত রেখে নিরাপদে "reinitialize" করে — অনেকে ভয় পান এটা পুরনো ইতিহাস মুছে দেবে, বাস্তবে তা হয় না।

• --bare রিপোতে ভুলবশত git add/git commit চালানোর চেষ্টা করলে "fatal: this operation must be run in a work tree" এরর আসে — এটা মনে করিয়ে দেয় bare রিপো শুধু বিনিময়-বিন্দু, ডেভেলপমেন্টের জায়গা না।

এই মডিউলে দৈনন্দিন staging ওয়ার্কফ্লোর প্রতিটা কমান্ড: git status (+ -s/--porcelain), git add (প্লেইন, ., -A, -u, ইন্টারেক্টিভ -p, -N), git diff বনাম git diff --staged/--cached, git restore ও git restore --staged, এবং git rm/git mv।

কী করে

git status তিনটা এলাকার (working directory, staging area, repository) মধ্যে বর্তমান পার্থক্য দেখায় — কোন ফাইল modified, staged, untracked।

git status

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   app.py

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
        modified:   config.py

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        new_feature.py

ভেতরে কী তুলনা করে

Git তিনটা তুলনা একসাথে করে: HEAD commit-এর tree বনাম index (staging area) — এটাই "Changes to be committed" সেকশন দেখায়; আর index বনাম working directory — এটাই "Changes not staged" সেকশন দেখায়। Untracked ফাইল মানে index-এই নেই।

স্ক্রিপ্টের জন্য মেশিন-পাঠযোগ্য ফরম্যাট

git status -s
#  M app.py
#  M config.py
# ?? new_feature.py

প্রথম কলাম staging area-র অবস্থা, দ্বিতীয় কলাম working directory-র অবস্থা। --porcelain একই আউটপুট কিন্তু ভবিষ্যৎ Git ভার্সনেও ফরম্যাট স্থির থাকার গ্যারান্টি সহ — শেল স্ক্রিপ্ট/CI-তে parse করার জন্য এটাই নিরাপদ পছন্দ, প্লেইন -s না।

রিয়েল-লাইফ ব্যবহার

একটা pre-commit hook বা CI চেকে "working directory পরিষ্কার আছে কিনা" যাচাই করতে:

if [ -n "$(git status --porcelain)" ]; then
  echo "Uncommitted changes found!"
  exit 1
fi

এই প্যাটার্ন প্রায় প্রতিটা deployment স্ক্রিপ্টে দেখা যায় — deploy করার আগে নিশ্চিত করা হয় কোনো uncommitted change নেই।

তিনটা ভিন্ন স্কোপ

git add-এর সবচেয়ে বেশি ভুল বোঝা অংশ হলো এর বিভিন্ন ফর্মের স্কোপ ভিন্ন।

git add .

বর্তমান ডিরেক্টরি ও তার নিচের নতুন + modified ফাইল stage করে — কিন্তু বর্তমান ডিরেক্টরির বাইরে deleted ফাইল ধরে না যদি সেটা অন্য পাথে থাকে (আসলে আধুনিক Git-এ . পুরো রিপোর deletion-ও ধরে যদি বর্তমান ডিরেক্টরি রিপো রুট হয়)।

git add -A
# বা: git add --all

পুরো রিপোজিটরি জুড়ে নতুন, modified, এবং deleted — সব ধরনের পরিবর্তন stage করে, বর্তমান ডিরেক্টরি নির্বিশেষে।

git add -u
# বা: git add --update

শুধু ইতিমধ্যে ট্র্যাক করা ফাইলের modification/deletion stage করে — নতুন (untracked) ফাইল কখনো যোগ করে না।

তুলনা টেবিল

রিয়েল-লাইফ সমস্যা যা এটা এড়ায়

ধরুন একটা .env.local ফাইল ভুলবশত তৈরি হয়ে গেছে যেটা কমিট করা উচিত না। git add -u ব্যবহার করলে এই নতুন ফাইলটা কখনোই স্টেজ হবে না (নিরাপদ), কিন্তু git add -A/git add . ব্যবহার করলে আপনাকে অবশ্যই .gitignore-এ সেটা যোগ করে রাখতে হবে, নাহলে ভুলবশত কমিট হয়ে যাবে।

-p: ফাইলের ভেতরের অংশ (hunk) আলাদাভাবে stage করা

একই ফাইলে দুটো unrelated পরিবর্তন করে ফেললে, পুরো ফাইল একসাথে stage করলে commit history অপরিষ্কার হয়। -p (--patch) প্রতিটা hunk আলাদাভাবে review করে stage করার সুযোগ দেয়।

git add -p app.py

diff --git a/app.py b/app.py
@@ -10,3 +10,6 @@ def process():
     return result
+
+def new_helper():
+    pass
Stage this hunk [y,n,q,a,d,s,e,?]?

গুরুত্বপূর্ণ অপশন: y (stage করো), n (skip করো), s (আরও ছোট hunk-এ split করো), e (ম্যানুয়ালি hunk এডিট করো)।

রিয়েল-লাইফ ব্যবহার

একই ফাইলে একটা bug fix আর একটা debug print() স্টেটমেন্ট দুটোই যোগ হয়ে গেছে। git add -p দিয়ে শুধু bug fix hunk stage করে debug print বাদ দেওয়া যায়, ফাইল আলাদা না করেই।

-N: Intent-to-Add

একটা নতুন ফাইল তৈরি করেছেন কিন্তু এখনই সম্পূর্ণ content stage করতে চান না — শুধু Git-কে জানাতে চান "এই ফাইলটা ট্র্যাক করা হবে ভবিষ্যতে"।

git add -N new_file.py
git status -s
#  AM new_file.py   ← Added কিন্তু Modified হিসেবেও দেখাচ্ছে

এর পর git diff (staged না, plain diff) এই নতুন ফাইলের সম্পূর্ণ content-কেই "diff" হিসেবে দেখাতে পারবে — -N ছাড়া git diff untracked ফাইল একেবারেই দেখায় না।

কেন -N কাজে লাগে

git add -p দিয়ে একটা সম্পূর্ণ নতুন ফাইলের নির্দিষ্ট অংশ stage করতে চাইলে প্রথমে -N দিয়ে ফাইলটাকে "known" বানাতে হয়, তারপরই -p সেই ফাইলের ভেতরে hunk-লেভেল সিলেকশন দেখাতে পারে — নাহলে সম্পূর্ণ নতুন ফাইল একটা একক ব্লক হিসেবে stage হয়ে যেত।

দুই ধরনের diff

git diff তিনটা এলাকার মধ্যে তুলনা করতে পারে — কিন্তু ফ্ল্যাগ ছাড়া ও ফ্ল্যাগসহ ভিন্ন জিনিস দেখায়।

git diff

এটা তুলনা করে staging area (index) বনাম working directory — অর্থাৎ যে পরিবর্তনগুলো এখনো git add করা হয়নি।

git diff --staged
# সমতুল্য: git diff --cached

এটা তুলনা করে HEAD commit বনাম staging area (index) — অর্থাৎ যে পরিবর্তনগুলো পরের commit-এ যাবে।

ভিজ্যুয়ালি

HEAD (last commit) ──diff --staged──► Index (staging) ──diff (no flag)──► Working Directory

তুলনা টেবিল

রিয়েল-লাইফ ওয়ার্কফ্লো

কমিট করার ঠিক আগে সবসময় git diff --staged চালিয়ে দেখে নেওয়া উচিত ঠিক কী commit হতে যাচ্ছে — এটা accidental debug কোড বা অসম্পূর্ণ পরিবর্তন commit হয়ে যাওয়া রোধ করে।

git add app.py
git diff --staged
# শুধু app.py-তে যা stage হয়েছে তার diff দেখাবে
git commit -m "fix: null check in process()"

গুরুত্বপূর্ণ পার্থক্য মনে রাখার শর্টকাট

git diff = "আমি কী add করতে ভুলে গেছি?" git diff --staged = "আমি ঠিক কী commit করতে যাচ্ছি?"

restore কী সমস্যার সমাধান

আগে git checkout দিয়ে ফাইল রিস্টোর করা আর branch পরিবর্তন — দুটো ভিন্ন কাজের জন্য একই কমান্ড ব্যবহার হতো, যা confusing ছিল। Git 2.23+ থেকে git restore (ফাইল রিস্টোরের জন্য) আর git switch (branch পরিবর্তনের জন্য) — আলাদা করা হয়েছে।

Working directory-র পরিবর্তন বাতিল করা

git restore app.py
# working directory-তে app.py-র পরিবর্তন বাতিল, index-এর ভার্সনে ফিরিয়ে দেয়

এটা destructive — commit না করা local পরিবর্তন স্থায়ীভাবে হারিয়ে যায়।

Stage থেকে সরানো (unstage)

git add app.py
git restore --staged app.py
# app.py আবার "unstaged" অবস্থায় ফিরে যায়, কিন্তু working directory-র পরিবর্তন অক্ষত থাকে

এটা নিরাপদ — শুধু staging area থেকে সরায়, ফাইলের কন্টেন্ট বদলায় না।

দুইটা একসাথে ব্যবহার করে সম্পূর্ণ রিসেট

git restore --staged --worktree app.py
# stage থেকেও সরাবে, working directory-র পরিবর্তনও বাতিল করবে — সম্পূর্ণ HEAD অবস্থায় ফিরিয়ে দেবে

ভেতরে কী ঘটে

git restore (ফ্ল্যাগ ছাড়া) index থেকে working directory-তে ফাইল কপি করে। git restore --staged HEAD commit-এর tree থেকে index-এ ফাইল কপি করে (working directory অক্ষত রেখে)।

রিয়েল-লাইফ দৃশ্যপট

ভুলবশত git add . চালিয়ে একটা secret ফাইল (.env) stage হয়ে গেছে commit করার আগেই ধরা পড়লো:

git restore --staged .env
# stage থেকে সরে গেলো, কমিট হওয়া থেকে বাঁচলো, ফাইলটা এখনো ডিস্কে অক্ষত আছে

git rm — ফাইল ডিলিট ও unstage একসাথে

git rm old_file.py

এটা দুটো কাজ একসাথে করে: ফাইলটা working directory থেকে ডিলিট করে, এবং সেই deletion index-এ stage করে — পরের commit-এ ফাইলটা সরানো হিসেবে রেকর্ড হবে।

--cached: শুধু ট্র্যাকিং বন্ধ করা, ফাইল অক্ষত রাখা

git rm --cached secrets.env

এটা ফাইলটাকে শুধু Git-এর ট্র্যাকিং থেকে বাদ দেয়, ডিস্কের আসল ফাইল মুছে ফেলে না। এটাই সঠিক পদ্ধতি যখন একটা ফাইল ভুলবশত ট্র্যাক হয়ে গেছে (যেমন node_modules/ বা .env) — এখন .gitignore-এ যোগ করার সাথে সাথে ব্যবহার করা হয়:

echo ".env" >> .gitignore
git rm --cached .env
git commit -m "stop tracking .env"

-r: রিকার্সিভভাবে পুরো ফোল্ডার সরানো

git rm -r old_directory/

git mv — রিনেম/মুভ

git mv old_name.py new_name.py

ভেতরে কী ঘটে (গুরুত্বপূর্ণ)

git mv old.py new.py আসলে ইন্টার্নালি সমতুল্য:

mv old.py new.py
git rm old.py
git add new.py

Git-এ কোনো explicit "rename" object/অপারেশন নেই — Git rename detect করে (content similarity বিশ্লেষণ করে) git log --follow বা git diff চালানোর সময়, storage-এ rename বলে কিছু আলাদাভাবে রেকর্ড হয় না। git mv শুধু ম্যানুয়াল দুই ধাপ (rm + add) একসাথে করার সুবিধাজনক শর্টকাট।

রিয়েল-লাইফ দৃশ্যপট

প্রজেক্ট রিস্ট্রাকচার করার সময় src/utils.py কে src/helpers/utils.py-তে সরাতে git mv src/utils.py src/helpers/utils.py — এক কমান্ডে move + stage দুটোই হয়ে যায়, আলাদা করে git add লাগে না।

লক্ষ্য

স্ট্যাটাস চেক, সিলেক্টিভ স্টেজিং, diff review, আর restore — পুরো ওয়ার্কফ্লো এক সেশনে প্র্যাকটিস করা।

ধাপ ১ — সেটআপ

mkdir ~/gitlab-04 && cd ~/gitlab-04
git init
echo "def add(a, b):\n    return a + b" > calc.py
git add calc.py
git commit -m "initial calc.py"

ধাপ ২ — দুটো unrelated পরিবর্তন একসাথে করা

cat >> calc.py << 'EOF'

def subtract(a, b):
    return a - b

print("DEBUG:", add(1, 2))
EOF

ধাপ ৩ — status ও diff দিয়ে যাচাই

git status -s
#  M calc.py
git diff
# দুটো hunk দেখাবে — নতুন ফাংশন যোগ + debug print

ধাপ ৪ — শুধু ফাংশনটা stage করা, debug print বাদ দিয়ে

git add -p calc.py
# subtract() ফাংশনের hunk-এ 'y', debug print-এর hunk-এ 'n'

ধাপ ৫ — নিশ্চিত হওয়া কী commit হতে যাচ্ছে

git diff --staged
# শুধু subtract() ফাংশন দেখাবে, debug print দেখাবে না

ধাপ ৬ — commit করা, তারপর বাকি অংশ পরিষ্কার করা

git commit -m "add subtract function"
git restore calc.py
# debug print লাইনটা working directory থেকেও বাতিল হয়ে গেলো
git diff
# কিছুই আসবে না — পরিষ্কার

ধাপ ৭ — rm --cached প্র্যাকটিস

echo "SECRET_KEY=abc123" > .env
git add .env
git commit -m "oops committed env"
echo ".env" >> .gitignore
git rm --cached .env
git commit -m "stop tracking .env"
ls .env  # ফাইলটা ডিস্কে এখনো আছে

চ্যালেঞ্জ

git mv calc.py math_ops.py চালিয়ে git status চেক করুন rename কীভাবে detect হয় (renamed: লেবেল দেখাবে)।

প্র.১ — git add -A আর git add -u-এর পার্থক্য কী? উত্তর: git add -A পুরো রিপোতে নতুন, modified, ও deleted — সব ধরনের পরিবর্তন stage করে। git add -u শুধু ইতিমধ্যে ট্র্যাক করা ফাইলের modification/deletion stage করে, কোনো নতুন (untracked) ফাইল কখনো যোগ করে না।

প্র.২ — git diff আর git diff --staged-এর মধ্যে পার্থক্য কী? উত্তর: git diff তুলনা করে staging area বনাম working directory (যা এখনো add করা হয়নি)। git diff --staged (= --cached) তুলনা করে HEAD commit বনাম staging area (যা পরের commit-এ যাবে)।

প্র.৩ — git restore আর git restore --staged-এর পার্থক্য বলুন। উত্তর: git restore <file> working directory-র পরিবর্তন বাতিল করে index-এর ভার্সনে ফিরিয়ে দেয় (destructive — local change হারায়)। git restore --staged <file> শুধু staging area থেকে unstage করে, working directory-র পরিবর্তন অক্ষত রাখে (নিরাপদ)।

প্র.৪ — একটা ফাইল ভুলবশত ট্র্যাক হয়ে গেছে (যেমন .env), কিন্তু ডিস্কে ফাইলটা রাখতে চান। কীভাবে সমাধান করবেন? উত্তর: git rm --cached .env চালিয়ে শুধু Git-এর ট্র্যাকিং থেকে বাদ দিতে হবে (ফাইল ডিস্কে অক্ষত থাকবে), তারপর .gitignore-এ .env যোগ করে commit করতে হবে যাতে ভবিষ্যতে আবার ট্র্যাক না হয়।

প্র.৫ — Git কীভাবে rename ট্র্যাক করে — git mv-এর জন্য কি আলাদা কোনো object তৈরি হয়? উত্তর: না, Git-এ কোনো explicit rename object/অপারেশন নেই। git mv আসলে ইন্টার্নালি mv + git rm + git add-এর শর্টকাট। Rename পরে detect করা হয় content similarity বিশ্লেষণ করে (git log --follow, git diff চালানোর সময়), storage-এ আলাদাভাবে রেকর্ড থাকে না।

প্র.৬ — git add -p-এ কখন ব্যবহার করবেন, আর -N (intent-to-add) কী সমস্যা সমাধান করে? উত্তর: -p ব্যবহার করা হয় যখন একই ফাইলে একাধিক unrelated পরিবর্তন থাকে এবং শুধু নির্দিষ্ট hunk stage করতে চান। -N একটা সম্পূর্ণ নতুন ফাইলকে "known" (কিন্তু এখনো empty-এর মতো) বানায় যাতে git diff/git add -p সেই ফাইলের ভেতরে hunk-লেভেল সিলেকশন করতে পারে — নাহলে নতুন ফাইল একটা একক ব্লক হিসেবে stage হয়।

• git add . পুরনো Git ভার্সনে (2.x-এর আগে) deleted ফাইল ধরত না, কিন্তু আধুনিক Git-এ ধরে — এটা নিয়ে পুরনো ব্লগ পোস্ট/স্ট্যাক ওভারফ্লো উত্তর প্রায়ই ভুল তথ্য দেয়; বর্তমান Git ভার্সনে git add . আর git add -A (রিপো রুট থেকে চালালে) কার্যত সমতুল্য আচরণ করে।

• git restore destructive — এটা rm বা checkout ---এর মতো, কোনো "undo" নেই যদি না কমিট হয়ে থাকে — একবার git restore file.py চালালে working directory-র uncommitted পরিবর্তন চিরতরে হারিয়ে যায়। কমিট না করা কাজ হারানোর সবচেয়ে সাধারণ কারণ এটাই।

• git rm ফাইলে uncommitted local পরিবর্তন থাকলে ডিফল্টে রিফিউজ করে ("error: ... has local modifications") — নিরাপত্তা ফিচার, force করতে -f লাগে, যা ভুলবশত কাজ হারানো রোধ করে।

• git mv আর ম্যানুয়াল mv + git add + git rm-এর ফলাফল কার্যত সম্পূর্ণ অভিন্ন — কেউ ভাবতে পারেন git mv একটা বিশেষ "rename tracking" object তৈরি করে, বাস্তবে দুটো পদ্ধতিই একই ফলাফল দেয়, git mv শুধু সুবিধার জন্য একটা wrapper।

এই মডিউলে কমিট করার প্রতিটা কৌশল: git commit -m, -am-এর ঝুঁকি, --amend (+ --no-edit), --allow-empty, --fixup/--squash-এর প্রিভিউ, -S সাইনিং প্রিভিউ, ভালো commit message লেখার নিয়ম (৫০/৭২ রুল, imperative mood), আর -v দিয়ে diff দেখে commit করা।

বেসিক commit

git commit -m "fix: null pointer in process()"

এটা staging area-তে যা কিছু আছে, তার একটা নতুন commit object তৈরি করে (Phase 2-এ বিস্তারিত) — বর্তমান HEAD-কে parent হিসেবে ধরে, একটা নতুন tree snapshot বানিয়ে, HEAD-কে সেই নতুন commit-এর দিকে সরিয়ে দেয়।

-am — দুটো কাজ একসাথে, কিন্তু একটা ফাঁদসহ

git commit -am "fix bug"
# সমতুল্য: git add -u && git commit -m "fix bug"

-a ফ্ল্যাগ commit-এর আগে স্বয়ংক্রিয়ভাবে সব ট্র্যাক করা ফাইলের পরিবর্তন stage করে দেয় — কিন্তু এটা git add -u-এর সমতুল্য, git add -A-এর না।

আসল ঝুঁকি

touch brand_new_file.py   # নতুন, untracked ফাইল
echo "x = 1" >> existing.py  # ট্র্যাক করা ফাইলে পরিবর্তন

git commit -am "add feature"
git status
# brand_new_file.py এখনো untracked! commit-এ যায়নি

অনেক ডেভেলপার ধরে নেন -am সব পরিবর্তন ধরে ফেলবে, কিন্তু নতুন ফাইল কখনোই -a দিয়ে stage হয় না — এটা শুধু ইতিমধ্যে ট্র্যাক করা ফাইলের জন্য কাজ করে। ফলে commit-এ একটা প্রয়োজনীয় নতুন ফাইল বাদ পড়ে যেতে পারে, যা পরে বিল্ড ব্রেক করে।

নিরাপদ অভ্যাস

Commit করার আগে সবসময় git status দেখে নিশ্চিত হওয়া উচিত কোনো নতুন ফাইল বাদ পড়ছে কিনা, বিশেষ করে -am ব্যবহারের সময়।

রিয়েল-লাইফ দৃশ্যপট

একটা নতুন মডিউল ফাইল (payment_gateway.py) তৈরি করে, একটা বিদ্যমান ফাইলে সেটা import যোগ করে -am দিয়ে commit করলে — commit-এ import লাইন থাকবে কিন্তু আসল payment_gateway.py ফাইলটাই থাকবে না, ফলে CI/deployment-এ ImportError আসবে।

--amend: সর্বশেষ commit সংশোধন

git commit --amend

এটা নতুন একটা commit object তৈরি করে যা পুরনো commit-এর জায়গা প্রতিস্থাপন করে — এটা পুরনো commit-কে এডিট করে না (Git-এ commit immutable, কখনো এডিট হয় না)। ভেতরে কী ঘটে: staging area-র বর্তমান কন্টেন্ট + আগের commit message নিয়ে একটা নতুন commit object বানানো হয়, HEAD ও current branch ref সেই নতুন commit-কে পয়েন্ট করে, পুরনো commit object অরফান হয়ে যায় (reachable না, পরে git gc-তে সাফ হতে পারে)।

# ভুলে একটা ফাইল বাদ পড়েছে সর্বশেষ commit-এ
git add forgotten_file.py
git commit --amend --no-edit
# --no-edit: commit message অপরিবর্তিত রেখে শুধু কন্টেন্ট আপডেট

--no-edit vs ডিফল্ট

ডিফল্টে --amend কমিট মেসেজ এডিটরে খোলে (পরিবর্তনের সুযোগ দেয়)। --no-edit দিলে আগের মেসেজ হুবহু রেখে দেয় — শুধু কন্টেন্ট/tree বদলায়।

⚠️ সবচেয়ে গুরুত্বপূর্ণ সতর্কতা

Push করা commit কখনো amend করা উচিত না যদি না নিশ্চিত হন কেউ সেই branch থেকে pull করেনি — কারণ amend পুরনো commit hash বাতিল করে নতুন hash তৈরি করে, যা অন্যদের লোকাল history-র সাথে diverge করে দেয় (force-push আর conflict লাগবে)।

--allow-empty: খালি commit তৈরি

git commit --allow-empty -m "trigger CI rebuild"

কোনো ফাইল পরিবর্তন ছাড়াই একটা commit তৈরি করে — একই tree hash, শুধু নতুন commit metadata। ব্যবহার: CI/CD pipeline জোর করে ট্রিগার করা, deployment marker রাখা।

তুলনা টেবিল

সমস্যা যা এই ফ্ল্যাগ দুটো সমাধান করে

একটা বড় feature-এর উপর কাজ করার সময় ইতিমধ্যে ১০টা commit হয়ে গেছে। পরে দেখা গেলো commit #৩-এ একটা সামান্য bug ছিল। সরাসরি একটা নতুন commit "fix typo in commit 3" যোগ করলে history অগোছালো হয়ে যায় — এই সমস্যার পরিষ্কার সমাধান --fixup।

--fixup

git commit --fixup=<commit-hash>

এটা একটা বিশেষ ফরম্যাটের commit message তৈরি করে (fixup! <original commit's subject>), যা পরে git rebase -i --autosquash চালালে স্বয়ংক্রিয়ভাবে সেই টার্গেট commit-এর সাথে মিশে যায় (squash হয়) — আপনাকে ম্যানুয়ালি reorder/squash করতে হয় না।

git log --oneline
# a1b2c3 fixup! add payment validation
# 9f8e7d add error logging
# 5c4d3e add payment validation   ← এটাই টার্গেট

git rebase -i --autosquash 5c4d3e~1
# rebase editor-এ fixup commit স্বয়ংক্রিয়ভাবে টার্গেটের ঠিক নিচে সাজানো ও 'fixup' অ্যাকশন প্রি-সিলেক্টেড থাকবে

--squash

git commit --squash=<commit-hash>

--fixup-এর মতোই আচরণ, কিন্তু পার্থক্য: squash commit-এর message টার্গেট commit-এর message-এর সাথে একত্রিত হয় ফাইনাল squash-এর সময় (fixup-এ টার্গেটের message-ই থেকে যায়, নতুনটা বাতিল হয়)।

এই মডিউলে শুধু প্রিভিউ কেন

--fixup/--squash-এর পূর্ণ শক্তি বোঝা যায় শুধু git rebase -i --autosquash-এর সাথে একত্রে — যেটা একটা সম্পূর্ণ আলাদা, গভীর টপিক (পরবর্তী ফেজে Interactive Rebase মডিউলে বিস্তারিত)। এখানে শুধু concept ও কমান্ড-সিনট্যাক্স পরিচিত করানো হলো।

রিয়েল-লাইফ ওয়ার্কফ্লো

PR রিভিউয়ে "commit #৩-এ এই বাগ আছে" কমেন্ট এলে, ডেভেলপাররা প্রায়ই git commit --fixup=<hash> দিয়ে ফিক্স করে রাখেন, তারপর একেবারে শেষে rebase দিয়ে সব fixup একসাথে squash করে পরিষ্কার history নিয়ে merge করেন।

সমস্যা: commit-এ identity spoof করা যায়

git config user.email যেকোনো ইমেইল বসিয়ে দেওয়া যায় — কেউ চাইলে অন্য কারো নামে/ইমেইলে commit বানাতে পারে, Git নিজে সেটা যাচাই করে না। এটা একটা বিশ্বাসের সমস্যা তৈরি করে বিশেষ করে ওপেন-সোর্স প্রজেক্টে।

সমাধান: GPG/SSH সাইনিং

git commit -S -m "critical security fix"

-S ফ্ল্যাগ commit object তৈরি করার সময় আপনার প্রাইভেট কী দিয়ে একটা cryptographic signature যোগ করে। এই signature commit object-এর ভেতরেই সংরক্ষিত হয় (একটা gpgsig হেডার হিসেবে) — অর্থাৎ signature নিজেই commit-এর hash-এর অংশ।

যাচাই

git log --show-signature -1
# gpg: Good signature from "Rakib Hasan <rakib@example.com>"

GitHub-এ সঠিকভাবে সাইন করা commit-এ একটা "Verified" ব্যাজ দেখা যায়।

প্রতিটা commit-এ স্বয়ংক্রিয়ভাবে সাইন করা

git config --global commit.gpgsign true
git config --global user.signingkey <KEY_ID>

কেন এখানে শুধু প্রিভিউ

সাইনিং-এর পূর্ণ সেটআপ (GPG কী তৈরি, GitHub-এ পাবলিক কী আপলোড, SSH সাইনিং বিকল্প, .gitconfig-এর gpg.format) একটা সম্পূর্ণ আলাদা Security-কেন্দ্রিক ফেজের বিষয় — সেখানে বিস্তারিত সেটআপ ও ট্রাবলশুটিং কভার হবে। এখানে শুধু concept ও কেন এটা দরকার তা বোঝাই লক্ষ্য।

রিয়েল-লাইফ প্রভাব

Linux kernel-এর মতো বড় ওপেন-সোর্স প্রজেক্টে maintainer-রা unsigned commit reject করে দেন — এটাই নিশ্চিত করে যে commit সত্যিই সেই দাবি করা ব্যক্তির কাছ থেকে এসেছে, কেউ identity spoof করেনি।

৫০/৭২ রুল

Git কমিউনিটির একটা স্বীকৃত কনভেনশন:

• প্রথম লাইন (subject) সর্বোচ্চ ৫০ ক্যারেক্টার — সংক্ষিপ্ত সারাংশ।
• খালি একটা লাইন subject আর body-র মাঝে (বাধ্যতামূলক — নাহলে অনেক টুল body-কে subject-এর অংশ ধরে নেয়)।
• Body-র প্রতিটা লাইন সর্বোচ্চ ৭২ ক্যারেক্টার — টার্মিনাল/git log আউটপুটে wrap ছাড়া readable থাকে।

git commit -m "fix: prevent race condition in order processing" -m "
Previously, concurrent requests to the same order ID could
create duplicate charge records. This adds a row-level lock
via SELECT ... FOR UPDATE before the charge is created.

Fixes #482"

Imperative Mood (আদেশসূচক ক্রিয়া)

Subject line লেখা উচিত এমনভাবে যেন এটা একটা আদেশ/নির্দেশ — "Fix bug" (✅), "Fixed bug" বা "Fixes bug" না (❌)।

কেন: Git নিজেই এই কনভেনশন অনুসরণ করে — git merge স্বয়ংক্রিয়ভাবে যে commit message বানায় তা হলো "Merge branch 'x'"। এই নিয়মটা মনে রাখার সহজ কৌশল: subject line-এর আগে মনে মনে "If applied, this commit will..." বসিয়ে পড়ুন — "If applied, this commit will fix bug" ব্যাকরণগতভাবে ঠিক আছে, "If applied, this commit will fixed bug" না।

তুলনা

রিয়েল-লাইফ প্রভাব

git log --oneline চালালে ৫০-ক্যারেক্টার সীমা মানা commit message-গুলো এক লাইনে সুন্দরভাবে align হয়ে থাকে, পড়া সহজ হয়। ভবিষ্যতে git bisect বা git blame দিয়ে ইতিহাস খুঁজতে হলে ভালো commit message-ই একমাত্র সূত্র — খারাপ message ("fix", "update", "wip") থাকলে debugging দ্বিগুণ সময় নেয়।

সমস্যা

git commit (ফ্ল্যাগ ছাড়া, এডিটর খোলে) সাধারণত শুধু একটা খালি কমিট মেসেজ এডিটর দেখায় — ঠিক কী commit হতে যাচ্ছে তা মনে করে লিখতে হয়, ভুলে যাওয়ার সম্ভাবনা থাকে।

-v ফ্ল্যাগ

git commit -v

এটা কমিট মেসেজ এডিটর খোলার সময় নিচে staged diff-টাও comment হিসেবে দেখায় — ঠিক কোন লাইনগুলো পরিবর্তন হয়েছে তা দেখতে দেখতেই মেসেজ লেখা যায়।

# Please enter the commit message for your changes...
#
# On branch main
# Changes to be committed:
#	modified:   payment.py
#
diff --git a/payment.py b/payment.py
index abc123..def456 100644
--- a/payment.py
+++ b/payment.py
@@ -15,6 +15,9 @@ def process_payment(order):
+    if order.amount <= 0:
+        raise ValueError("Invalid amount")

স্থায়ীভাবে সেট করা

git config --global commit.verbose true
# এখন থেকে সাধারণ 'git commit' (ফ্ল্যাগ ছাড়া, এডিটর মোডে) সবসময় diff দেখাবে

রিয়েল-লাইফ সুবিধা

একটা multi-file commit-এ ঠিক কী কী পরিবর্তন হয়েছে মনে রাখা কঠিন। -v দিয়ে diff দেখতে দেখতে একটা নির্ভুল, নির্দিষ্ট commit message লেখা যায় — যেমন "fix: reject zero-amount payments" লেখার সময় সরাসরি diff-এ দেখা if order.amount <= 0 লাইনটাই মেসেজের ভাষা নির্ধারণ করতে সাহায্য করে।

গুরুত্বপূর্ণ নোট

diff অংশটা comment (# দিয়ে শুরু) হিসেবে থাকে — সেভ করার সময় স্বয়ংক্রিয়ভাবে বাদ পড়ে যায়, actual commit message-এ যুক্ত হয় না।

লক্ষ্য

--amend, --allow-empty, আর ভালো commit message লেখার অভ্যাস — একই সেশনে প্র্যাকটিস করা।

ধাপ ১ — সেটআপ

mkdir ~/gitlab-05 && cd ~/gitlab-05
git init
git config commit.verbose true
echo "def total(items):\n    return sum(items)" > cart.py
git add cart.py
git commit -m "add total function"

ধাপ ২ — ভুল ধরা পড়লো, amend দিয়ে ঠিক করা

cat >> cart.py << 'EOF'

def total(items):
    if not items:
        return 0
    return sum(items)
EOF
git add cart.py
git commit --amend -m "add total function with empty-list guard"
git log --oneline
# একটাই commit দেখাবে — নতুন hash, পুরনোটা প্রতিস্থাপিত

ধাপ ৩ — -am-এর ঝুঁকি হাতে-কলমে দেখা

touch discount.py     # নতুন, untracked ফাইল
echo "# updated" >> cart.py   # tracked ফাইলে পরিবর্তন
git commit -am "add discount support"
git status
# discount.py এখনো untracked! ভুল ধরা পড়লো
git add discount.py
git commit -m "add discount.py file"

ধাপ ৪ — --allow-empty প্র্যাকটিস

git commit --allow-empty -m "chore: trigger CI rebuild"
git log --oneline
# একটা নতুন commit, কোনো ফাইল পরিবর্তন ছাড়াই

ধাপ ৫ — ৫০/৭২ রুল মেনে একটা multi-line commit

echo "def apply_discount(total, pct):\n    return total * (1 - pct)" >> cart.py
git add cart.py
git commit -v -m "feat: add percentage-based discount" -m "Adds apply_discount() which reduces the cart
total by a given percentage. Percentage is expected
as a fraction (0.1 = 10%), not a whole number."

চ্যালেঞ্জ

git log -p -1 চালিয়ে দেখুন সর্বশেষ commit-এর সম্পূর্ণ diff ও message কীভাবে একসাথে দেখা যায়, তারপর git log --format="%h %s" দিয়ে শুধু hash + subject দেখুন।

প্র.১ — git commit -am কেন সবসময় নিরাপদ না? উত্তর: -a ফ্ল্যাগ git add -u-এর সমতুল্য — শুধু ইতিমধ্যে ট্র্যাক করা ফাইলের পরিবর্তন stage করে, কোনো নতুন (untracked) ফাইল কখনো যোগ করে না। ফলে যদি একটা নতুন ফাইল প্রয়োজনীয় হয় (যেমন একটা নতুন মডিউল), সেটা commit-এ বাদ পড়ে যেতে পারে, যা পরে বিল্ড ভেঙে ফেলে।

প্র.২ — git commit --amend কি পুরনো commit-কে এডিট করে, নাকি নতুন commit তৈরি করে? উত্তর: এটা সবসময় একটা নতুন commit object তৈরি করে যা পুরনোটাকে প্রতিস্থাপন করে — Git-এ commit immutable, কখনো in-place এডিট হয় না। পুরনো commit object অরফান হয়ে যায় (কোনো ref থেকে reachable না) এবং পরে git gc-তে সাফ হতে পারে।

প্র.৩ — Push করা commit amend করা কেন বিপজ্জনক হতে পারে? উত্তর: amend পুরনো commit hash বাতিল করে নতুন hash তৈরি করে। যদি কেউ ইতিমধ্যে সেই পুরনো commit pull করে থাকেন, তাদের লোকাল history-র সাথে diverge তৈরি হয় — সমাধানে force-push এবং সম্ভাব্য conflict লাগবে, যা টিম-ওয়ার্কে সমস্যা তৈরি করে।

প্র.৪ — --fixup আর --squash-এর পার্থক্য কী? উত্তর: দুটোই git rebase -i --autosquash-এর সাথে ব্যবহারের জন্য বিশেষ commit তৈরি করে যা টার্গেট commit-এর সাথে মিশে যায়। পার্থক্য: --fixup-এ ফাইনাল squash-এর সময় টার্গেটের message-ই থাকে (নতুনটা বাতিল), --squash-এ দুটো message একত্রিত করে এডিট করার সুযোগ দেওয়া হয়।

প্র.৫ — git commit -S কী করে, এবং এটা কীসের সমাধান? উত্তর: এটা commit object-এ একটা cryptographic signature (GPG/SSH) যোগ করে যা প্রমাণ করে commit সত্যিই দাবি করা ব্যক্তির কাছ থেকে এসেছে। এটা সমাধান করে identity spoofing সমস্যা — যেহেতু user.email যেকোনো মান বসানো যায়, signature ছাড়া কেউ অন্য কারো নামে commit বানাতে পারত।

প্র.৬ — Commit message-এ imperative mood ("fix bug" না "fixed bug") কেন ব্যবহার করা হয়? উত্তর: এটা Git-এর নিজস্ব কনভেনশনের সাথে সামঞ্জস্যপূর্ণ (যেমন auto-generated "Merge branch 'x'" মেসেজ)। মনে রাখার কৌশল হলো subject-এর আগে "If applied, this commit will..." বসিয়ে পড়া — imperative mood-এই বাক্যটা ব্যাকরণগতভাবে সঠিক হয়।

• git commit --amend করলে commit-এর author date অপরিবর্তিত থাকে, কিন্তু committer date আপডেট হয়ে যায় — git log --format="%ad %cd" দিয়ে দেখলে বোঝা যায় দুটো তারিখ ভিন্ন হয়ে গেছে; এটা মাঝেমধ্যে audit/timeline বিশ্লেষণে বিভ্রান্তি তৈরি করে।

• খালি staging area নিয়ে git commit (কোনো --allow-empty ছাড়া) চালালে Git এরর দেয়, চুপচাপ কিছু করে না — "nothing to commit, working tree clean" বার্তা আসে, নতুনরা মাঝে মাঝে ভাবেন commit হয়ে গেছে, বাস্তবে কিছুই ঘটেনি।

• --fixup/--squash commit তৈরি করলেই স্বয়ংক্রিয়ভাবে squash হয় না — এই commit গুলো আলাদা commit হিসেবেই history-তে থেকে যায় যতক্ষণ না ম্যানুয়ালি git rebase -i --autosquash চালানো হয়। অনেকে ভুল করে ভাবেন --fixup চালালেই কাজ শেষ।

• commit.gpgsign true গ্লোবালি সেট থাকা অবস্থায় GPG এজেন্ট চালু না থাকলে বা key expire হয়ে গেলে প্রতিটা commit ব্যর্থ হবে ("gpg failed to sign the data") — CI/CD পাইপলাইনে হঠাৎ সব commit ব্যর্থ হওয়ার একটা কমন কারণ এটাই, বিশেষ করে key rotation-এর পর।

এটাই এই পুরো জার্নির সবচেয়ে গুরুত্বপূর্ণ ফেজ। এখন পর্যন্ত আমরা "porcelain" কমান্ড (add, commit, status) দিয়ে কাজ করেছি — এগুলো আসলে নিচের লেয়ারে থাকা "plumbing" কমান্ড আর একটা content-addressable object ডেটাবেজের উপর সুবিধাজনক wrapper মাত্র। এই ফেজ শেষ না করে branching, merging, rebase, reflog — কোনোটাই সত্যিকার অর্থে বোঝা সম্ভব না, শুধু মুখস্থ কমান্ড থেকে যাবে। তিনটা মডিউল: Module 6 (blob/tree/commit — object model-এর ভিত্তি), Module 7 (refs, HEAD, index — এবং প্লাম্বিং কমান্ড দিয়ে হাতে একটা কমিট বানানোর সবচেয়ে গুরুত্বপূর্ণ ল্যাব, শেষে একটা checkpoint gate), Module 8 (packfiles ও মেইনটেন্যান্স — অবজেক্টগুলো ডিস্কে বাস্তবে কীভাবে সংরক্ষিত থাকে)। এই ফেজের প্রতিটা concept পরবর্তী প্রতিটা ফেজে বারবার রেফারেন্স হবে — এখানে সময় নিয়ে গভীরভাবে বোঝা বিনিয়োগযোগ্য।

এই মডিউলে Git-এর object model-এর তিনটা মূল বিল্ডিং ব্লক: content-addressable storage-এর মূল ধারণা (SHA hash কন্টেন্টের ফাংশন), blob (ফাইল-কন্টেন্ট, নাম ছাড়া), tree (ডিরেক্টরি স্ন্যাপশট — নাম+মোড+hash), আর commit (tree pointer + parent + author/committer + message)। সাথে plumbing কমান্ড git hash-object, git cat-file — এগুলো দিয়ে সরাসরি object ডেটাবেজে হাত দিয়ে দেখা।

মূল ধারণা

সাধারণ ফাইলসিস্টেমে একটা ফাইলের "ঠিকানা" তার নাম আর পাথ — /home/user/app.py। Git সম্পূর্ণ ভিন্নভাবে ভাবে: content-addressable storage মানে একটা অবজেক্টের ঠিকানা নির্ধারিত হয় তার কন্টেন্টের উপর ভিত্তি করে, নাম বা লোকেশনের উপর না।

Git প্রতিটা অবজেক্টের কন্টেন্ট নিয়ে একটা SHA-1 (নতুন রিপোতে ক্রমশ SHA-256) hash কম্পিউট করে — সেই hash-ই সেই অবজেক্টের একমাত্র identifier।

echo "hello world" | git hash-object --stdin
# 3b18e512dba79e4c8300dd08aeb37f8e728b8dad

কেন এটা গুরুত্বপূর্ণ: একই কন্টেন্ট = একই hash

echo "hello world" > file1.txt
echo "hello world" > file2.txt
git hash-object file1.txt
# 3b18e512dba79e4c8300dd08aeb37f8e728b8dad
git hash-object file2.txt
# 3b18e512dba79e4c8300dd08aeb37f8e728b8dad  ← হুবহু একই!

দুইটা সম্পূর্ণ ভিন্ন ফাইল, ভিন্ন নাম, কিন্তু identical কন্টেন্ট থাকায় Git-এর object database-এ একটাই copy সংরক্ষিত থাকবে — এটাই automatic deduplication।

প্রভাব: Integrity Verification

যেহেতু hash কন্টেন্ট-নির্ভর, একটা অবজেক্টের কন্টেন্ট একটুও বদলে গেলে (এমনকি ১ বাইট) hash সম্পূর্ণ ভিন্ন হয়ে যাবে। এর মানে Git স্বয়ংক্রিয়ভাবে corruption detect করতে পারে — git fsck এই নীতির উপরই কাজ করে (Module 8-এ বিস্তারিত)।

রিয়েল-লাইফ প্রভাব

দুইটা ভিন্ন branch-এ যদি একই ফাইল (identical কন্টেন্ট) থাকে, Git storage-এ সেটা একবারই রাখে — এই জন্যই branch তৈরি করা "সস্তা" (cheap), কপি-অন-রাইট-স্টাইল স্টোরেজ মডেলের কারণে, ফাইল সিস্টেম-লেভেল কপি না।

এক লাইনে

ফাইলনাম বলে "এই ঠিকানায় যাও"। Content hash বলে "এই কন্টেন্টটাই আমি, যেখানেই থাকি না কেন।"

সংজ্ঞা

Blob (Binary Large Object) হলো Git-এর object model-এর সবচেয়ে সাধারণ একক — এটা একটা ফাইলের শুধু raw content সংরক্ষণ করে। গুরুত্বপূর্ণ: blob-এ ফাইলের নাম, পাথ, বা পারমিশন কিছুই থাকে না — শুধু বাইট কন্টেন্ট।

ভেতরে কী থাকে

একটা blob অবজেক্ট আসলে একটা হেডার + কন্টেন্ট, zlib দিয়ে compress করা:

blob <size>\0<content>

echo "print('hello')" | git hash-object -t blob --stdin
# একটা 40-ক্যারেক্টার SHA-1 hash আসবে

নাম কোথায় সংরক্ষিত হয়, তাহলে?

নাম-পাথ-পারমিশন সংরক্ষিত হয় tree অবজেক্টে (পরের leaf-এ) — blob শুধু "কী কন্টেন্ট" জানে, "কোথায়/কী নামে" জানে না। এই আলাদাকরণের একটা সরাসরি ফলাফল: একই কন্টেন্টের দুইটা ভিন্ন-নামের ফাইল (config.py আর backup_config.py, একই কন্টেন্ট) — দুটোই একই blob-কে পয়েন্ট করবে, storage-এ একবারই রক্ষিত হবে।

সরাসরি দেখা

echo "version 1" | git hash-object -w --stdin
# abc123... (hash প্রিন্ট হবে, -w দিয়ে object database-এ লেখাও হবে)

git cat-file -p abc123...
# version 1

git cat-file -t abc123...
# blob

রিয়েল-লাইফ প্রভাব

Git কখনো "diff store" করে না — একটা ফাইলের প্রতিটা ভার্সন একটা সম্পূর্ণ নতুন (বা dedup করা পুরনো) blob হিসেবে থাকে। এই জন্য git show <hash>:path/to/file দিয়ে যেকোনো পুরনো commit-এর যেকোনো ফাইলের পূর্ণ কন্টেন্ট সরাসরি, তাৎক্ষণিকভাবে বের করা যায় — কোনো delta chain apply করার দরকার নেই।

সারসংক্ষেপ

Blob = শুধু "কী" (content), "কোথায়" আর "কী নামে" — এই তথ্য blob-এর দায়িত্বে না, এটা tree-র কাজ।

সংজ্ঞা

Tree অবজেক্ট একটা ডিরেক্টরির স্ন্যাপশট প্রতিনিধিত্ব করে — এতে থাকে এন্ট্রির একটা তালিকা, প্রতিটা এন্ট্রিতে: file mode (permission, যেমন 100644 normal file বা 100755 executable), নাম, আর hash (blob-এর জন্য, অথবা সাব-ডিরেক্টরির জন্য আরেকটা tree object-এর hash)।

গঠন দেখা

git cat-file -p HEAD^{tree}

100644 blob a1b2c3...   README.md
100644 blob d4e5f6...   config.py
040000 tree 7a8b9c...   src

লক্ষ্য করুন: src একটা সাব-ডিরেক্টরি হওয়ায় সেটা একটা নেস্টেড tree object-কে পয়েন্ট করছে, blob-কে না। এভাবে ডিরেক্টরি স্ট্রাকচার recursively প্রতিনিধিত্ব হয় — একটা tree of trees।

কেন এই ডিজাইন

Tree-blob আলাদা করার ফলে: একটা কমিটে যদি শুধু src/app.py বদলায়, তাহলে শুধু নতুন blob (app.py-র জন্য) আর সেই পাথের tree chain-এর (src/ এবং root) নতুন tree object তৈরি হয় — বাকি অপরিবর্তিত ফাইল/ফোল্ডারের tree/blob hash অপরিবর্তিত থাকে, পুনরায় তৈরি হয় না।

রিয়েল-লাইফ দৃশ্যপট

একটা প্রজেক্টে ১০০০টা ফাইল আছে, একটা commit-এ শুধু ১টা ফাইল বদলেছে। Git এই এক commit-এ নতুন কপি বানায় না ৯৯৯টা অপরিবর্তিত ফাইলের — শুধু বদলে যাওয়া ফাইলের blob + সেই পাথ পর্যন্ত tree chain (root থেকে সেই ফাইল পর্যন্ত ডিরেক্টরির প্রতিটা tree) নতুন করে তৈরি হয়, বাকি সব পুরনো hash-ই reuse হয়।

Tree কীভাবে তৈরি হয় (প্লাম্বিং)

git write-tree
# বর্তমান staging area (index) থেকে একটা tree object তৈরি করে, hash রিটার্ন করে

এটাই git commit-এর ভেতরে ভেতরে প্রথম ধাপ — Module 7-এর ল্যাবে বিস্তারিতভাবে হাতে-কলমে দেখা যাবে।

সারসংক্ষেপ টেবিল

সংজ্ঞা

Commit অবজেক্ট একটা নির্দিষ্ট মুহূর্তে পুরো প্রজেক্টের অবস্থার একটা রেকর্ড। এতে থাকে চারটা মূল অংশ:

git cat-file -p HEAD

tree 7a8b9c1d2e3f...
parent 5c4d3e2f1a0b...
author Rakib Hasan <rakib@example.com> 1735000000 +0600
committer Rakib Hasan <rakib@example.com> 1735000000 +0600

fix: null check in payment handler

প্রতিটা ফিল্ডের অর্থ

• tree — এই মুহূর্তের সম্পূর্ণ প্রজেক্ট স্ন্যাপশটের root tree-র hash (আগের leaf-এ ব্যাখ্যা করা)।
• parent — আগের commit-এর hash। প্রথম commit-এ parent থাকে না। Merge commit-এ একাধিক parent থাকে (Phase-পরবর্তী branching মডিউলে বিস্তারিত)।
• author — কে আসল পরিবর্তনটা লিখেছেন, ও কখন (timestamp + timezone)।
• committer — কে এই commit object-টা তৈরি করেছেন। সাধারণত author আর committer একই ব্যক্তি, কিন্তু git commit --amend, git cherry-pick, বা git rebase-এর পর এরা ভিন্ন হয়ে যেতে পারে — committer date/identity পরিবর্তিত হয়, author তথ্য অক্ষত থাকে।
• message — commit message (subject + body)।

Author বনাম Committer — কেন আলাদা

git log --format="Author: %an %ad%nCommitter: %cn %cd" -1

Rebase বা cherry-pick-এর সময় একটা commit "replay" করা হলে, মূল লেখক (author) অপরিবর্তিত থাকেন, কিন্তু committer হয়ে যান যিনি rebase/cherry-pick চালাচ্ছেন — এভাবে Git একাধিক ধাপে হাত বদল হওয়া commit-এর পুরো ইতিহাস ট্র্যাক রাখে।

Commit hash কীভাবে চেইন তৈরি করে

প্রতিটা commit তার parent-এর hash ধারণ করায়, পুরো history একটা linked list (বা merge commit-এর ক্ষেত্রে DAG — Directed Acyclic Graph) তৈরি করে। এই চেইনটাই git log traverse করে।

রিয়েল-লাইফ প্রভাব

commit hash tree + parent + author/committer + message — সবকিছুর উপর নির্ভরশীল হওয়ায়, --amend করলে (message বা content যেকোনো একটা বদলালেও) সম্পূর্ণ নতুন hash তৈরি হয় — এটাই আগের মডিউলে দেখা "amend নতুন commit তৈরি করে" নিয়মের root cause।

লক্ষ্য: object ডেটাবেজে সরাসরি হাত দেওয়া

git hash-object একটা plumbing কমান্ড যা কন্টেন্ট নিয়ে hash কম্পিউট করে, ঐচ্ছিকভাবে object database-এ লেখে।

শুধু hash কম্পিউট করা (ডিস্কে লেখে না)

echo "Hello, Git internals!" | git hash-object --stdin
# f6f75a11c9fbfb814a...  (hash প্রিন্ট হলো, কিন্তু .git/objects-এ কিছু লেখা হয়নি)

-w দিয়ে আসলেই object database-এ লেখা

echo "Hello, Git internals!" | git hash-object -w --stdin
# একই hash প্রিন্ট হবে
find .git/objects -type f
# .git/objects/f6/f75a11c9fbfb814a...  ← নতুন blob object ফাইল তৈরি হয়েছে

কীভাবে ফাইল হিসেবে সংরক্ষিত হয় (loose object ফরম্যাট)

Hash-এর প্রথম ২ ক্যারেক্টার ফোল্ডার নাম, বাকি ৩৮ ক্যারেক্টার ফাইল নাম — এটা একটা মিলিয়ন-প্লাস অবজেক্ট থাকা রিপোতেও একটা সিঙ্গেল ফ্ল্যাট ডিরেক্টরিতে ফাইলসিস্টেম স্লো-ডাউন এড়ায়।

xxd .git/objects/f6/f75a11c9fbfb814a... | head -3
# zlib-compressed বাইনারি ডেটা দেখাবে, প্লেইন টেক্সট না

বিদ্যমান ফাইল থেকে blob তৈরি

git hash-object -w README.md
# একটা এক্সিস্টিং ফাইলের কন্টেন্ট নিয়ে blob object তৈরি করবে

এটা কেন গুরুত্বপূর্ণ শেখার জন্য

git add-এর ভেতরে ভেতরে ঠিক এই কাজটাই ঘটে — প্রতিটা staged ফাইলের জন্য hash-object -w-এর সমতুল্য একটা অপারেশন চলে, তারপর সেই hash-গুলো index-এ (staging area) রেকর্ড হয়। git add আসলে hash-object -w + index আপডেট — এই দুটো কাজের একটা porcelain wrapper।

রিয়েল-লাইফ ব্যবহার

কোনো ফাইলের কন্টেন্ট আসলেই বদলেছে কিনা (byte-for-byte) চেক করতে, দুইটা ফাইলে git hash-object চালিয়ে hash তুলনা করা — diff কমান্ডের চেয়ে দ্রুত, বাইনারি ফাইলের জন্যও কাজ করে।

cat-file: object ডেটাবেজ পড়ার মূল টুল

git cat-file object hash দিয়ে সরাসরি object database থেকে কন্টেন্ট বের করে দেখায় — Git-এর "X-ray" টুল।

-t: টাইপ জানা

git cat-file -t a1b2c3d4
# blob   (অথবা: tree, commit, tag)

-p: প্রেটি-প্রিন্ট (মানুষের পড়ার উপযোগী)

git cat-file -p a1b2c3d4       # blob হলে raw content দেখাবে
git cat-file -p HEAD^{tree}    # tree হলে এন্ট্রি তালিকা দেখাবে
git cat-file -p HEAD           # commit হলে tree/parent/author/message দেখাবে

-s: সাইজ

git cat-file -s a1b2c3d4
# 1847   (বাইটে, compress-এর আগের আসল সাইজ)

--batch: বহু অবজেক্ট দ্রুত প্রসেস করা (স্ক্রিপ্টিং-এর জন্য)

প্রতিটা hash-এর জন্য আলাদা cat-file প্রসেস চালানো ধীরগতির (প্রতিবার নতুন প্রসেস স্পন হয়)। --batch একটা persistent প্রসেস চালু রেখে stdin দিয়ে একাধিক hash নেয়:

git rev-list --all | git cat-file --batch-check
# প্রতিটা commit hash-এর জন্য: hash type size — একলাইনে

echo "HEAD" | git cat-file --batch
# type + size + সম্পূর্ণ raw content একসাথে দেখাবে

রিয়েল-লাইফ ব্যবহার

একটা কাস্টম টুল লিখতে চাইলে যা রিপোর হাজার হাজার commit স্ক্যান করে (যেমন একটা leaked-secret স্ক্যানার), --batch/--batch-check ব্যবহার করলে প্রতিটা object-এর জন্য নতুন প্রসেস স্পন করার ওভারহেড এড়ানো যায় — বড় রিপোতে এটা ১০-১০০ গুণ দ্রুত হতে পারে single cat-file কল লুপের তুলনায়।

সারসংক্ষেপ টেবিল

লক্ষ্য

blob, tree — এই দুইটা অবজেক্ট শুধু plumbing কমান্ড দিয়ে ম্যানুয়ালি তৈরি করে দেখা, git add/git commit ছাড়াই (commit object পরের মডিউলের ল্যাবে যোগ হবে)।

ধাপ ১ — খালি রিপো

mkdir ~/gitlab-06 && cd ~/gitlab-06
git init

ধাপ ২ — দুইটা blob ম্যানুয়ালি তৈরি করা

BLOB1=$(echo "# My Project" | git hash-object -w --stdin)
BLOB2=$(echo "print('hello')" | git hash-object -w --stdin)
echo "README blob: $BLOB1"
echo "main.py blob: $BLOB2"

ধাপ ৩ — প্রতিটা যাচাই

git cat-file -t $BLOB1   # blob
git cat-file -p $BLOB1   # # My Project
git cat-file -s $BLOB2   # সাইজ বাইটে

ধাপ ৪ — একটা tree ম্যানুয়ালি তৈরি করা (mktree ব্যবহার করে)

printf "100644 blob %s\tREADME.md\n100644 blob %s\tmain.py\n" "$BLOB1" "$BLOB2" | git mktree
# একটা tree hash প্রিন্ট হবে

ধাপ ৫ — সেই tree যাচাই করা

TREE=$(printf "100644 blob %s\tREADME.md\n100644 blob %s\tmain.py\n" "$BLOB1" "$BLOB2" | git mktree)
git cat-file -p $TREE

100644 blob a1b2c3...    README.md
100644 blob d4e5f6...    main.py

ধাপ ৬ — dedup যাচাই করা

BLOB3=$(echo "# My Project" | git hash-object -w --stdin)
echo $BLOB1 $BLOB3
# হুবহু একই hash — কন্টেন্ট identical হওয়ায় নতুন object তৈরিই হয়নি

ধাপ ৭ — সবকিছু কতটা "invisible" তা দেখা

git status
# nothing to commit, working tree clean — অথচ .git/objects-এ ৩টা নতুন object আছে!
find .git/objects -type f | wc -l

এটাই গুরুত্বপূর্ণ শিক্ষা: object database-এ কিছু থাকা মানেই সেটা কোনো branch/HEAD থেকে reachable — এই দুটো ভিন্ন জিনিস (Module 7-এ refs আসার পর পরিষ্কার হবে)।

চ্যালেঞ্জ

git cat-file --batch-check --batch-all-objects চালিয়ে এই মুহূর্তে object database-এ কী কী object আছে তার সম্পূর্ণ তালিকা দেখুন।

প্র.১ — Content-addressable storage মানে কী, আর এটা Git-এ কীভাবে কাজ করে? উত্তর: এটা এমন একটা স্টোরেজ মডেল যেখানে একটা অবজেক্টের ঠিকানা (identifier) নির্ধারিত হয় তার কন্টেন্টের উপর ভিত্তি করে, নাম বা লোকেশনের উপর না। Git প্রতিটা অবজেক্টের কন্টেন্ট থেকে একটা SHA hash কম্পিউট করে সেটাকেই identifier হিসেবে ব্যবহার করে — একই কন্টেন্ট সবসময় একই hash দেয়।

প্র.২ — Blob অবজেক্টে ফাইলের নাম সংরক্ষিত থাকে কি? না থাকলে নাম কোথায় থাকে? উত্তর: না, blob শুধু raw ফাইল কন্টেন্ট রাখে, কোনো নাম/পাথ/পারমিশন না। ফাইলের নাম, mode, ও blob-এর রেফারেন্স সংরক্ষিত থাকে tree অবজেক্টে।

প্র.৩ — একটা tree object-এ একটা সাব-ডিরেক্টরি কীভাবে প্রতিনিধিত্ব হয়? উত্তর: সাব-ডিরেক্টরির জন্য tree-তে একটা এন্ট্রি থাকে যার mode 040000 এবং সেটা আরেকটা tree object-এর hash-কে পয়েন্ট করে (blob-কে না) — এভাবে recursively একটা tree of trees পুরো ডিরেক্টরি স্ট্রাকচার প্রতিনিধিত্ব করে।

প্র.৪ — Commit object-এর author আর committer ফিল্ড কখন ভিন্ন হয়ে যায়? উত্তর: git rebase, git cherry-pick, বা কেউ অন্যের patch apply করলে — মূল লেখক (author) অপরিবর্তিত থাকেন কিন্তু committer হয়ে যান যিনি সেই অপারেশনটা চালাচ্ছেন। সাধারণ git commit-এ দুটো একই থাকে।

প্র.৫ — git add আর git hash-object -w-এর সম্পর্ক কী? উত্তর: git add ইন্টার্নালি প্রতিটা staged ফাইলের জন্য hash-object -w-এর সমতুল্য একটা অপারেশন চালায় (blob object তৈরি করে), তারপর সেই hash index (staging area)-এ রেকর্ড করে। git add মূলত এই দুই কাজের একটা porcelain wrapper।

প্র.৬ — দুইটা সম্পূর্ণ ভিন্ন-নামের ফাইলে যদি হুবহু একই কন্টেন্ট থাকে, Git-এ স্টোরেজে কী ঘটে? উত্তর: দুটোই একই blob hash পাবে (content-addressable storage-এর কারণে), তাই Git-এর object database-এ সেই কন্টেন্টের একটাই কপি থাকবে — automatic deduplication, কোনো explicit ডি-ডুপ লজিক ছাড়াই।

• git hash-object (ফ্ল্যাগ ছাড়া, -w ছাড়া) hash প্রিন্ট করে কিন্তু object database-এ কিছুই লেখে না — অনেকে ভুলে যান -w ফ্ল্যাগ যোগ করতে, তারপর অবাক হন কেন git cat-file -p <সেই hash> বলে "fatal: Not a valid object name"।

• git cat-file -p <hash> কাজ করার জন্য hash-টা object database-এ থাকতেই হবে, শুধু syntactically সঠিক ৪০-ক্যারেক্টার স্ট্রিং হলেই চলবে না — একটা এলোমেলো কিন্তু সঠিক ফরম্যাটের hash দিলে "fatal: Not a valid object name" আসবে যদি সেটা আসলে কখনো তৈরি না হয়ে থাকে।

• একই কন্টেন্টের ফাইল বিভিন্ন লাইন-এন্ডিং (CRLF vs LF)-এ থাকলে ভিন্ন hash পাবে — Windows-এ তৈরি ফাইল (CRLF) আর Linux-এ তৈরি ফাইল (LF) কন্টেন্ট "দেখতে একই" হলেও বাইট-লেভেলে ভিন্ন, তাই blob hash-ও ভিন্ন হবে। এটাই cross-platform টিমে .gitattributes/core.autocrlf জরুরি হওয়ার মূল কারণ।

• শুধু object database-এ blob/tree object থাকা মানেই সেটা "নিরাপদ" না — কোনো branch/tag/HEAD থেকে reachable না হলে সেটা unreachable এবং পরবর্তী git gc চালালে চিরতরে মুছে যেতে পারে। Blob তৈরি করা মানে এখনো commit history-র অংশ হওয়া না, এটা শুধু "রিজার্ভ করা" — Module 7-এ commit-tree দিয়ে দেখা যাবে কীভাবে সত্যিকার reachability তৈরি হয়।

এই মডিউলে refs (refs/heads, refs/remotes, refs/tags) আসলে কী তা বোঝা — শুধু commit hash ধরে রাখা টেক্সট ফাইল; HEAD কী (symbolic ref বনাম detached); প্লাম্বিং কমান্ড git symbolic-ref, git update-ref, git show-ref, git for-each-ref; .git/index-এর গঠন (staging area-র বাইনারি রিপ্রেজেন্টেশন); git ls-files, git update-index; আর সবচেয়ে গুরুত্বপূর্ণ ল্যাব — git write-tree, git read-tree, git commit-tree দিয়ে সম্পূর্ণ প্লাম্বিং কমান্ড ব্যবহার করে হাতে একটা কমিট বানানো। মডিউলের শেষে একটা checkpoint gate — Phase 2 সম্পূর্ণভাবে আত্মস্থ হয়েছে কিনা তা যাচাই করার জন্য।

সংজ্ঞা

একটা ref (reference) Git-এ আশ্চর্যজনকভাবে সহজ একটা জিনিস — এটা শুধু একটা ফাইল যার ভেতরে একটা ৪০-ক্যারেক্টার (SHA-1) বা ৬৪-ক্যারেক্টার (SHA-256) commit hash লেখা থাকে। এইটুকুই। কোনো জাদু নেই।

সরাসরি দেখা

cat .git/refs/heads/main
# a1b2c3d4e5f6...   ← শুধু একটা commit hash, আর কিছু না

তিন ধরনের ref

কেন branch তৈরি করা এত সস্তা (instant)

git branch experimental
# ভেতরে ভেতরে যা ঘটে: .git/refs/heads/experimental ফাইল তৈরি হয়,
# HEAD যে commit-এ আছে সেই hash-টা কপি করে লেখা হয়

কোনো ফাইল কপি হয় না, কোনো tree/blob পুনরায় তৈরি হয় না — শুধু একটা ৪১-বাইট (hash + newline) টেক্সট ফাইল তৈরি হয়। এটাই ব্যাখ্যা করে Git-এ branch করা কেন SVN-এর branch করার চেয়ে হাজার গুণ দ্রুত।

Branch "মুভ" করা মানে কী

git commit -m "new change"

commit করলে আসলে HEAD যে branch-কে পয়েন্ট করছে, সেই branch ref ফাইলের ভেতরের hash আপডেট হয়ে যায় — নতুন commit-এর hash দিয়ে ওভাররাইট হয়। Branch একটা "movable pointer" মাত্র, commit-এর মতো immutable object না।

রিয়েল-লাইফ প্রভাব

git branch -d feature-x চালালে শুধু একটা টেক্সট ফাইল ডিলিট হয় — commit object গুলো object database-এ থেকেই যায় (যদি অন্য কোনো ref থেকে reachable থাকে), অন্যথায় unreachable হয়ে পরবর্তী git gc-তে সাফ হতে পারে। এই জন্যই ভুলে ডিলিট হওয়া branch প্রায়ই git reflog দিয়ে রিকভার করা যায় (কিছুদিনের মধ্যে)।

সাধারণ অবস্থা: HEAD একটা Symbolic Ref

HEAD সাধারণত সরাসরি একটা commit hash ধারণ করে না — বরং এটা একটা branch ref-কে পয়েন্ট করে, একে বলে symbolic ref।

cat .git/HEAD
# ref: refs/heads/main

এর মানে HEAD বলছে "আমি main branch-এর সাথে আছি" — main যেখানেই যাক (নতুন commit হলে), HEAD স্বয়ংক্রিয়ভাবে সেখানেই থাকবে।

Detached HEAD: সরাসরি একটা Commit-কে পয়েন্ট করা

git checkout a1b2c3d4
cat .git/HEAD
# a1b2c3d4e5f6...   ← এখন সরাসরি একটা commit hash, কোনো branch নাম না

এই অবস্থায় HEAD কোনো branch-এর সাথে যুক্ত না — এটাকে "detached" বলা হয়। কোনো branch নাম ছাড়া একটা নির্দিষ্ট commit-এ "ভ্রমণ" করা।

Detached HEAD-এ কমিট করলে কী হয় (বিপদ)

# detached অবস্থায়
echo "experiment" > test.txt
git add test.txt
git commit -m "trying something"

এই নতুন commit কোনো branch থেকে reachable না! যদি এখন git checkout main করেন, এই commit-টা "হারিয়ে" যাবে (আসলে হারায় না ঠিক তখনই — git reflog-এ থেকে যায় কিছুদিন, কিন্তু কোনো branch পয়েন্ট করছে না বলে দৃষ্টির আড়ালে চলে যায়, এবং একসময় git gc-তে unreachable হিসেবে সাফ হয়ে যেতে পারে)।

নিরাপদ ব্যবহার

git checkout a1b2c3d4
# পরীক্ষা করলাম, ফলাফল ভালো লাগলো
git switch -c new-feature
# এখন detached অবস্থার commit-টা একটা branch-এ "নোঙর" করলো, নিরাপদ হয়ে গেলো

রিয়েল-লাইফ ব্যবহার

পুরনো একটা commit-এ গিয়ে (git checkout <old-hash>) কোড কেমন ছিল দেখা, বিল্ড টেস্ট করা — এগুলো নিরাপদ যতক্ষণ না নতুন commit করেন সেই অবস্থায়। যদি সেখানে কাজ চালিয়ে যেতে হয়, সবসময় প্রথমে git switch -c <নতুন-branch-নাম> করে নেওয়া উচিত।

চারটা প্লাম্বিং কমান্ড যা রেফের সাথে সরাসরি কাজ করে

git symbolic-ref — HEAD কী পয়েন্ট করছে জানা/বদলানো

git symbolic-ref HEAD
# refs/heads/main

git symbolic-ref HEAD refs/heads/develop
# HEAD-কে সরাসরি develop branch-এ পয়েন্ট করানো (checkout ছাড়াই, working directory অপরিবর্তিত)

git update-ref — একটা ref-এর মান সরাসরি সেট করা

git update-ref refs/heads/main a1b2c3d4
# main branch ref-কে জোর করে নির্দিষ্ট commit hash-এ সেট করে দেয় — 'git commit' ছাড়াই

এটাই ভেতরে ভেতরে ব্যবহৃত হয় git reset --hard <commit>-এর মতো কমান্ডে — branch ref-কে নতুন hash-এ পয়েন্ট করানো।

git show-ref — সব ref-এর তালিকা ও তাদের hash

git show-ref
# a1b2c3... refs/heads/main
# d4e5f6... refs/heads/develop
# 7a8b9c... refs/tags/v1.0.0

git for-each-ref — কাস্টম ফরম্যাটে ref তালিকা (স্ক্রিপ্টিং-এর জন্য)

git for-each-ref --format='%(refname:short) %(objectname:short) %(committerdate:relative)' refs/heads/
# main    a1b2c3d  2 days ago
# develop d4e5f6a  5 hours ago

রিয়েল-লাইফ ব্যবহার

একটা deployment স্ক্রিপ্ট যেটা স্বয়ংক্রিয়ভাবে সর্বশেষ tag খুঁজে বের করে:

git for-each-ref --sort=-creatordate --format='%(refname:short)' refs/tags/ | head -1
# সর্বশেষ তৈরি হওয়া tag-এর নাম, সরাসরি স্ক্রিপ্টে ব্যবহারযোগ্য

আর git update-ref ব্যবহার হয় custom Git tooling-এ যেখানে একটা branch-কে নির্দিষ্ট commit-এ পয়েন্ট করাতে হয় কিন্তু working directory স্পর্শ না করেই (যেমন একটা bare mirror রিপো আপডেট করা)।

কেন এগুলো "plumbing"

এই কমান্ডগুলো কোনো safety-check করে না (যেমন uncommitted changes আছে কিনা), কোনো human-friendly আউটপুট দেয় না — এগুলো সরাসরি নিচের লেয়ারে কাজ করে, script/automation-এর জন্য ডিজাইন করা। git branch, git checkout-এর মতো porcelain কমান্ড এদেরই wrapper, অতিরিক্ত safety আর সুবিধাজনক ইন্টারফেসসহ।

Index আসলে কী

.git/index একটা বাইনারি ফাইল — এটাই "staging area"-র প্রকৃত বাস্তব রূপ। এতে প্রতিটা tracked ফাইলের একটা এন্ট্রি থাকে: ফাইলের পাথ, mode, blob hash, ফাইল সাইজ, mtime (last modified time), আর কিছু অতিরিক্ত মেটাডেটা (stage number, flags)।

কেন এটা প্রয়োজন (working directory আর HEAD-এর মাঝে একটা "তৃতীয় স্ন্যাপশট")

Index আসলে একটা প্রস্তাবিত পরবর্তী commit-এর tree-র flat প্রতিনিধিত্ব — git write-tree এই index থেকেই একটা প্রকৃত tree object বানায় (পরের ল্যাবে হাতে-কলমে দেখা যাবে)।

বাইনারি হওয়ার কারণ (পারফরম্যান্স)

একটা টেক্সট ফাইল হলে হাজার হাজার ফাইলের রিপোতে git status চালানো ধীর হয়ে যেত — প্রতিটা ফাইলের mtime/size চেক করে working directory-র সাথে দ্রুত তুলনা করার জন্য index বাইনারি ফরম্যাটে ডিজাইন করা, যাতে O(1)-এর কাছাকাছি lookup সম্ভব হয়।

সরাসরি দেখা (raw বাইনারি না, readable আকারে)

git ls-files --stage

100644 a1b2c3d4e5f6... 0	README.md
100644 d4e5f6a7b8c9... 0	main.py

এখানে 0 হলো "stage number" — সাধারণ অবস্থায় সবসময় ০ (কনফ্লিক্ট-মুক্ত)। Merge conflict-এর সময় একই ফাইলের একাধিক এন্ট্রি stage 1/2/3 নিয়ে দেখা যায় (base/ours/theirs) — এটা পরবর্তী merge মডিউলে বিস্তারিত হবে।

রিয়েল-লাইফ প্রভাব

git status দ্রুত হওয়ার মূল কারণ এই index-এর mtime ক্যাশিং — Git প্রথমে mtime তুলনা করে (সস্তা), শুধু mtime বদলেছে মনে হলে actual content hash আবার কম্পিউট করে (ব্যয়বহুল) যাচাই করতে ফাইলটা সত্যিই বদলেছে কিনা। এই optimization-ই বিশাল রিপোতে (লক্ষ লক্ষ ফাইল) git status-কে ব্যবহারযোগ্য গতিতে রাখে।

Index-এর কন্টেন্ট মানুষের পড়ার উপযোগী ফরম্যাটে

git ls-files index (আর ঐচ্ছিকভাবে working directory)-র বিভিন্ন দৃশ্য দেখানোর জন্য একটা multi-purpose plumbing কমান্ড।

বেসিক — সব tracked ফাইল

git ls-files
# README.md
# main.py
# src/utils.py

-s: স্টেজ তথ্যসহ (mode, hash, stage number)

git ls-files -s

100644 a1b2c3d4e5f6789... 0	README.md
100644 d4e5f6a7b8c9012... 0	main.py

এটাই সরাসরি index-এর raw এন্ট্রি — git cat-file-এর index-ভার্সন বলা যায়।

--others: untracked ফাইল দেখা

git ls-files --others
# temp_notes.txt
# debug.log

ডিফল্টে এটা .gitignore-এ থাকা ফাইলও untracked হিসেবে দেখায়, তাই সাধারণত --exclude-standard-এর সাথে ব্যবহার হয়:

git ls-files --others --exclude-standard
# শুধু সত্যিকার untracked ফাইল, .gitignore-এ থাকা ফাইল বাদে

--ignored: কোন ফাইলগুলো .gitignore-এর কারণে বাদ পড়ছে

git ls-files --others --ignored --exclude-standard
# node_modules/package.json
# __pycache__/module.pyc

এটা ডিবাগ করতে কাজে লাগে যখন সন্দেহ হয় একটা ফাইল ভুলবশত .gitignore-এর প্যাটার্নে পড়ে যাচ্ছে।

রিয়েল-লাইফ ব্যবহার

একটা pre-commit hook যেটা নিশ্চিত করে কোনো .env-স্টাইল ফাইল ভুলবশত tracked হয়ে যায়নি:

git ls-files | grep -E '\.env$' && echo "WARNING: .env is tracked!" && exit 1

সারসংক্ষেপ

সমস্যা: কিছু ফাইল "লোকালি বদলানো দরকার কিন্তু কমিট করা যাবে না"

কিছু ফাইল (যেমন লোকাল ডেভেলপমেন্ট config, settings.local.py) tracked থাকা দরকার (টিমের একটা টেমপ্লেট শেয়ার করার জন্য), কিন্তু প্রতিটা ডেভেলপার নিজের মতো বদলাবেন, আর সেই বদল কখনো commit হওয়া উচিত না। .gitignore এখানে কাজ করবে না কারণ ফাইলটা ইতিমধ্যে tracked।

--assume-unchanged: "এই ফাইলের দিকে তাকিও না, বদলায়নি ধরে নাও"

git update-index --assume-unchanged config/local_settings.py

এর পর থেকে git status/git diff এই ফাইলের পরিবর্তন সম্পূর্ণ উপেক্ষা করবে, যদিও ফাইলটা আসলে বদলে গেছে। ⚠️ এটা পারফরম্যান্স-অপ্টিমাইজেশন হিসেবে ডিজাইন করা (বড় ফাইল যেগুলোর mtime চেক ব্যয়বহুল), নিরাপদ "ignore" মেকানিজম হিসেবে না — Git নিজেই সতর্ক করে এটা silently override হয়ে যেতে পারে কিছু অপারেশনে।

# ফিরিয়ে আনতে
git update-index --no-assume-unchanged config/local_settings.py

--skip-worktree: আধুনিক, নির্ভরযোগ্য বিকল্প

git update-index --skip-worktree config/local_settings.py

এটা --assume-unchanged-এর চেয়ে বেশি নির্ভরযোগ্য এই নির্দিষ্ট ব্যবহারের জন্য — যখন ফাইলটা লোকালি বদলানো প্রত্যাশিত (উদ্দেশ্যমূলক), Git checkout/merge-এর সময় এই ফাইল overwrite করার চেষ্টা করবে না।

তুলনা

যাচাই করা কোন ফাইল flag করা আছে

git ls-files -v | grep '^S'
# S config/local_settings.py   ← 'S' মানে skip-worktree সেট আছে

রিয়েল-লাইফ দৃশ্যপট

একটা মাইক্রোসার্ভিস টেমপ্লেটে docker-compose.override.yml ফাইল কমিট করা আছে ডিফল্ট ভ্যালুসহ, কিন্তু প্রতিটা ডেভেলপার নিজের লোকাল পোর্ট/পাথ বদলাবেন — --skip-worktree দিয়ে এই ফাইলের লোকাল পরিবর্তন git status/accidental commit থেকে সুরক্ষিত রাখা যায়।

লক্ষ্য

git add/git commit — এই দুইটা porcelain কমান্ড একবারও ব্যবহার না করে, শুধু plumbing কমান্ড (hash-object, update-index, write-tree, commit-tree, update-ref) দিয়ে একটা সম্পূর্ণ বৈধ commit তৈরি করা এবং সেটাকে একটা branch-এ reachable বানানো। এটাই object model বোঝার চূড়ান্ত প্রমাণ।

ধাপ ১ — খালি রিপো

mkdir ~/gitlab-07-plumbing && cd ~/gitlab-07-plumbing
git init
git config user.email "rakib@example.com"
git config user.name "Rakib Hasan"

ধাপ ২ — blob object তৈরি করা (hash-object)

BLOB=$(echo "# Plumbing Demo" | git hash-object -w --stdin)
echo "Blob hash: $BLOB"

ধাপ ৩ — সেই blob-কে index-এ যোগ করা (update-index) — 'git add'-এর সমতুল্য কাজ ম্যানুয়ালি

git update-index --add --cacheinfo 100644,$BLOB,README.md
git ls-files -s
# 100644 <BLOB hash> 0	README.md   ← index-এ এন্ট্রি যোগ হলো

ধাপ ৪ — index থেকে একটা tree object তৈরি করা (write-tree)

TREE=$(git write-tree)
echo "Tree hash: $TREE"
git cat-file -p $TREE
# 100644 blob <BLOB hash>	README.md

ধাপ ৫ — সেই tree থেকে একটা commit object তৈরি করা (commit-tree) — কোনো parent ছাড়া (প্রথম commit)

COMMIT=$(echo "Initial commit via plumbing" | git commit-tree $TREE)
echo "Commit hash: $COMMIT"
git cat-file -p $COMMIT

tree <TREE hash>
author Rakib Hasan <rakib@example.com> ...
committer Rakib Hasan <rakib@example.com> ...

Initial commit via plumbing

ধাপ ৬ — এখনো এই commit কোনো branch থেকে reachable না

git log
# fatal: your current branch 'main' does not have any commits yet

ধাপ ৭ — একটা branch ref তৈরি করে "নোঙর" করা (update-ref)

git update-ref refs/heads/main $COMMIT
git log --oneline
# <short-hash> Initial commit via plumbing   ← এখন দেখা যাচ্ছে!
git status
# nothing to commit, working tree clean

ধাপ ৮ — দ্বিতীয় commit, parent-সহ (read-tree দিয়ে বিদ্যমান tree লোড করে পরিবর্তন)

BLOB2=$(echo "print('hello world')" | git hash-object -w --stdin)
git read-tree $TREE          # বর্তমান index-কে সেই tree-এর অবস্থায় রিসেট
git update-index --add --cacheinfo 100644,$BLOB2,main.py
TREE2=$(git write-tree)
COMMIT2=$(echo "Add main.py via plumbing" | git commit-tree $TREE2 -p $COMMIT)
git update-ref refs/heads/main $COMMIT2
git log --oneline
# দুইটা commit, স্বাভাবিক 'git log'-এই দেখা যাচ্ছে

চ্যালেঞ্জ

git checkout main -- . চালিয়ে working directory-তে ফাইল দুইটা আসল কিনা দেখুন — পুরো এই সময়ে working directory ছিল সম্পূর্ণ খালি, শুধু object database আর index ম্যানিপুলেট করা হয়েছিল।

প্র.১ — একটা ref (যেমন refs/heads/main) আসলে কী? উত্তর: এটা একটা সাধারণ টেক্সট ফাইল যার ভেতরে একটা commit hash লেখা থাকে — কোনো জটিল কাঠামো না। এই সরলতার কারণেই branch তৈরি করা তাৎক্ষণিক (instant) — শুধু একটা ছোট ফাইল লেখা হয়, কোনো content কপি হয় না।

প্র.২ — Symbolic ref আর detached HEAD-এর পার্থক্য কী? উত্তর: সাধারণ অবস্থায় HEAD একটা symbolic ref — এটা refs/heads/<branch>-কে পয়েন্ট করে, তাই branch এগোলে HEAD-ও স্বয়ংক্রিয়ভাবে এগোয়। Detached HEAD-এ HEAD সরাসরি একটা commit hash ধারণ করে, কোনো branch-এর সাথে যুক্ত না — এই অবস্থায় commit করলে সেই commit কোনো branch থেকে reachable হয় না।

প্র.৩ — .git/index ফাইলটা আসলে কী প্রতিনিধিত্ব করে? উত্তর: এটা staging area-র বাইনারি রিপ্রেজেন্টেশন — প্রস্তাবিত পরবর্তী commit-এর tree-র একটা flat তালিকা (প্রতিটা ফাইলের পাথ, mode, blob hash, mtime সহ)। git write-tree এই index থেকেই একটা প্রকৃত tree object তৈরি করে।

প্র.৪ — git update-ref কী করে, আর এটা কোন porcelain কমান্ডের ভেতরে ব্যবহৃত হয়? উত্তর: এটা একটা ref-কে সরাসরি একটা নির্দিষ্ট commit hash-এ সেট করে দেয়, কোনো safety check বা working-directory পরিবর্তন ছাড়াই। এটা ব্যবহৃত হয় git reset --hard, git branch -f-এর মতো কমান্ডের ভেতরে।

প্র.৫ — --assume-unchanged আর --skip-worktree-এর মধ্যে কোনটা ইচ্ছাকৃত লোকাল কাস্টমাইজেশনের জন্য বেশি নির্ভরযোগ্য, এবং কেন? উত্তর: --skip-worktree বেশি নির্ভরযোগ্য এই ব্যবহারের জন্য — এটা ঠিক এই উদ্দেশ্যেই ডিজাইন করা (ইচ্ছাকৃতভাবে tracked ফাইল লোকালি বদলানো), Git checkout/merge-এর সময় এই ফাইল overwrite করার চেষ্টা করে না। --assume-unchanged মূলত পারফরম্যান্স-অপ্টিমাইজেশনের জন্য, সহজে override/রিসেট হয়ে যেতে পারে।

প্র.৬ — git commit-এর ভেতরে ভেতরে কোন তিনটা plumbing অপারেশন ঘটে (সংক্ষেপে)? উত্তর: (১) write-tree — index থেকে একটা tree object তৈরি, (২) commit-tree — সেই tree + বর্তমান HEAD-কে parent হিসেবে নিয়ে একটা commit object তৈরি, (৩) update-ref — বর্তমান branch ref-কে নতুন commit hash-এ আপডেট করা।

• Detached HEAD-এ থাকা অবস্থায় করা commit তাৎক্ষণিকভাবে হারায় না, কিন্তু "reachable" থাকে না — git reflog কিছুদিনের জন্য এই commit-এর রেফারেন্স ধরে রাখে (ডিফল্টে ৩০-৯০ দিন), কিন্তু কোনো branch-এ "নোঙর" (git switch -c) না করলে একসময় git gc-তে unreachable object হিসেবে সাফ হয়ে যেতে পারে।

• git update-ref দিয়ে একটা branch ref-কে জোর করে অন্য commit-এ সেট করলে, working directory স্বয়ংক্রিয়ভাবে আপডেট হয় না — এটা git reset --hard-এর থেকে ভিন্ন (যেটা ref আপডেটের পাশাপাশি working directory-ও sync করে); শুধু update-ref চালালে working directory আর নতুন HEAD state-এর মধ্যে mismatch তৈরি হয়ে git status-এ প্রচুর "modified" ফাইল দেখাতে পারে।

• --assume-unchanged সেট করা একটা ফাইল remote branch থেকে merge/pull করার সময় নীরবে override/সমস্যা তৈরি করতে পারে — Git কখনো কখনো ফ্ল্যাগ উপেক্ষা করে ফাইল আপডেট করতে বাধ্য হয়, যার ফলে ঠিক কোন ফাইলে flag ছিল তা ভুলে গেলে অদ্ভুত merge আচরণ দেখা যায়।

• .git/index ফাইল সরাসরি টেক্সট এডিটরে খোলা বা ম্যানুয়ালি এডিট করার চেষ্টা করলে রিপো নষ্ট হয়ে যায় — এটা বাইনারি ফরম্যাট, শুধু git update-index/git read-tree-জাতীয় কমান্ড দিয়েই নিরাপদে বদলানো উচিত, কখনো raw ফাইল হিসেবে এডিট না করে।

আপনি কি পারবেন?

Phase 3-এ (branching ও merging) যাওয়ার আগে নিজেকে সৎভাবে যাচাই করুন — নিচের প্রতিটা প্রশ্নের উত্তর confidently দিতে পারলেই এগিয়ে যান:

• আপনি কি ব্যাখ্যা করতে পারবেন কেন git commit --amend আসলে একটা নতুন commit object তৈরি করে, পুরনোটা এডিট করে না — এবং এটা কেন push করা commit-এ বিপজ্জনক?
• আপনি কি হাতে-কলমে ব্যাখ্যা করতে পারবেন git add চালানোর সময় ভেতরে ভেতরে ঠিক কোন plumbing অপারেশনগুলো ঘটে (blob তৈরি + index আপডেট)?
• আপনি কি বলতে পারবেন কেন দুইটা সম্পূর্ণ ভিন্ন-নামের, ভিন্ন-পাথের ফাইল, একই কন্টেন্ট থাকলে, object database-এ একবারই সংরক্ষিত হয়?
• আপনি কি পার্থক্য করতে পারবেন branch ref (movable pointer, একটা টেক্সট ফাইল) আর commit object (immutable, permanent)-এর মধ্যে?
• আপনি কি ব্যাখ্যা করতে পারবেন detached HEAD অবস্থায় করা commit কেন "হারিয়ে যাওয়ার" ঝুঁকিতে থাকে?
• আপনি কি নিজে থেকে, git add/git commit ব্যবহার না করে, শুধু hash-object, write-tree, commit-tree, update-ref দিয়ে একটা বৈধ commit তৈরি করতে পারবেন?

কেন এই ফেজ একটা বাধ্যতামূলক গেট

এই ছয়টা প্রশ্নের প্রতিটাই সরাসরি Phase 3+-এর প্রতিটা টপিকের ভিত্তি — branching মানে নতুন ref তৈরি করা, merging মানে একাধিক parent-সহ commit তৈরি করা, rebase মানে commit-কে নতুন parent দিয়ে "replay" করে নতুন hash তৈরি করা, reflog মানে ref-এর ইতিহাস ট্র্যাক করা। এই object/ref/index মডেলটা মুখস্থ না হয়ে সত্যিকার অর্থে অন্তর্গত না হলে, পরের প্রতিটা ফেজ শুধু "এই পরিস্থিতিতে এই কমান্ড টাইপ করো" ধরনের প্যাটার্ন-মেমোরাইজেশন হয়ে থাকবে, প্রকৃত বোঝাপড়া হবে না।

যদি উপরের যেকোনো একটা প্রশ্নে আটকে যান, Module 6 ও 7-এর লিফগুলো, বিশেষ করে প্লাম্বিং ল্যাবটা, আবার করে দেখুন — এগিয়ে যাওয়ার আগে এই ভিত্তিটা শক্ত হওয়া জরুরি।

এই মডিউলে দেখা হবে object database বাস্তবে ডিস্কে কীভাবে efficient রাখা হয়: loose object বনাম packfile (এবং delta compression), git gc/git repack দিয়ে maintenance, git verify-pack/git index-pack/git unpack-objects দিয়ে packfile-এর ভেতরে দেখা, git count-objects দিয়ে ডায়াগনস্টিক, আর git fsck/git prune দিয়ে ইন্টেগ্রিটি চেক ও পরিষ্কার করা।

Loose Object: প্রতিটা object একটা আলাদা ফাইল

এখন পর্যন্ত আমরা যা দেখেছি — git hash-object -w চালালে .git/objects/xx/yyyy... — একটা আলাদা zlib-compressed ফাইল তৈরি হয়। এটাকে বলে loose object। প্রতিটা blob/tree/commit আলাদা ফাইল।

সমস্যা: হাজার হাজার ছোট ফাইল

একটা সক্রিয় প্রজেক্টে হাজার হাজার commit মানে হাজার হাজার loose object ফাইল — প্রতিটা ফাইলের নিজস্ব filesystem overhead (inode, metadata), আর অনেক ছোট ফাইল ফাইলসিস্টেম I/O-কে ধীর করে দেয়।

সমাধান: Packfile

একটা packfile অনেকগুলো object-কে একটা মাত্র ফাইলে একসাথে সংকুচিত করে রাখে, সাথে একটা index ফাইল (.idx) যা দ্রুত lookup সম্ভব করে (কোন object কোথায় আছে সেই ফাইলের ভেতরে)।

ls .git/objects/pack/
# pack-a1b2c3....pack   (আসল ডেটা)
# pack-a1b2c3....idx    (দ্রুত lookup index)

Delta Compression — প্যাকিং-এর আসল জাদু

Packfile শুধু জিপ-স্টাইল কম্প্রেশন করে না — এটা similar object-দের মধ্যে delta (পার্থক্য) স্টোর করে। যদি দুইটা blob প্রায় একই রকম (যেমন একই ফাইলের দুইটা কাছাকাছি ভার্সন), Git একটাকে পূর্ণরূপে (base) রাখে, আরেকটাকে শুধু পার্থক্য (delta) হিসেবে রাখে — উল্লেখযোগ্যভাবে জায়গা বাঁচায়।

গুরুত্বপূর্ণ: এটা loose object সংরক্ষণের মূল নীতি (snapshot-based, delta না) ভঙ্গ করে না — delta compression শুধু স্টোরেজ-লেভেল অপ্টিমাইজেশন, conceptual মডেলে প্রতিটা commit এখনো একটা পূর্ণ, স্বতন্ত্র snapshot। প্রয়োজনে (cat-file -p) Git স্বচ্ছভাবে delta থেকে পূর্ণ কন্টেন্ট পুনর্গঠন করে দেয়, ইউজারের কাছে এই delta সম্পূর্ণ transparent।

তুলনা টেবিল

রিয়েল-লাইফ প্রভাব

Linux kernel-এর মতো বিশাল রিপো (কয়েক লাখ commit) packed অবস্থায় কয়েক GB, কিন্তু loose object হিসেবে থাকলে এটা কয়েকগুণ বড় হতো এবং clone/fetch অনেক ধীর হতো। git push/git fetch-এর সময় নেটওয়ার্কে যা পাঠানো হয় তা-ও একটা packfile — যেটা দ্রুত ট্রান্সমিশনের জন্য অপ্টিমাইজ করা।

git gc — Garbage Collection, কিন্তু শুধু "ময়লা সাফ" না

git gc আসলে দুটো কাজ একসাথে করে: (১) loose object-দের একত্রিত করে নতুন packfile বানায় (পারফরম্যান্স), (২) unreachable object (কোনো ref/reflog থেকে পৌঁছানো যায় না এমন object) — নির্দিষ্ট সময় (ডিফল্ট ২ সপ্তাহ) পার হয়ে গেলে মুছে ফেলে।

git gc
# Auto packing the repository...

স্বয়ংক্রিয় ট্রিগার

Git স্বয়ংক্রিয়ভাবে git gc --auto চালায় যখন loose object সংখ্যা একটা থ্রেশহোল্ড (ডিফল্ট ~৬৭০০) পার হয় — সাধারণত ম্যানুয়ালি git gc চালানোর দরকার হয় না, কিন্তু বড় অপারেশনের (বিশাল history rewrite) পর ম্যানুয়ালি চালানো উপকারী হতে পারে।

--aggressive — আরও গভীর অপ্টিমাইজেশন

git gc --aggressive

এটা delta compression-এর জন্য আরও ব্যাপক অনুসন্ধান করে (বেশি candidate base object পরীক্ষা করে) — ফলাফল ছোট packfile, কিন্তু চালাতে অনেক বেশি সময় লাগে। সাধারণত এটা মাঝেমধ্যে (মাসে একবার, বড় রিপোতে) চালানোর জন্য, নিয়মিত ওয়ার্কফ্লোর অংশ না।

--prune=now — সাথে সাথে unreachable object মুছে ফেলা

git gc --prune=now

ডিফল্ট grace period (২ সপ্তাহ) উপেক্ষা করে তাৎক্ষণিকভাবে সব unreachable object মুছে ফেলে। ⚠️ সতর্কতা: এর মানে git reflog দিয়ে অতি সাম্প্রতিক "হারানো" commit রিকভার করার সুযোগও চলে যেতে পারে যদি সেই grace period পার হওয়ার আগে prune করেন।

git repack — শুধু repacking, gc-র বাকি কাজ ছাড়া

git repack -a -d
# -a: সব object একটা নতুন packfile-এ একত্রিত করা
# -d: পুরনো redundant packfile ডিলিট করা

git gc ভেতরে git repack-ই ব্যবহার করে, কিন্তু repack সরাসরি চালালে fine-grained control পাওয়া যায় (কবে prune হবে তা আলাদাভাবে নিয়ন্ত্রণ করা যায়)।

রিয়েল-লাইফ ওয়ার্কফ্লো

একটা বড় git filter-repo/BFG অপারেশনের পর (history থেকে বড় ফাইল/secret সরানো) — পুরনো object গুলো unreachable হয়ে যায় কিন্তু ডিস্কে থেকে যায় যতক্ষণ না git gc --prune=now --aggressive চালানো হয়। রিপোর সাইজ আসলে না কমা পর্যন্ত এই ধাপ ভুলে গেলে মনে হবে history rewrite "কাজ করেনি"।

git verify-pack — packfile-এর ইন্টেগ্রিটি ও কন্টেন্ট যাচাই

git verify-pack -v .git/objects/pack/pack-a1b2c3....idx

a1b2c3d4... commit 245 178 12
d4e5f6a7... tree   89  67  190
7a8b9c1d... blob   1847 502 257 1 d4e5f6a7...

কলামগুলো: hash, type, uncompressed size, compressed size, offset, (delta হলে) depth ও base object hash। -v দিয়ে প্রতিটা object লিস্ট হয় এবং শেষে chain integrity ভেরিফাই করা হয় — কোনো corruption থাকলে এখানে ধরা পড়বে।

git index-pack — একটা .pack ফাইল থেকে .idx রিজেনারেট করা

git index-pack pack-a1b2c3....pack

যদি কোনোভাবে .idx ফাইল হারিয়ে যায় বা করাপ্ট হয়ে যায় (কিন্তু .pack ফাইল অক্ষত), এই কমান্ড দিয়ে .pack ফাইল স্ক্যান করে আবার .idx তৈরি করা যায় — একটা রিকভারি টুল।

git unpack-objects — একটা packfile-কে আবার loose object-এ ভেঙে ফেলা

git unpack-objects < pack-a1b2c3....pack

এটা বিরল কিন্তু ডিবাগিং-এ কাজে লাগে — একটা packfile-এর ভেতরের প্রতিটা object আলাদা loose ফাইলে বের করে আনলে সেগুলো আলাদাভাবে পরীক্ষা করা সহজ হয়ে যায় (cat-file, hash যাচাই একটা একটা করে)।

রিয়েল-লাইফ দৃশ্যপট

একটা transferred/ডাউনলোড করা packfile করাপ্ট কিনা সন্দেহ হলে, প্রথমে git verify-pack -v চালিয়ে দেখা হয় — যদি ইন্টেগ্রিটি এরর আসে, git index-pack দিয়ে রিজেনারেট চেষ্টা করা যায়; সম্পূর্ণ করাপ্ট হলে সেই source থেকে আবার fetch করাই একমাত্র সমাধান।

সারসংক্ষেপ

দ্রুত ডায়াগনস্টিক

git count-objects -v

count: 42
size: 168
in-pack: 15230
packs: 1
size-pack: 48920
prune-packable: 3
garbage: 0
size-garbage: 0

প্রতিটা ফিল্ডের অর্থ

• count — কতগুলো loose object আছে (এখনো packfile-এ যায়নি)।
• size — সেই loose object গুলোর মোট সাইজ (KB-তে)।
• in-pack — packfile-এর ভেতরে থাকা object সংখ্যা।
• packs — কতগুলো packfile আছে।
• size-pack — packfile গুলোর মোট সাইজ (KB-তে)।
• prune-packable — এমন loose object যেগুলো ইতিমধ্যে কোনো packfile-এও আছে, তাই নিরাপদে prune করা যায়।
• garbage — করাপ্টেড বা অপ্রয়োজনীয় ফাইল object ডিরেক্টরিতে।

কেন এটা ব্যবহার করবেন

count > 0 অনেক বেশি হলে (হাজার+) বোঝায় রিপোতে অনেক নতুন কাজ হয়েছে কিন্তু সাম্প্রতিক git gc চলেনি — git status/git log-এর গতিতে সামান্য প্রভাব ফেলতে পারে।

# gc চালানোর আগে-পরে তুলনা
git count-objects -v   # count: 5000+
git gc
git count-objects -v   # count: 0, in-pack বৃদ্ধি পেয়েছে

রিয়েল-লাইফ ব্যবহার

একটা বড় CI সার্ভারে যেখানে একই রিপো বারবার fetch/rebuild হয়, git count-objects -v দিয়ে পিরিয়ডিক্যালি চেক করে দেখা যায় রিপো "ফুলে" যাচ্ছে কিনা (loose object জমছে কিনা), আর সেই অনুযায়ী একটা scheduled git gc cron job সেট করা যায় ডিস্ক স্পেস ও I/O পারফরম্যান্স নিয়ন্ত্রণে রাখতে।

এক-লাইন সারাংশ

git count-objects -v হলো রিপোর "স্বাস্থ্য পরীক্ষা" — কতটা ময়লা (loose object) জমেছে, packing কতটা efficient, তার একটা তাৎক্ষণিক স্ন্যাপশট।

git fsck — Filesystem Check, object ডেটাবেজের ইন্টেগ্রিটি যাচাই

git fsck

এটা পুরো object database ট্র্যাভার্স করে যাচাই করে: প্রতিটা object-এর hash তার কন্টেন্টের সাথে মেলে কিনা (corruption ধরা), সব রেফারেন্স করা object (tree-র ভেতরের blob hash, commit-এর parent hash) আসলে অস্তিত্বশীল কিনা (dangling reference ধরা)।

git fsck --full
# dangling commit a1b2c3d4...
# dangling blob e5f6a7b8...

dangling object মানে কী

Dangling মানে object database-এ আছে, কিন্তু কোনো অন্য object থেকে reference করা না (একটা orphan commit, বা কোনো tree-তে যোগ না হওয়া blob) — সাধারণত এগুলো তৈরি হয় git reset --hard, amend, বা rebase-এর পর পুরনো commit "রেখে যাওয়ার" ফলে।

--lost-found — dangling commit উদ্ধার করা

git fsck --lost-found
ls .git/lost-found/commit/
# a1b2c3d4...

এটা প্রতিটা dangling commit-কে .git/lost-found/-এ একটা ফাইল হিসেবে রাখে, যা থেকে ম্যানুয়ালি ইনস্পেক্ট বা রিকভার করা যায়:

git show a1b2c3d4
# সেই কমিটের কন্টেন্ট দেখা যাবে
git branch recovered-work a1b2c3d4
# একটা branch দিয়ে আবার reachable বানানো

git prune — dangling/unreachable object চিরতরে মুছে ফেলা

git prune
# ডিফল্ট grace period (২ সপ্তাহ) পার হওয়া unreachable object মুছে দেয়
git prune --dry-run
# আসলে না মুছে শুধু কী মুছা হতো তার তালিকা দেখায় — নিরাপদ প্রথম ধাপ

⚠️ git gc-এর ভেতরেও prune চলে, তাই আলাদাভাবে git prune কমই সরাসরি চালানো হয় — সাধারণত git gc-এর সাথে integrated থাকে।

রিয়েল-লাইফ দৃশ্যপট: রিকভারি

একজন ডেভেলপার ভুলে git reset --hard HEAD~3 চালিয়ে ৩টা commit "হারিয়ে ফেলেছেন" (আসলে unreachable হয়ে গেছে, ডিলিট হয়নি এখনই):

git fsck --lost-found
# dangling commit <hash>   ← হারানো কাজ এখানে!
git branch recovered <hash>

git reflog সাধারণত এই ধরনের রিকভারির জন্য আরও সহজ পথ (পরবর্তী ফেজে বিস্তারিত), কিন্তু git fsck --lost-found একটা fallback যখন reflog-ও কোনো কারণে সাহায্য করছে না।

সারসংক্ষেপ

লক্ষ্য

Loose object তৈরি করে, count-objects দিয়ে দেখে, gc দিয়ে pack করে, তারপর একটা dangling commit ইচ্ছাকৃতভাবে তৈরি করে fsck দিয়ে রিকভার করা।

ধাপ ১ — অনেক loose object তৈরি করা

mkdir ~/gitlab-08 && cd ~/gitlab-08
git init
for i in $(seq 1 30); do
  echo "content $i" > "file$i.txt"
  git add "file$i.txt"
  git commit -m "add file$i.txt"
done

ধাপ ২ — packing-এর আগে অবস্থা দেখা

git count-objects -v
# count: বেশ কিছু (৩০টা commit × তিনটা object টাইপ)
# in-pack: 0 (এখনো কোনো pack হয়নি, ছোট রিপো বলে auto-gc trigger হয়নি)

ধাপ ৩ — ম্যানুয়ালি gc চালানো

git gc
git count-objects -v
# count: 0 (loose object সব pack হয়ে গেছে)
# in-pack: আগের সমান সংখ্যা
ls .git/objects/pack/
# pack-....pack এবং pack-....idx দেখা যাবে

ধাপ ৪ — packfile ইন্টেগ্রিটি যাচাই

git verify-pack -v .git/objects/pack/*.idx | tail -5

ধাপ ৫ — ইচ্ছাকৃতভাবে একটা dangling commit তৈরি করা

echo "important work" > wip.txt
git add wip.txt
git commit -m "WIP: important experiment"
git reset --hard HEAD~1
# 'important experiment' commit-টা এখন unreachable, কিন্তু object database-এ আছে

ধাপ ৬ — fsck দিয়ে খুঁজে বের করা ও রিকভার করা

git fsck --lost-found
# dangling commit <hash> দেখাবে
HASH=$(git fsck --lost-found | grep "dangling commit" | awk '{print $3}')
git show $HASH --stat
git branch recovered-wip $HASH
git log recovered-wip --oneline -1
# "WIP: important experiment" — রিকভার হয়ে গেলো!

চ্যালেঞ্জ

git prune --dry-run চালিয়ে দেখুন এখন আর কোনো (recovered-wip branch করার পর) dangling object prune-এর তালিকায় আসছে কিনা — branch তৈরি করার ফলে সেটা আবার reachable হয়ে গেছে কিনা যাচাই করুন।

প্র.১ — Loose object আর packfile-এর মধ্যে পার্থক্য কী? উত্তর: Loose object প্রতিটা আলাদা zlib-compressed ফাইল হিসেবে .git/objects/xx/yyyy পাথে থাকে। Packfile অনেক object-কে একটা ফাইলে একত্রিত করে delta compression প্রয়োগ করে, সাথে একটা .idx ফাইল দ্রুত lookup-এর জন্য — অনেক বেশি স্পেস-এফিশিয়েন্ট।

প্র.২ — Delta compression কি Git-এর snapshot মডেল ভঙ্গ করে? উত্তর: না। Delta compression শুধু স্টোরেজ-লেভেল অপ্টিমাইজেশন — conceptually প্রতিটা commit এখনো একটা পূর্ণ, স্বতন্ত্র snapshot। প্রয়োজনে Git স্বচ্ছভাবে delta থেকে পূর্ণ কন্টেন্ট পুনর্গঠন করে দেয়, ইউজার কখনো "delta" সরাসরি দেখেন না।

প্র.৩ — git gc ঠিক কী কী কাজ করে? উত্তর: (১) loose object-দের একত্রিত করে নতুন packfile তৈরি করে (পারফরম্যান্স), (২) grace period পার হওয়া unreachable object মুছে ফেলে (prune)। এছাড়া reflog expire এবং অন্যান্য housekeeping কাজও করে।

প্র.৪ — --prune=now ব্যবহারে কী ঝুঁকি আছে? উত্তর: এটা ডিফল্ট grace period (সাধারণত ২ সপ্তাহ) উপেক্ষা করে তাৎক্ষণিকভাবে সব unreachable object মুছে ফেলে — এর ফলে সাম্প্রতিক ভুলবশত "হারানো" (unreachable হওয়া) commit git reflog/git fsck --lost-found দিয়ে রিকভার করার সুযোগও হারিয়ে যেতে পারে।

প্র.৫ — Dangling commit কী, এবং এটা কীভাবে তৈরি হয়? উত্তর: Dangling commit হলো object database-এ থাকা কিন্তু কোনো ref/অন্য object থেকে reference করা না এমন একটা commit। সাধারণত git reset --hard, --amend, বা rebase-এর পর পুরনো commit reachable না থাকলে এটা ঘটে।

প্র.৬ — git fsck --lost-found দিয়ে কীভাবে একটা ভুলবশত হারানো commit রিকভার করবেন? উত্তর: git fsck --lost-found চালিয়ে dangling commit-এর hash খুঁজে বের করে, তারপর git branch <নতুন-নাম> <hash> চালিয়ে সেটাকে একটা branch-এর মাধ্যমে আবার reachable বানিয়ে সম্পূর্ণ কাজ উদ্ধার করা যায়।

• git gc --aggressive "আরও ভালো" মনে হলেও নিয়মিত ব্যবহারের জন্য না — এটা অনেক বেশি সময় নেয় (বড় রিপোতে ঘণ্টার হিসেবে) এবং সাধারণ git gc-এর তুলনায় সবসময় উল্লেখযোগ্যভাবে ছোট packfile না-ও দিতে পারে; বেশিরভাগ ক্ষেত্রে ডিফল্ট git gc-ই যথেষ্ট, --aggressive কালেভদ্রে (major history cleanup-এর পর) ব্যবহার করা উচিত।

• git prune সরাসরি চালানো বিপজ্জনক হতে পারে যদি সম্প্রতি কোনো অপারেশন চলমান থাকে (যেমন একটা rebase বা push মাঝপথে) — চলমান অপারেশনের অস্থায়ী object এখনো কোনো ref-এ যুক্ত না হলে সেগুলো ভুলবশত unreachable ধরে prune হয়ে যেতে পারে; এই কারণে git gc/prune সাধারণত অন্য কোনো Git অপারেশন চলাকালীন এড়িয়ে চলা উচিত।

• git count-objects-এর size আর size-pack ফিল্ড সরাসরি ডিস্ক ইউসেজ (du) থেকে সামান্য ভিন্ন হতে পারে — filesystem block size, sparse ফাইল, আর অতিরিক্ত মেটাডেটার কারণে; সঠিক ডিস্ক ব্যবহারের জন্য du -sh .git ব্যবহার করা ভালো, count-objects-কে শুধু object-কাউন্ট ট্রেন্ড দেখার জন্য ব্যবহার করা উচিত।

• git fsck ডিফল্টে reflog-এ থাকা dangling commit রিপোর্ট করে না (--unreachable/--no-reflog ছাড়া) — reflog নিজেই সেই object-কে সাময়িকভাবে "reachable" ধরে রাখে, তাই সাম্প্রতিক history-rewrite-এর পরপরই git fsck চালালে প্রত্যাশিত সব dangling object নাও দেখাতে পারে, যতক্ষণ না reflog expire হয়।

Phase 2 পর্যন্ত আমরা মূলত single-branch, linear ইতিহাস নিয়ে কাজ করেছি। কিন্তু বাস্তব প্রোডাকশন ওয়ার্কফ্লো — feature branch, hotfix branch, release branch — এই সবকিছুর ভিত্তি হলো Git-এর branch ও ref model। এই Phase-এ দুটো মডিউল: প্রথমে Module 9-এ branch তৈরি/মুছা/rename/tracking-এর প্রতিটা কমান্ড এবং কেন branch এত সস্তা অপারেশন সেটা ref-level-এ বোঝা হবে। তারপর Module 10-এ detached HEAD আর orphan branch — দুটো এমন state যেগুলো নতুনদের কাছে ভীতিকর মনে হয়, কিন্তু আসলে Git-এর ref model বুঝলে এগুলো সম্পূর্ণ predictable এবং নিরাপদ। এই Phase শেষে branch একটা "ম্যাজিক" মনে হবে না — এটা হবে শুধু একটা ছোট ফাইলে লেখা একটা commit hash।

Branch নিয়ে দৈনন্দিন কাজ — তৈরি করা, দেখা, নাম বদলানো, মুছে ফেলা, আর remote-এর সাথে ট্র্যাক করা — এই মডিউলের মূল বিষয়। কভার হবে: git branch-এর প্রতিটা লিস্টিং ফ্ল্যাগ, ref model-এ branch আসলে কী (একটা ৪১-বাইট ফাইল), git switch -c/git checkout -b, rename/delete, tracking branches, আর কেন ২০১৯ সালে switch/restore আলাদা কমান্ড হিসেবে আনা হলো।

branch তালিকা দেখা

git branch কমান্ড কোনো আর্গুমেন্ট ছাড়া চালালে শুধু local branch-গুলোর তালিকা দেখায়, বর্তমান branch-এর সামনে একটা * চিহ্ন দিয়ে। কিন্তু এর ফ্ল্যাগগুলোই আসল শক্তি:

• -a — local ও remote-tracking branch দুটোই দেখায় (remotes/origin/main সহ)।
• -r — শুধু remote-tracking branch দেখায়।
• -v / -vv — প্রতিটা branch-এর শেষ commit hash ও subject দেখায়; -vv আরও দেখায় কোন upstream branch ট্র্যাক করছে এবং ahead/behind সংখ্যা।
• --merged / --no-merged — বর্তমান branch-এ merge হয়ে গেছে (বা হয়নি) এমন branch ফিল্টার করে।
• --contains <commit> — যে branch-গুলোর ইতিহাসে একটা নির্দিষ্ট commit আছে সেগুলো দেখায়।
• --points-at <commit> — যে branch-এর tip ঠিক সেই commit-এ আছে (contains-এর চেয়ে সংকীর্ণ)।

রিয়েল-লাইফ ব্যবহার

PR merge হওয়ার পর স্থানীয়ভাবে জমে থাকা মৃত feature branch পরিষ্কার করার সময় সবচেয়ে বেশি ব্যবহৃত প্যাটার্ন:

git branch --merged main | grep -v '^\* main$'
# feature/login-page
# feature/old-experiment

git branch -vv
# main                7a1f9c2 [origin/main] fix: payment retry logic
# feature/login-page  3b8e0a1 [origin/feature/login-page: ahead 2] add OTP flow

-vv-এর আউটপুটে ahead 2 দেখলে বোঝা যায় লোকাল branch-এ ২টা commit আছে যেগুলো এখনো push হয়নি। --contains <hash> দিয়ে সহজেই বের করা যায় একটা নির্দিষ্ট bug-fix commit কোন কোন branch-এ ইতিমধ্যে পৌঁছেছে — release ম্যানেজমেন্টে খুবই দরকারি প্রশ্ন।

branch একটা ডেটা স্ট্রাকচার না, একটা পয়েন্টার

Git-এ একটা branch আসলে .git/refs/heads/<name> লোকেশনে একটা সাধারণ টেক্সট ফাইল, যার ভেতরে থাকে একটামাত্র commit-এর ৪০-hex-character SHA-1 hash (নতুন SHA-256 রিপোতে ৬৪ ক্যারেক্টার) প্লাস একটা newline — মোট ৪১ বাইট।

cat .git/refs/heads/main
# 7a1f9c2e4b8d3f1a0c9e7b6d5a4c3b2a1f0e9d8c

git show-ref refs/heads/main
# 7a1f9c2e4b8d3f1a0c9e7b6d5a4c3b2a1f0e9d8c refs/heads/main

কেন এটা এত গুরুত্বপূর্ণ

Git-এর object model-এ commit, tree, blob — এই সবকিছু কন্টেন্ট-অ্যাড্রেসেবল আর ইমিউটেবল object। কিন্তু কোনো object নিজে থেকে "আমি main branch-এর tip" — এমন কিছু জানে না। branch ref-টাই সেই তথ্য ধরে রাখে — এটা একটা mutable পয়েন্টার যা কোন commit-এর দিকে নির্দেশ করছে সেটা বদলাতে থাকে।

branch তৈরি করা মানে তাই কোনো ফাইল কপি করা, কোনো tree ট্রাভার্স করা, বা কোনো নতুন object বানানো না — শুধু একটা ৪১-বাইট ফাইল লেখা। এইজন্যই:

time git branch experiment
# real    0m0.003s

কার্যত instant। এর সাথে তুলনা করুন Subversion-এর মতো সিস্টেমের সাথে, যেখানে branch মানে পুরো ডিরেক্টরি ট্রি সার্ভারে কপি করা (svn copy trunk branches/experiment) — সেটা রিপোর সাইজের সাথে সমানুপাতিক সময় নেয়। Git-এর সস্তা branch-ই কারণ কেন Git কালচারে প্রতিটা ছোট ফিচারের জন্যও আলাদা branch বানানো স্বাভাবিক অভ্যাস — কোনো storage বা সময়ের খরচ নেই।

HEAD কীভাবে এর সাথে যুক্ত

.git/HEAD ফাইলে সাধারণত থাকে ref: refs/heads/main — অর্থাৎ HEAD নিজেও সরাসরি hash ধরে না, এটা currently checked-out branch ref-কে পয়েন্ট করে। commit করলে আসলে যা ঘটে: নতুন commit object তৈরি হয়, তারপর বর্তমান branch ref (যেটা HEAD পয়েন্ট করছে) আপডেট হয়ে নতুন commit hash-টা লেখা হয়। এই দুই-স্তরের indirection (HEAD → branch ref → commit) পরের মডিউলে detached HEAD বোঝার চাবিকাঠি।

তৈরি করা

git branch feature/otp-login          # branch তৈরি, কিন্তু HEAD এখনো পুরনো branch-এই থাকে
git switch -c feature/otp-login       # তৈরি + সাথে সাথে switch (আধুনিক)
git checkout -b feature/otp-login     # একই কাজ, পুরনো সিনট্যাক্স

-c (create) ফ্ল্যাগ ছাড়া git switch feature/otp-login চালালে existing branch-এ switch করার চেষ্টা হয়, না থাকলে error দেবে।

Rename ও Delete

git branch -m old-name new-name   # rename (বর্তমান branch হলে -m শুধুই যথেষ্ট, নাম না দিলে current branch rename হয়)
git branch -d feature/done        # safe delete — main-এ merge না হলে refuse করবে
git branch -D feature/abandoned   # force delete — merge না হলেও মুছে ফেলবে, commit হারানোর ঝুঁকি

-d আসলে ভেতরে চেক করে branch-টা reachable কিনা HEAD বা upstream থেকে — merge না হওয়া কাজ থাকলে Git সতর্ক করে "not fully merged" বলে। -D সেই চেক বাইপাস করে — dangling commit তৈরি হতে পারে (Phase 4-এর Reflog মডিউলে রিকভারি দেখানো হবে)।

Tracking branch (upstream) সেট করা

git push -u origin feature/otp-login          # push-এর সাথে upstream সেট
git branch --set-upstream-to=origin/main main # existing branch-এ পরে upstream সেট
git branch --unset-upstream                    # ট্র্যাকিং সম্পর্ক ভেঙে ফেলা

Tracking branch মানে local branch refs/heads/feature/otp-login-এর সাথে remote-tracking ref refs/remotes/origin/feature/otp-login-এর একটা সম্পর্ক রেকর্ড করা .git/config-এ (branch.<name>.remote ও branch.<name>.merge কী হিসেবে)। এই সম্পর্ক থাকলেই git pull/git push কোনো আর্গুমেন্ট ছাড়া কাজ করে, আর -vv আউটপুটে ahead/behead সংখ্যা দেখায়।

পুরনো সমস্যা: checkout ছিলো তিনটা ভিন্ন কাজের জন্য ওভারলোডেড

Git 2.23 (আগস্ট ২০১৯)-এর আগে git checkout একাই তিনটা সম্পূর্ণ ভিন্ন কাজ করতো:

1. Branch switch করা: git checkout main
2. Working directory-তে ফাইল restore করা: git checkout -- file.py
3. Detached HEAD-এ যাওয়া: git checkout <commit-hash>

এই ওভারলোডিং বিপজ্জনক ছিলো কারণ git checkout <name> — এখানে <name> একটা branch হলে switch হবে, কিন্তু একটা ফাইলের নাম হলে (ভুল টাইপ করলে) সেই ফাইলের uncommitted পরিবর্তন নিঃশব্দে মুছে working-tree ভার্সন দিয়ে replace করে দিতো — কোনো নিশ্চিতকরণ ছাড়াই।

সমাধান: দায়িত্ব ভাগ করা

Git 2.23-এ দুটো নতুন কমান্ড আনা হলো, প্রতিটার একটাই দায়িত্ব:

git checkout এখনো আছে backward-compatibility-র জন্য — এটা কখনো deprecated হবে না, কারণ লক্ষ লক্ষ স্ক্রিপ্ট এর উপর নির্ভরশীল। কিন্তু নতুন workflow-এ switch/restore সুপারিশ করা হয় কারণ এগুলোর নাম থেকেই বোঝা যায় কী ঘটবে, আর accidental data-loss-এর সুযোগ কম — যেমন git restore ডিফল্টে working tree বদলায়, staged পরিবর্তনের জন্য এক্সপ্লিসিট --staged লাগবেই।

বাস্তব প্রভাব

আজকের টিউটোরিয়াল/ডকুমেন্টেশনে switch/restore বেশি দেখা যায়, কিন্তু পুরনো CI স্ক্রিপ্ট, StackOverflow উত্তর, আর অনেক টিমের runbook এখনো checkout-ই ব্যবহার করে — দুটোই জানা দরকার, একটা আরেকটাকে রিপ্লেস করেনি, শুধু নতুন, নিরাপদ বিকল্প যোগ হয়েছে।

লক্ষ্য

branch তৈরি, listing flag, rename, delete, আর tracking — সবগুলো নিজে হাতে চালিয়ে দেখা।

mkdir git-branch-lab && cd git-branch-lab && git init
echo "v1" > app.txt && git add . && git commit -m "initial commit"

# ১) তিনটা feature branch তৈরি
git switch -c feature/login
echo "login code" >> app.txt && git commit -am "add login"
git switch main
git switch -c feature/logout
echo "logout code" >> app.txt && git commit -am "add logout"
git switch main
git branch feature/unused   # তৈরি হলো কিন্তু কোনো কমিট নেই

# ২) listing flags পরীক্ষা করুন
git branch -v
git branch --merged main
git branch --no-merged main

# ৩) feature/login কে main-এ merge করুন
git merge feature/login

# ৪) এখন আবার --merged চালিয়ে পার্থক্য লক্ষ্য করুন
git branch --merged main
# feature/login এখন এই তালিকায় থাকবে, feature/logout থাকবে না

# ৫) নিরাপদ ও ফোর্স ডিলিট পরীক্ষা
git branch -d feature/login       # সফল হবে (merge হয়ে গেছে)
git branch -d feature/logout      # refuse করবে "not fully merged"
git branch -D feature/logout      # ফোর্স ডিলিট, সফল হবে

# ৬) rename করুন
git branch -m feature/unused feature/renamed
git branch -v

চ্যালেঞ্জ (নিজে করুন)

একটা bare remote সিমুলেট করুন (git init --bare ../origin.git), git remote add origin ../origin.git, git push -u origin main চালিয়ে upstream সেট করুন, তারপর git branch -vv চালিয়ে ahead/behind কলাম দেখুন। একটা নতুন লোকাল কমিট করে আবার -vv চালিয়ে দেখুন "ahead 1" কীভাবে দেখায়।

প্র.১ — একটা branch তৈরি করা কেন এত দ্রুত ও সস্তা অপারেশন? উত্তর: কারণ branch আসলে কোনো ডেটা কপি করে না — এটা শুধু .git/refs/heads/<name> নামে একটা ছোট ফাইল লেখে যাতে একটা কমিট hash (৪০/৬৪ ক্যারেক্টার) থাকে। কোনো tree/blob object নতুন করে তৈরি হয় না, শুধু একটা পয়েন্টার সেট হয়।

প্র.২ — git branch -d আর -D-এর পার্থক্য কী? উত্তর: -d (lowercase) একটা safe delete — branch-টা যদি বর্তমান branch/upstream-এ ইতিমধ্যে merge না হয়ে থাকে তাহলে Git refuse করবে। -D (uppercase) সেই চেক বাইপাস করে যেকোনো অবস্থায় ডিলিট করে দেয় — merge না হওয়া কমিটও হারিয়ে যেতে পারে (যদিও reflog দিয়ে কিছুদিন রিকভারি সম্ভব)।

প্র.৩ — --merged আর --no-merged-এর ব্যবহারিক উপকারিতা কী? উত্তর: PR merge হওয়ার পর জমে থাকা মৃত local branch খুঁজে পরিষ্কার করার জন্য --merged ব্যবহার হয়, আর --no-merged দেখায় কোন কোন branch-এ এখনো unmerged কাজ পড়ে আছে — রিভিউ বা রিমাইন্ডারের জন্য দরকারি।

প্র.৪ — git switch কেন git checkout-কে সম্পূর্ণ রিপ্লেস করলো না? উত্তর: backward compatibility রক্ষা করার জন্য — লক্ষ লক্ষ স্ক্রিপ্ট, CI পাইপলাইন, ডকুমেন্টেশন checkout ব্যবহার করে। switch/restore ২০১৯-এ (Git 2.23) যোগ হয়েছে নতুন, স্পষ্ট, নিরাপদ বিকল্প হিসেবে, কিন্তু পুরনোটা deprecated হয়নি।

প্র.৫ — tracking branch সেট করা না থাকলে কী সমস্যা হয়? উত্তর: git pull/git push কোনো আর্গুমেন্ট ছাড়া চালানো যায় না — প্রতিবার explicit remote ও branch নাম দিতে হয় (git push origin feature/x)। tracking সেট থাকলে Git জানে কোন remote branch-এর সাথে তুলনা করে ahead/behind দেখাবে।

প্র.৬ — বর্তমানে checkout করা branch rename করা যায় কি? উত্তর: হ্যাঁ, git branch -m new-name চালালে (পুরনো নাম না দিয়ে) বর্তমান checked-out branch-ই rename হয় এবং HEAD স্বয়ংক্রিয়ভাবে নতুন নামের ref-কে পয়েন্ট করে।

• -a দিয়ে দেখা remote-tracking branch (remotes/origin/x) আসলে সত্যিকারের branch না — এগুলো শুধু local ক্যাশ, শেষ কবে fetch করা হয়েছিলো তার একটা স্ন্যাপশট। remote-এ কেউ branch মুছে দিলেও git fetch --prune না চালানো পর্যন্ত এটা লোকালি দেখা যেতেই থাকবে।
• --contains আর --points-at গুলিয়ে ফেলা সাধারণ ভুল। --contains <commit> দেখায় যেসব branch-এর ইতিহাসে commit-টা আছে (tip না-ও হতে পারে); --points-at <commit> দেখায় শুধু যেসব branch-এর tip ঠিক সেই commit-এ আছে — অনেক বেশি সংকীর্ণ ফিল্টার।
• git branch -d মাঝেমধ্যে merge হওয়া সত্ত্বেও refuse করে যদি merge অন্য branch-এ হয় (যেমন develop-এ merge হয়েছে কিন্তু আপনি main-এ থেকে delete করছেন) — কারণ -d merge-status চেক করে current HEAD-এর সাপেক্ষে, তাই সঠিক branch-এ checkout করে delete করা দরকার অথবা -D লাগবে যদি নিশ্চিত হন।
• rename করার পর remote branch স্বয়ংক্রিয়ভাবে rename হয় না। git branch -m old new শুধু লোকাল ref বদলায়; remote-এ পুরনো নামেই branch থেকে যায় যতক্ষণ না ম্যানুয়ালি git push origin :old && git push -u origin new চালানো হয়।

Detached HEAD-কে নতুনরা প্রায়ই ভয় পান — টার্মিনালে "you are in 'detached HEAD' state" মেসেজ দেখে মনে হয় কিছু ভেঙে গেছে। এই মডিউলে দেখানো হবে এটা আসলে একটা সম্পূর্ণ স্বাভাবিক, predictable state — Git-এর HEAD/ref মডেল বুঝলে এতে ভয় পাওয়ার কিছু নেই। সাথে থাকবে git switch --orphan — সম্পূর্ণ নতুন, ইতিহাসবিহীন branch তৈরির কমান্ড, যেটা বাস্তবে gh-pages-এর মতো ব্যবহার হয়।

HEAD স্বাভাবিক অবস্থায়: একটা symbolic ref

স্বাভাবিক অবস্থায় .git/HEAD ফাইলের ভেতরে থাকে:

ref: refs/heads/main

এটা একটা indirect পয়েন্টার — HEAD সরাসরি কোনো commit hash ধরে না, বরং একটা branch ref-কে পয়েন্ট করে, আর সেই branch ref তখন commit hash ধরে। এই দুই-স্তরের indirection-এর সুবিধা: commit করলে শুধু branch ref-টা আপডেট হয়, HEAD-এর বদলানোর দরকার হয় না — HEAD স্বয়ংক্রিয়ভাবে branch-এর সাথে "চলতে থাকে"।

Detached HEAD: সরাসরি একটা commit hash

যখন HEAD কোনো branch ref-এর বদলে সরাসরি একটা commit hash ধরে, তখন সেটাকে বলে detached HEAD:

7a1f9c2e4b8d3f1a0c9e7b6d5a4c3b2a1f0e9d8c

এই অবস্থায় নতুন commit করলে সেই commit কোনো branch-এর সাথে যুক্ত হয় না — এটা "floating" থাকে, শুধু HEAD থেকে reachable, অন্য কোনো ref থেকে না। যদি এই অবস্থায় অন্য branch-এ switch করে ফেলেন, সেই commit-গুলো কোনো branch থেকে পৌঁছানো যাবে না (unreachable) — কিন্তু object হিসেবে তখনো .git/objects-এ থেকে যায়, reflog-এ ট্র্যাক থাকে।

এক লাইনে পার্থক্য

স্বাভাবিক HEAD = "আমি main branch-এ আছি, main যেখানেই যাক আমিও সেখানে যাব।" Detached HEAD = "আমি ঠিক এই একটা commit-এ আছি, কোনো branch-এর সাথে যুক্ত না।"

তিনটা সাধারণ উপায়

git checkout 7a1f9c2          # নির্দিষ্ট commit hash-এ checkout
git checkout v1.2.0           # একটা tag-এ checkout — tag নিজেও একটা branch না, তাই detach হবে
git switch --detach main      # স্পষ্টভাবে detach করে main-এর বর্তমান tip-এ

ভেতরে কী ঘটে

Git দেখে আপনি যে আর্গুমেন্ট দিয়েছেন সেটা কোনো branch নাম (refs/heads/<name>)-এর সাথে ম্যাচ করে কিনা। ম্যাচ না করলে (একটা raw hash, একটা tag, বা HEAD~3-এর মতো একটা relative reference), Git ধরে নেয় আপনি একটা নির্দিষ্ট commit-এ যেতে চাইছেন — তখন .git/HEAD-এ ref: refs/heads/... এর বদলে সরাসরি সেই commit-এর hash লিখে দেয়।

git checkout v1.2.0
# Note: switching to 'v1.2.0'.
#
# You are in 'detached HEAD' state. You can look around, make experimental
# changes and commit them, and you can discard any commits you make in this
# state without impacting any branches by switching back to a branch.

Git নিজেই এই মেসেজে বুঝিয়ে দেয়: এটা read-only exploration-এর জন্য নিরাপদ একটা মোড — একটা পুরনো release ট্যাগ চেকআউট করে দেখা, বা একটা নির্দিষ্ট commit-এ কোড কেমন ছিলো সেটা পরীক্ষা করার জন্য আদর্শ, কোনো branch তৈরি না করেই।

ভয়টা কোথা থেকে আসে

নতুনরা ভয় পান কারণ মনে হয় detached অবস্থায় কমিট করলে সেটা "হারিয়ে যাবে"। আংশিক সত্য: যদি detached অবস্থায় কমিট করে তারপর সরাসরি অন্য branch-এ switch করে ফেলেন কোনো branch না বানিয়ে, সেই commit কোনো branch থেকে reachable থাকবে না।

কিন্তু আসলে ডেটা হারায় না — অন্তত সাথে সাথে না

Commit object তৈরি হওয়ার সাথে সাথে সেটা .git/objects-এ পার্মানেন্টলি সংরক্ষিত থাকে, আর git reflog HEAD-এর প্রতিটা movement ট্র্যাক রাখে — এমনকি detached অবস্থাতেও। ফলে switch করে ফেলার পরও কয়েক সপ্তাহ (ডিফল্ট gc grace period, সাধারণত ৩০-৯০ দিন) পর্যন্ত git reflog দিয়ে সেই commit hash খুঁজে বের করে নতুন branch বানিয়ে রিকভার করা সম্ভব (পুরো ওয়াকথ্রু Phase 4-এর Reflog মডিউলে)।

আসল ঝুঁকি: reflog-ও এক্সপায়ার হলে

যদি অনেক দিন পার হয়ে যায় (default gc.reflogExpireUnreachable=30 days) এবং git gc চলে, তখন সেই commit সত্যিই মুছে যেতে পারে — কারণ কোনো ref (branch/tag/reflog) থেকে reachable না এমন object-কে Git garbage collect করে। তাই ভয়টা সম্পূর্ণ ভিত্তিহীন না, কিন্তু "সাথে সাথে হারিয়ে যাবে" — এই ধারণাটা ভুল। বাস্তব অভ্যাস: detached অবস্থায় গুরুত্বপূর্ণ কাজ করলে সাথে সাথে একটা branch বানিয়ে ফেলুন।

সমাধান: একটা branch বানিয়ে ফেলুন

git switch --detach v1.2.0
echo "hotfix attempt" >> app.py
git commit -am "experimental fix while exploring v1.2.0"

# এখন এই commit বাঁচাতে —
git switch -c hotfix/v1.2.0-patch
# অথবা switch না করেই:
git branch hotfix/v1.2.0-patch

git branch <name> (switch ছাড়া) চালালে HEAD যেখানে আছে ঠিক সেই commit-এ একটা নতুন branch ref তৈরি হয়ে যায় — কিন্তু HEAD তখনো detached-ই থাকে যদি না switch -c/checkout -b ব্যবহার করেন। তাই safe pattern হলো switch -c — এক কমান্ডেই branch তৈরি ও তাতে attach হওয়া, যাতে ভবিষ্যতের commit স্বয়ংক্রিয়ভাবে সেই branch-এর সাথে যুক্ত হয়।

ইতিমধ্যে switch করে ফেললে

যদি কমিট করার পর ভুলে অন্য branch-এ switch করে ফেলেন, git reflog চালিয়ে "commit:" লাইনের hash খুঁজে বের করুন, তারপর git branch recovered-work <hash> দিয়ে সেই commit-কে নতুন branch-এ প্রাণ দিন। এই ফ্লো Phase 4-এর Module 16-এ বিস্তারিত ওয়াকথ্রু হবে।

Orphan branch কী

git switch --orphan <name> এমন একটা branch তৈরি করে যার কোনো parent commit নেই — সম্পূর্ণ খালি ইতিহাস দিয়ে শুরু। বর্তমান branch-এর working tree ফাইলগুলো staged অবস্থায় থেকে যায় (যদি না --discard-changes ব্যবহার করেন), কিন্তু commit history সম্পূর্ণ আলাদা, disconnected।

git switch --orphan gh-pages
git rm -rf .                    # আগের সব ফাইল unstage+delete করে ফাঁকা শুরু
echo "<h1>My Site</h1>" > index.html
git add index.html
git commit -m "initial gh-pages commit"

ভেতরে কী ঘটছে

স্বাভাবিক নতুন commit তৈরি হয় তার আগের HEAD commit-কে parent হিসেবে রেখে (parent ফিল্ড commit object-এ পূরণ থাকে)। Orphan branch-এর প্রথম commit-এর parent ফিল্ড খালি — ঠিক যেমন রিপোর প্রথম commit-এর কোনো parent থাকে না। ফলে git log gh-pages আর git log main সম্পূর্ণ আলাদা, সংযোগহীন ইতিহাস দেখাবে — যদিও দুটোই একই .git রিপোজিটরির ভেতরে থাকে।

বাস্তব ব্যবহার: gh-pages branch

GitHub Pages-এ static site হোস্ট করার সময় প্রচলিত প্যাটার্ন: main branch-এ সোর্স কোড থাকে, আর gh-pages branch-এ শুধু বিল্ড-করা static HTML/CSS/JS থাকে — সম্পূর্ণ আলাদা ইতিহাস, কারণ এই দুই branch-এর কন্টেন্ট যুক্তিগতভাবে সম্পর্কহীন (একটা সোর্স, একটা আর্টিফ্যাক্ট)। orphan branch দিয়ে gh-pages শুরু করলে main-এর হাজার হাজার commit-এর ইতিহাস gh-pages-এ বহন করতে হয় না, রিপো ছোট থাকে।

লক্ষ্য

detached HEAD-এ কাজ করে সেটা রিকভার করা, তারপর একটা orphan branch তৈরি করে দেখা।

mkdir git-detached-lab && cd git-detached-lab && git init
for i in 1 2 3; do echo "line $i" >> file.txt && git commit -am "commit $i"; done
git tag v1.0 HEAD~1     # দ্বিতীয় কমিটে একটা ট্যাগ

# ১) detached HEAD-এ যান
git switch --detach v1.0
git status              # "HEAD detached at v1.0" দেখুন

# ২) একটা experimental commit করুন
echo "experimental line" >> file.txt
git commit -am "experimental change from v1.0"
git log --oneline -3

# ৩) main-এ ফিরে যান (এখনো branch বানাননি!)
git switch main
git log --oneline --all    # লক্ষ্য করুন experimental commit আর কোনো branch থেকে দেখা যাচ্ছে না

# ৪) reflog দিয়ে সেই commit উদ্ধার করুন
git reflog | head -5
# HEAD@{1} থেকে hash কপি করুন, তারপর:
git branch recovered-experiment <সেই-hash>
git log --oneline recovered-experiment

# ৫) এখন orphan branch তৈরি করুন
git switch --orphan gh-pages
git rm -rf .
echo "<h1>Static Site</h1>" > index.html
git add index.html
git commit -m "initial gh-pages"
git log --oneline gh-pages    # মাত্র ১টা commit, main-এর সাথে কোনো সংযোগ নেই
git log --oneline main        # এখনো ৩টা commit

চ্যালেঞ্জ (নিজে করুন)

git log --graph --all --oneline চালিয়ে দেখুন gh-pages branch গ্রাফে সম্পূর্ণ বিচ্ছিন্ন root হিসেবে কীভাবে দেখানো হয়, main/recovered-experiment-এর সাথে কোনো connecting line ছাড়াই।

প্র.১ — detached HEAD আর normal HEAD-এর মধ্যে .git/HEAD ফাইলের কন্টেন্টে কী পার্থক্য? উত্তর: Normal অবস্থায় .git/HEAD-এ থাকে ref: refs/heads/<branch-name> — একটা symbolic (indirect) পয়েন্টার। Detached অবস্থায় সরাসরি একটা commit hash থাকে, কোনো branch ref-এর রেফারেন্স ছাড়াই।

প্র.২ — detached HEAD অবস্থায় commit করে switch করে ফেললে সাথে সাথে ডেটা হারায় কি? উত্তর: না, সাথে সাথে না। Commit object .git/objects-এ থেকে যায় এবং git reflog-এ ট্র্যাক থাকে। শুধু কোনো branch থেকে reachable না থাকায় সাধারণ git log-এ দেখা যায় না। gc.reflogExpireUnreachable (ডিফল্ট ~৩০ দিন) পার হয়ে git gc চললে তবেই সত্যিকারের ঝুঁকি তৈরি হয়।

প্র.৩ — detached HEAD অবস্থায় করা একটা commit কীভাবে স্থায়ীভাবে রক্ষা করবেন? উত্তর: git switch -c <new-branch-name> চালিয়ে সেই মুহূর্তে একটা নতুন branch তৈরি করে সেখানে attach হয়ে যান — তাহলে ভবিষ্যতের commit-ও সেই branch-এর সাথেই যুক্ত থাকবে।

প্র.৪ — git switch --orphan আর সাধারণ git switch -c-এর পার্থক্য কী? উত্তর: switch -c নতুন branch তৈরি করে বর্তমান HEAD commit-কে parent হিসেবে রেখে — ইতিহাস সংযুক্ত থাকে। switch --orphan সম্পূর্ণ প্যারেন্টহীন branch তৈরি করে — নতুন root commit, আগের ইতিহাসের সাথে কোনো সংযোগ থাকে না।

প্র.৫ — gh-pages branch-এর জন্য orphan branch কেন ব্যবহার করা হয়? উত্তর: কারণ gh-pages-এ থাকে বিল্ড-করা static output, যেটার সাথে source code branch (main)-এর ইতিহাসগত কোনো সম্পর্ক নেই। orphan branch দিয়ে শুরু করলে main-এর হাজার হাজার commit বহন করতে হয় না — clone দ্রুত হয়, ইতিহাস পরিষ্কার থাকে।

প্র.৬ — একটা tag checkout করলে কেন সবসময় detached HEAD হয়, কখনো নরমাল branch checkout হয় না? উত্তর: কারণ tag নিজে refs/tags/<name>-এ থাকে, refs/heads/-এ না। Git-এর branch/HEAD মডেলে শুধু refs/heads/-এর ref-গুলোই HEAD-কে "attached" রাখতে পারে; tag একটা fixed পয়েন্টার (annotated হলে নিজেই আলাদা object), তাই checkout করলে সরাসরি সেই commit-এ detach করে দেয়।

• git branch <name> (switch ছাড়া) চালালে HEAD detached-ই থেকে যায় — নতুন branch ref তৈরি হয় ঠিকই, কিন্তু HEAD সেই নতুন branch-এ attach হয় না, তাই পরের commit আগের মতোই detached অবস্থায় হবে যদি না আলাদা করে git switch <name> চালান।
• git checkout main detached HEAD থেকে বের করে আনার সময় সতর্কতা ছাড়াই আগের uncommitted কাজ হারাতে পারে যদি conflict থাকে — commit না করে থাকলে working tree changes carry-over করার চেষ্টা Git করে, কিন্তু conflict হলে switch block হয়ে যায়; committed change না থাকলে সবচেয়ে নিরাপদ practice হলো স্টাশ করে switch করা।
• orphan branch-এর প্রথম commit-এর আগের working tree ফাইলগুলো ডিফল্টে staged অবস্থায় থেকে যায় — git rm -rf . না চালালে পুরনো ফাইলগুলোই নতুন orphan branch-এর প্রথম commit-এ চলে আসতে পারে, যেটা gh-pages-এর মতো ব্যবহারে অনিচ্ছাকৃতভাবে পুরো সোর্স কোড লিক করে দিতে পারে।
• git log --all detached HEAD-এর commit দেখাবে না যদি কোনো branch/tag/HEAD reflog থেকে reachable না হয় — --all শুধু ref-ভিত্তিক reachability দেখায়, dangling commit দেখতে git fsck --lost-found বা git reflog লাগবে।

এই Phase-টাই সম্ভবত গোটা journey-র সবচেয়ে ঘনবসতিপূর্ণ ও বাস্তব-জীবনে সবচেয়ে বেশি ব্যবহৃত অংশ। ছয়টা মডিউল — merge fundamentals, conflict resolution, reset/undo model, interactive rebase, cherry-pick, আর সবশেষে reflog সেফটি নেট — একসাথে মিলে তৈরি করে "undo mastery": আপনি কখনো ভুল করবেনই (ভুল branch-এ commit, ভুল merge, ভুল rebase), আসল দক্ষতা হলো কীভাবে সেই ভুল থেকে নিরাপদে ফিরে আসা যায়। এই Phase শেষ হলে git reset --hard বা git rebase দেখে আর ভয় পাওয়ার কিছু থাকবে না — বরং এগুলো হয়ে উঠবে আপনার সবচেয়ে শক্তিশালী টুল।

দুটো branch-এর ইতিহাস একত্র করার সবচেয়ে মৌলিক অপারেশন হলো merge। কিন্তু "merge" শব্দটার আড়ালে আসলে দুটো ভিন্ন মেকানিজম লুকিয়ে আছে — fast-forward আর 3-way merge — আর কখন কোনটা ঘটবে সেটা predictable, ম্যাজিক না। এই মডিউলে merge-base অ্যালগরিদম, --no-ff/--ff-only ফ্ল্যাগ, আর টিম ওয়ার্কফ্লোতে কোনটা কখন ব্যবহার করবেন সেটা কভার হবে।

Fast-forward merge

যখন target branch (যেমন main)-এর tip commit, source branch (যেমন feature/x)-এর ইতিহাসের একটা অগ্রজ (ancestor), তখন merge করার জন্য নতুন কোনো commit তৈরি করার দরকার নেই — Git শুধু main-এর ref-কে সরাসরি এগিয়ে নিয়ে feature/x-এর tip-এ বসিয়ে দেয়:

git switch main
git merge feature/x
# Updating 7a1f9c2..3b8e0a1
# Fast-forward
#  app.py | 3 +++

এখানে main ref কেবল একটা পয়েন্টার আপডেট — কোনো নতুন merge commit object তৈরি হয়নি।

3-way merge

যখন দুই branch একে অপরের থেকে ডাইভার্জ করে গেছে (দুইদিকেই নতুন commit হয়েছে কোনো common ancestor-এর পর থেকে), fast-forward সম্ভব না। তখন Git একটা 3-way merge করে — তিনটা commit ব্যবহার করে: দুই branch-এর tip, আর তাদের common ancestor (merge base)। ফলাফল হিসেবে একটা নতুন merge commit তৈরি হয় যার দুটো parent থাকে।

git merge feature/y
# Merge made by the 'ort' strategy.
#  utils.py | 5 +++++

ভেতরে common ancestor খোঁজা

Git প্রথমে git merge-base main feature/y চালানোর সমতুল্য একটা কাজ করে — দুই branch-এর commit graph ব্যাক-ট্রাভার্স করে সবচেয়ে recent common commit বের করে। তারপর তিনটা tree (ancestor, main-এর tree, feature/y-এর tree) তুলনা করে diff বের করে প্রতিটা ফাইলে — যেখানে দুইদিকেই একই লাইনে পরিবর্তন হয়েছে সেখানেই conflict দেখা দেয় (পরের মডিউলে বিস্তারিত)।

কী করে

git merge-base <commit1> <commit2> দুটো commit/branch-এর সবচেয়ে recent common ancestor বের করে দেয় — merge অপারেশনের ভেতরে এই কমান্ডটাই সবার আগে চলে (implicit ভাবে), কিন্তু নিজে থেকেও ম্যানুয়ালি চালানো যায়।

git merge-base main feature/y
# 7a1f9c2e4b8d3f1a0c9e7b6d5a4c3b2a1f0e9d8c

git log --oneline 7a1f9c2..feature/y   # ancestor থেকে feature/y পর্যন্ত কী নতুন
git log --oneline 7a1f9c2..main        # ancestor থেকে main পর্যন্ত কী নতুন

কীভাবে অ্যালগরিদমিক্যালি কাজ করে

Git-এর commit graph একটা DAG (Directed Acyclic Graph) — প্রতিটা commit তার parent(s)-কে পয়েন্ট করে। merge-base অ্যালগরিদম দুই commit থেকে ব্যাকওয়ার্ডে (parent চেইন ধরে) হাঁটে এবং প্রথম যে commit-টা উভয় দিক থেকেই reachable, সেটাই common ancestor। একাধিক merge commit থাকলে একাধিক "best" common ancestor থাকতে পারে — এই জটিল ক্ষেত্রে Git --all ফ্ল্যাগ দিয়ে সবগুলো দেখাতে পারে, অথবা recursive/ort strategy নিজে থেকে একটা virtual merge base তৈরি করে handle করে।

কোথায় ব্যবহারিকভাবে কাজে লাগে

# একটা feature branch-এ ঠিক কী কী নতুন commit আছে main-এর তুলনায়
git log --oneline $(git merge-base main feature/x)..feature/x

# rebase করার আগে দেখে নেওয়া কতগুলো commit replay হবে
git rev-list --count $(git merge-base main feature/x)..feature/x

PR রিভিউ করার সময় "এই branch-এ আসলে কী নতুন আছে main-এর তুলনায়" বোঝার জন্য এটা প্রতিদিনের কাজ — GitHub/GitLab-এর PR diff view ভেতরে ঠিক এই merge-base logic-ই ব্যবহার করে diff দেখায়, main-এর সর্বশেষ commit না দিয়ে।

সমস্যা: fast-forward ইতিহাস থেকে branch-এর অস্তিত্ব মুছে দেয়

Fast-forward merge কোনো নতুন commit তৈরি করে না — ফলে পরে git log-এ দেখলে মনে হবে সব commit যেন সরাসরি main-এই করা হয়েছিলো, কোনো আলাদা feature branch কখনো ছিলোই না। এটা group work-এর ইতিহাস হারিয়ে ফেলে — কোন commit-গুলো একটা logical unit (একটা feature/PR) হিসেবে একসাথে এসেছিলো, সেই তথ্য চলে যায়।

সমাধান: --no-ff

git merge --no-ff feature/otp-login

এই ফ্ল্যাগ fast-forward সম্ভব হলেও জোর করে একটা merge commit তৈরি করে — ফলে git log --graph দেখতে গেলে স্পষ্ট দেখা যায় কোথায় একটা feature branch শুরু হয়ে কোথায় merge হয়েছে:

git log --graph --oneline
*   3f8a1c2 Merge branch 'feature/otp-login'
|\
| * 9d2e7b1 add OTP verification endpoint
| * 5c1a0f3 add OTP generation logic
|/
* 7a1f9c2 initial commit

টিম ওয়ার্কফ্লোতে ব্যবহারিক সুবিধা

• Revert সহজ হয় — পুরো একটা feature-কে এক merge commit হিসেবে git revert -m 1 <merge-hash> দিয়ে সম্পূর্ণ undo করা যায় (Module 13-এ বিস্তারিত)।
• PR-এর ইতিহাস সংরক্ষিত থাকে — কোন commit-গুলো একটা PR-এর অংশ ছিলো তা git log --graph-এই দেখা যায়, external টুল ছাড়াই।
• Bisect-এ সাহায্য করে — একটা বাগ কোন feature merge-এর সাথে এসেছে সেটা merge commit বাউন্ডারি দিয়ে দ্রুত আইসোলেট করা যায়।

অনেক টিম policy হিসেবে git config --global merge.ff false সেট করে রাখে, যাতে ভুলবশত fast-forward কখনো না ঘটে।

সমস্যা: automation-এ auto-merge commit ঝুঁকিপূর্ণ

CI/CD পাইপলাইনে যখন স্বয়ংক্রিয়ভাবে main-এ merge করা হয় (যেমন একটা bot দিয়ে), যদি ইতিমধ্যে অন্য কেউ main-এ নতুন commit push করে ফেলে থাকে, একটা automatic 3-way merge conflict তৈরি করতে পারে — আর automation-এর ভেতরে conflict resolve করার কোনো মানুষ নেই। এটা pipeline-কে অনির্ধারিত অবস্থায় ফেলে দিতে পারে।

সমাধান: --ff-only

git merge --ff-only feature/x
# fatal: Not possible to fast-forward, aborting.

এই ফ্ল্যাগ Git-কে বলে: শুধুমাত্র fast-forward সম্ভব হলেই merge করো, নাহলে সম্পূর্ণ ব্যর্থ হয়ে থামো — কোনো automatic 3-way merge commit তৈরি করার চেষ্টা করবে না। এটা fail-fast আচরণ — pipeline সাথে সাথে বুঝে যায় merge সম্ভব না, আর মানুষকে জানিয়ে দেয় ম্যানুয়াল হস্তক্ষেপ দরকার।

বাস্তব ব্যবহার

# একটা release automation script-এ
git fetch origin
git switch main
git merge --ff-only origin/main   # শুধু নিশ্চিত করে local main আপডেটেড, conflict নেই

# একটা "merge train" পদ্ধতিতে rebase+ff-only পদ্ধতি
git switch feature/x
git rebase origin/main            # প্রথমে rebase করে main-এর উপরে replay
git switch main
git merge --ff-only feature/x     # এখন guaranteed fast-forward, নিরাপদ

এই প্যাটার্ন — rebase করে তারপর --ff-only merge — অনেক টিমের "linear history" policy-র ভিত্তি, যেখানে main-এ কখনো merge commit থাকে না, সবকিছু সরল রেখায় থাকে।

লক্ষ্য

দুই ধরনের merge নিজের চোখে ঘটতে দেখা, আর merge-base কমান্ড ব্যবহার করা।

mkdir git-merge-lab && cd git-merge-lab && git init
echo "base" > file.txt && git add . && git commit -m "initial commit"

# ১) Fast-forward দৃশ্য
git switch -c feature/ff
echo "ff change" >> file.txt && git commit -am "ff change"
git switch main
git merge feature/ff
# লক্ষ্য করুন: "Fast-forward" মেসেজ, কোনো নতুন merge commit নেই
git log --oneline --graph

# ২) 3-way merge দৃশ্য (branch diverge করানো)
git switch -c feature/a
echo "change from a" >> file2.txt && git add . && git commit -m "feature a work"
git switch main
echo "unrelated main work" >> file3.txt && git add . && git commit -m "main work"
git merge feature/a
# লক্ষ্য করুন: একটা editor খুলবে merge commit message-এর জন্য, "Merge made by the 'ort' strategy"
git log --oneline --graph

# ৩) merge-base পরীক্ষা
git switch -c feature/b main~1
echo "b work" >> file4.txt && git add . && git commit -m "feature b work"
git merge-base main feature/b
git log --oneline $(git merge-base main feature/b)..feature/b

# ৪) --no-ff বনাম ডিফল্ট তুলনা
git switch -c feature/c
echo "c work" >> file5.txt && git commit -am "feature c work"
git switch main
git merge --no-ff feature/c
git log --graph --oneline   # স্পষ্ট merge commit দেখুন, fast-forward সম্ভব থাকলেও

চ্যালেঞ্জ (নিজে করুন)

git config merge.ff false সেট করে একটা fast-forward-যোগ্য branch merge করুন — দেখুন config সেটিং ছাড়া --no-ff ফ্ল্যাগ প্রতিবার লেখা ছাড়াই একই আচরণ পাচ্ছেন কিনা।

প্র.১ — fast-forward merge কখন সম্ভব, আর কখন সম্ভব না? উত্তর: যখন target branch-এর tip commit, source branch-এর ইতিহাসের সরাসরি একটা ancestor (অর্থাৎ target-এ merge হওয়ার পর থেকে target-এ কোনো নতুন commit হয়নি), তখন fast-forward সম্ভব। দুই branch diverge করে গেলে (দুইদিকেই আলাদা commit হয়ে গেলে) fast-forward সম্ভব না, 3-way merge লাগবে।

প্র.২ — 3-way merge-এ "তিনটা" জিনিস কী কী? উত্তর: দুই branch-এর বর্তমান tip commit, আর তাদের common ancestor (merge base)। এই তিনটা tree তুলনা করে Git বুঝে কোথায় স্বয়ংক্রিয়ভাবে মার্জ করা যায় আর কোথায় conflict।

প্র.৩ — git merge-base ব্যবহারিকভাবে কোথায় কাজে লাগে? উত্তর: একটা feature branch-এ ঠিক কী নতুন কমিট আছে main-এর তুলনায় সেটা বের করতে (git log $(git merge-base main feature)..feature), rebase-এর আগে কতগুলো commit replay হবে বোঝার জন্য, আর PR টুলে diff দেখানোর ভিত্তি হিসেবে।

প্র.৪ — --no-ff কেন অনেক টিম policy হিসেবে ব্যবহার করে? উত্তর: এটা fast-forward সম্ভব থাকলেও জোর করে একটা merge commit তৈরি করে, যাতে ইতিহাসে স্পষ্ট থাকে কোন commit-গুলো একটা feature/PR হিসেবে একসাথে এসেছে — এটা পরবর্তীতে সেই পুরো ফিচারকে এক merge commit হিসেবে revert করা, বা bisect-এ দ্রুত আইসোলেট করা সহজ করে।

প্র.৫ — --ff-only কেন CI/CD automation-এ নিরাপদ? উত্তর: এটা কোনো automatic 3-way merge/conflict তৈরির চেষ্টা করে না — fast-forward সম্ভব না হলে সাথে সাথে fail করে থামে। এটা fail-fast আচরণ, যাতে automation নিজে থেকে অনির্ধারিত/জটিল conflict resolve করার চেষ্টা না করে, বরং মানুষকে জানায়।

প্র.৬ — "linear history" policy বজায় রাখতে rebase আর merge কীভাবে একসাথে ব্যবহার করা হয়? উত্তর: প্রথমে feature branch-কে git rebase origin/main দিয়ে main-এর latest tip-এর উপর replay করা হয়, তারপর git merge --ff-only feature/x দিয়ে merge করা হয় — rebase-এর পর guaranteed fast-forward সম্ভব হয়, ফলে কোনো merge commit ছাড়াই সম্পূর্ণ linear ইতিহাস বজায় থাকে।

• git merge feature/x যখন আপনার local branch আসলে ancestor, তখনও মাঝেমধ্যে merge commit তৈরি হয় যদি merge.ff config false সেট করা থাকে (গ্লোবাল বা লোকাল)। ডিফল্ট আচরণ ধরে নেওয়ার আগে git config --get merge.ff চেক করুন।
• একাধিক common ancestor থাকতে পারে জটিল branch topology-তে (criss-cross merge) — যখন দুই branch একে অপরকে একাধিকবার merge করে ফেলেছে। এক্ষেত্রে git merge-base --all একাধিক hash দেখাতে পারে, আর merge strategy (ort/recursive) নিজে থেকে একটা virtual merge base তৈরি করে হ্যান্ডল করে — ফলাফল কখনো কখনো অপ্রত্যাশিত মনে হতে পারে।
• --ff-only fail করলে সেটা কোনো error না, এটা ইচ্ছাকৃত সেফটি গার্ড — script-এ exit code চেক করে fallback logic (যেমন rebase চেষ্টা করা বা মানুষকে জানানো) রাখা উচিত, শুধু "crash" হিসেবে treat না করে।
• fast-forward merge-এর পর git log --graph দেখতে "merge হয়েছে" বোঝার কোনো উপায় নেই — যেহেতু কোনো merge commit তৈরিই হয়নি, ইতিহাস দেখতে সম্পূর্ণ linear মনে হবে, যেন branch-টা কখনো ছিলোই না।

Merge conflict দেখলে অনেকের হাত-পা ঠান্ডা হয়ে যায় — কিন্তু conflict marker আসলে খুবই সরল একটা তথ্য প্রকাশ করে: "দুইদিকে একই জায়গায় ভিন্ন পরিবর্তন হয়েছে, তুমি ঠিক করো কোনটা রাখবে।" এই মডিউলে conflict marker পড়া, ours/theirs-এর বিভ্রান্তিকর দ্বৈত অর্থ (merge বনাম rebase), strategy option, rerere দিয়ে repetitive conflict এড়ানো, আর একটা হাতে-কলমে conflict তৈরি করে সমাধানের ল্যাব — সবকিছু কভার হবে।

marker-গুলোর অর্থ

যখন একটা merge/rebase-এ conflict হয়, Git ফাইলের ভেতরেই দুই দিকের কন্টেন্ট মার্ক করে দেয়:

<<<<<<< HEAD
const MAX_RETRIES = 5;
=======
const MAX_RETRIES = 3;
>>>>>>> feature/tune-retries

• <<<<<<< HEAD থেকে ======= পর্যন্ত — বর্তমান branch (যেটাতে আপনি আছেন, merge-এ HEAD) এর ভার্সন।
• ======= থেকে >>>>>>> feature/tune-retries পর্যন্ত — যে branch merge/rebase করা হচ্ছে তার ভার্সন।
• >>>>>>> লাইনের পরের নাম বলে দেয় কোন branch/commit থেকে এই অংশ এসেছে।

সমাধান করার প্রক্রিয়া

Git স্বয়ংক্রিয়ভাবে conflicted ফাইলগুলোকে working directory-তে marker-সহ রেখে দেয়, আর git status দিয়ে কোন ফাইলে conflict আছে দেখা যায়:

git status
# Unmerged paths:
#   both modified:   config.js

সমাধান মানে ম্যানুয়ালি ফাইল এডিট করে marker-গুলো মুছে ফেলে সঠিক ফাইনাল কন্টেন্ট রাখা (একটার, অন্যটার, বা দুটোর মিশ্রণ), তারপর git add <file> দিয়ে resolved হিসেবে mark করা, আর git commit (merge-এ) বা git rebase --continue (rebase-এ) দিয়ে এগিয়ে যাওয়া।

রিয়েল-লাইফ উদাহরণ

দুটো টিম মেম্বার একই কনফিগ ফাইলে MAX_RETRIES ভ্যালু আলাদা আলাদাভাবে টিউন করেছেন — merge করার সময় Git বুঝতে পারে না কোনটা সঠিক, তাই মানুষের সিদ্ধান্তের জন্য conflict marker রেখে থামে। সমাধান হতে পারে দুটোর একটা বেছে নেওয়া, বা দুজনের সাথে কথা বলে একটা নতুন consensus ভ্যালু ঠিক করা।

বিখ্যাত বিভ্রান্তি

"ours" আর "theirs" শব্দ দুটো Git-এ ব্যবহার হয়, কিন্তু merge আর rebase-এ এদের অর্থ ঠিক উল্টো — এটা experienced ডেভেলপারদেরও প্রায়ই বিভ্রান্ত করে।

Merge-এ: "ours" = আপনার বর্তমান branch

git switch main
git merge feature/x
# conflict হলে: "ours" = main (আপনি যেখানে আছেন), "theirs" = feature/x (যেটা merge করছেন)
git checkout --ours config.js    # main-এর ভার্সন রাখুন
git checkout --theirs config.js  # feature/x-এর ভার্সন রাখুন

Rebase-এ: "ours" = target branch, "theirs" = আপনার নিজের commit!

git switch feature/x
git rebase main
# rebase আসলে ভেতরে main-এ switch করে আপনার commit replay করে —
# তাই "ours" = main (base, যেটার উপর replay হচ্ছে), "theirs" = feature/x-এর commit (আপনারই কাজ!)
git checkout --ours config.js    # এখানে main-এর ভার্সন!
git checkout --theirs config.js  # এখানে আপনার নিজের feature commit-এর ভার্সন!

কেন এমন হয়

Rebase ভেতরে Git-কে আসলে বলে: "আমি temporarily main-এ চেকআউট করে আছি, এখন feature/x-এর commit-গুলো একে একে এখানে replay (cherry-pick-এর মতো) করছি।" প্রতিটা replay-এর সময় "ours" মানে বর্তমান base (main), আর "theirs" মানে যেই commit-টা apply করার চেষ্টা হচ্ছে (আপনারই পুরনো commit) — merge-এর মতো "আপনি" আর "অন্যপক্ষ"-এর ধারণা এখানে literally উল্টে যায়।

নিরাপদ অভ্যাস

নাম নিয়ে অনুমান না করে সবসময় git diff বা conflict marker-এর ভেতরের branch নাম (>>>>>>> <name>) দেখে নিশ্চিত হয়ে নিন কোনটা কী — বিশেষ করে rebase-এর সময়।

merge --abort: সম্পূর্ণ ফিরে যাওয়া

git merge feature/x
# CONFLICT (content): Merge conflict in config.js
git merge --abort

--abort merge শুরু হওয়ার ঠিক আগের অবস্থায় working directory, index, ও HEAD সব ফিরিয়ে দেয় — যেন merge কখনো শুরুই হয়নি। এটা কাজ করে কারণ merge শুরু হলে .git/MERGE_HEAD ফাইলে merge-in-progress state সংরক্ষিত থাকে; --abort সেই state ব্যবহার করে reset করে।

-X ours / -X theirs: স্বয়ংক্রিয় strategy option

কখনো conflict হলে ম্যানুয়াল রেজোলিউশন না করে পুরোপুরি এক পক্ষের ভার্সন অটোমেটিক রাখতে চাইলে:

git merge -X ours feature/x     # সব conflict-এ automatic ভাবে "ours" (main) জিতবে
git merge -X theirs feature/x   # সব conflict-এ automatic ভাবে "theirs" (feature/x) জিতবে

সতর্কতা: -X ours/-X theirs পুরো merge strategy-র option, git checkout --ours-এর মতো per-file সিদ্ধান্ত না — এটা confusing কারণ নাম প্রায় একই, কিন্তু scope আলাদা (পুরো merge বনাম একটা ফাইল)। এছাড়া -X ours এবং git merge -s ours সম্পূর্ণ আলাদা জিনিস — -s ours (strategy) পুরো অন্য branch-এর পরিবর্তন সম্পূর্ণ উপেক্ষা করে, শুধু history-তে merge হয়েছে বলে mark করে।

রিয়েল-লাইফ ব্যবহার

Vendor/generated ফাইল merge করার সময় (যেমন lock ফাইল), যেখানে "কোনটা সঠিক" প্রশ্নটা অর্থহীন — শুধু সাম্প্রতিক ভার্সন দরকার — -X theirs দিয়ে ম্যানুয়াল কাজ এড়ানো যায়। কিন্তু business logic-এ কখনো এটা ব্যবহার করা উচিত না, কারণ নীরবে একপক্ষের কাজ হারিয়ে যেতে পারে।

ডিফল্ট conflictstyle-এর সীমাবদ্ধতা

ডিফল্ট merge style শুধু দুই পক্ষের ভার্সন দেখায় — কিন্তু আসল common ancestor-এ লাইনটা কেমন ছিলো সেটা দেখায় না। ফলে বোঝা কঠিন হতে পারে কে আসলে কী বদলেছে — দুটো ভার্সনই ancestor থেকে ভিন্ন হতে পারে ভিন্ন কারণে।

diff3: তৃতীয় অংশ যোগ করা

git config --global merge.conflictstyle diff3

<<<<<<< HEAD
const MAX_RETRIES = 5;
||||||| a1b2c3d (merge base)
const MAX_RETRIES = 10;
=======
const MAX_RETRIES = 3;
>>>>>>> feature/tune-retries

মাঝের ||||||| (merge base) অংশ দেখায় ancestor-এ আসল ভ্যালু কী ছিলো (১০)। এখন স্পষ্ট বোঝা যায় — আপনি ১০ থেকে ৫-এ কমিয়েছেন, অন্যপক্ষ ১০ থেকে ৩-এ কমিয়েছে। প্রসঙ্গ ছাড়া এই তথ্য অনুমান করা কঠিন ছিলো।

zdiff3: আরও পরিষ্কার (Git 2.35+)

git config --global merge.conflictstyle zdiff3

zdiff3 একই তথ্য দেখায় কিন্তু common (unchanged) লাইনগুলোকে conflict marker-এর বাইরে রেখে দেয়, ফলে conflict block ছোট ও পড়া সহজ হয় — শুধু আসল ভিন্নতাগুলো marker-এর ভেতরে থাকে।

সুপারিশ

আজকাল অনেক অভিজ্ঞ ডেভেলপার ডিফল্টভাবে zdiff3 সেট করে রাখেন — বাড়তি প্রসঙ্গের জন্য কোনো খরচ নেই, শুধু সুবিধা। এটা একটা one-time global config যা সারাজীবনের জন্য conflict resolution সহজ করে দেয়।

সমস্যা: একই conflict বারবার ফিরে আসা

Long-lived feature branch rebase করার সময়, একই লাইনে conflict বারবার দেখা দিতে পারে — প্রতিটা commit replay-তে যদি সেই লাইন touch হয়। প্রতিবার একই ম্যানুয়াল রেজোলিউশন পুনরাবৃত্তি করা ক্লান্তিকর এবং ভুলের ঝুঁকিপূর্ণ।

rerere: Reuse Recorded Resolution

git config --global rerere.enabled true

একবার চালু করলে, Git প্রতিটা conflict resolution-এর "before" ও "after" স্টেট রেকর্ড করে রাখে (.git/rr-cache-এ)। ভবিষ্যতে ঠিক একই conflict prefix আবার দেখা দিলে, Git স্বয়ংক্রিয়ভাবে আগের রেজোলিউশন প্রয়োগ করে — resolved marker সহ ফাইল দেখায়, শুধু review করে git add করলেই চলে।

git rebase main
# CONFLICT in config.js
# Resolved 'config.js' using previous resolution.

ভেতরে কীভাবে কাজ করে

rerere conflict marker-সহ ফাইলের একটা normalized ফিঙ্গারপ্রিন্ট (hash) রাখে "before" স্টেট হিসেবে, আর সমাধানের পরের কন্টেন্ট "after" হিসেবে। পরের বার একই fingerprint match করলে, সেই "after" কন্টেন্ট অটোমেটিক অ্যাপ্লাই হয়।

বাস্তব ব্যবহার

দীর্ঘ সময় ধরে বহুবার rebase হওয়া একটা feature branch-এ (প্রতিদিন main-এর উপর rebase করা হয়), একই merge conflict বারবার আসতে পারে যতক্ষণ না feature branch merge হয়ে যায় — rerere চালু থাকলে প্রথমবার resolve করার পর বাকি সবগুলোতে ম্যানুয়াল কাজ লাগে না। টিমে global default হিসেবে চালু রাখা একটা সাধারণ productivity বুস্ট।

কী করে

git mergetool একটা কনফিগার করা external tool (VS Code, meld, vimdiff, kdiff3 ইত্যাদি) খুলে দেয় প্রতিটা conflicted ফাইলের জন্য, যেখানে three-pane (local/base/remote) ভিজ্যুয়াল view-তে conflict দেখা ও ক্লিক করে resolve করা যায় — টেক্সট marker হাতে এডিট করার বদলে।

git config --global merge.tool vscode
git config --global mergetool.vscode.cmd 'code --wait $MERGED'

git merge feature/x
# conflict হলে:
git mergetool

ভেতরে কী ঘটে

mergetool আসলে conflicted ফাইলের তিনটা ভার্সন (<file>.BASE, <file>.LOCAL, <file>.REMOTE) সাময়িক ফাইল হিসেবে তৈরি করে, external tool-কে সেই তিনটা পাস করে, আর tool বন্ধ হওয়ার পর ফলাফল ফাইলটা git add করার জন্য প্রস্তুত রাখে।

কখন ব্যবহার করবেন

• বড়, জটিল conflict যেখানে অনেকগুলো লাইন জড়িত — visual side-by-side view টেক্সট marker পড়ার চেয়ে দ্রুত বোঝা যায়।
• Binary বা structured ফাইল (যেমন JSON config) — syntax-aware tool ভুল কম করে।
• নতুন টিম মেম্বার যারা এখনো marker পড়তে স্বচ্ছন্দ না — GUI দিয়ে শেখা সহজ শুরু।

ছোট, সরল conflict-এ (এক-দুই লাইন) ম্যানুয়ালি marker এডিট করাই দ্রুততর — mergetool সব জায়গায় বাধ্যতামূলক না, প্রয়োজন অনুযায়ী বেছে নেওয়ার টুল।

লক্ষ্য

ইচ্ছাকৃতভাবে একটা conflict তৈরি করে, marker পড়ে, ম্যানুয়ালি সমাধান করে সম্পূর্ণ merge শেষ করা।

mkdir git-conflict-lab && cd git-conflict-lab && git init
cat > config.js << 'EOF'
const MAX_RETRIES = 10;
const TIMEOUT_MS = 3000;
EOF
git add . && git commit -m "initial config"

# branch A: MAX_RETRIES কমানো
git switch -c feature/reduce-retries
sed -i 's/MAX_RETRIES = 10/MAX_RETRIES = 5/' config.js
git commit -am "reduce retries to 5 for faster failure"

# branch B: একই লাইন ভিন্নভাবে বদলানো
git switch main
sed -i 's/MAX_RETRIES = 10/MAX_RETRIES = 3/' config.js
git commit -am "reduce retries to 3 based on incident review"

# এখন merge করুন — conflict হবে
git merge feature/reduce-retries
# CONFLICT (content): Merge conflict in config.js

সমাধান করুন

cat config.js
# <<<<<<< HEAD
# const MAX_RETRIES = 3;
# =======
# const MAX_RETRIES = 5;
# >>>>>>> feature/reduce-retries
# const TIMEOUT_MS = 3000;

ফাইলটা এডিট করে একটা সিদ্ধান্ত নিন (ধরুন টিমে আলোচনা করে ৪ ঠিক হলো):

# marker মুছে final content রাখুন:
# const MAX_RETRIES = 4;
# const TIMEOUT_MS = 3000;

git add config.js
git commit    # merge commit message এডিটর খুলবে, ডিফল্ট রেখে সেভ করুন
git log --graph --oneline

চ্যালেঞ্জ (নিজে করুন)

একই সিনারিও আবার তৈরি করুন কিন্তু git config merge.conflictstyle zdiff3 চালু করে — লক্ষ্য করুন conflict marker-এর ভেতরে এবার merge base-এর মূল ভ্যালু (১০) কীভাবে দেখা যায়, যা প্রথমবার দেখা যায়নি।

প্র.১ — conflict marker-এর তিনটা অংশ কী বোঝায়? উত্তর: <<<<<<< HEAD থেকে ======= পর্যন্ত বর্তমান branch (HEAD)-এর ভার্সন, ======= থেকে >>>>>>> <branch> পর্যন্ত merge/rebase হওয়া branch-এর ভার্সন। >>>>>>>-এর পরের নাম বলে দেয় কোন branch থেকে সেই অংশ এসেছে।

প্র.২ — merge আর rebase-এ "ours"/"theirs"-এর অর্থ কেন উল্টে যায়? উত্তর: Merge-এ "ours" মানে আপনার বর্তমান branch, "theirs" মানে merge করা হচ্ছে যেটা। Rebase আসলে ভেতরে target branch-এ (base) গিয়ে আপনার commit-গুলো replay করে — তাই "ours" মানে base (target), "theirs" মানে replay হওয়া commit (যেটা আসলে আপনারই কাজ)। এই কারণে rebase-এ ours/theirs উল্টে যায়।

প্র.৩ — git merge -X theirs আর git checkout --theirs-এর পার্থক্য কী? উত্তর: -X theirs পুরো merge strategy-র option — সব conflict-এ automatic ভাবে theirs জিতবে। git checkout --theirs <file> একটা নির্দিষ্ট ফাইলের জন্য ম্যানুয়ালি theirs ভার্সন নেওয়া (conflict চলাকালীন per-file সিদ্ধান্ত)।

প্র.৪ — merge.conflictstyle=diff3 কী বাড়তি তথ্য দেখায় যা ডিফল্ট style দেখায় না? উত্তর: common ancestor (merge base)-এ লাইনটা আসলে কেমন ছিলো, ||||||| (merge base) সেকশনে। এটা বুঝতে সাহায্য করে দুই পক্ষ ঠিক কী পরিবর্তন করেছে ancestor থেকে, শুধু চূড়ান্ত দুই ভার্সন দেখে অনুমান করার বদলে।

প্র.৫ — git rerere কী সমস্যা সমাধান করে? উত্তর: long-lived branch বারবার rebase করার সময় একই conflict বারবার ফিরে আসার সমস্যা। rerere আগের resolution রেকর্ড করে রাখে এবং একই conflict fingerprint আবার দেখা দিলে স্বয়ংক্রিয়ভাবে আগের সমাধান প্রয়োগ করে।

প্র.৬ — merge conflict-এর মাঝপথে সম্পূর্ণ বাতিল করতে চাইলে কী করবেন? উত্তর: git merge --abort চালাতে হবে — এটা merge শুরুর আগের অবস্থায় working directory, index, HEAD সব ফিরিয়ে দেয়, যেন merge কখনো শুরুই হয়নি।

• rebase চলাকালীন git merge --abort কাজ করবে না — rebase-এর জন্য আলাদা কমান্ড লাগে: git rebase --abort। দুটো ভিন্ন in-progress state (MERGE_HEAD বনাম .git/rebase-merge/rebase-apply), তাই ভুল abort কমান্ড চালালে "There is no merge to abort" এরর আসবে।
• git add-এর পর conflict marker ফাইলের ভেতরে ভুলে থেকে গেলেও Git resolved হিসেবে ধরে নেয় — Git marker সিনট্যাক্স চেক করে না, শুধু ফাইল staged হয়েছে কিনা দেখে। ফলে অসাবধানে <<<<<<< HEAD টেক্সট কোডে কমিট হয়ে যাওয়া একটা সাধারণ (embarrassing) ভুল — commit করার আগে diff রিভিউ করা ভালো অভ্যাস।
• rerere রেকর্ড করা resolution ভুল হলে সেটাও পরের বার স্বয়ংক্রিয়ভাবে re-apply হবে — ভুল ফিক্স একবার রেকর্ড হয়ে গেলে বারবার ভুলভাবেই অ্যাপ্লাই হতে থাকবে যতক্ষণ না git rerere forget <file> দিয়ে সেই এন্ট্রি মুছে ফেলা হয়।
• -X ours পুরো merge-এ conflict এড়িয়ে যায়, কিন্তু non-conflicting পরিবর্তন ঠিকই merge করে — এটা git merge -s ours-এর মতো সম্পূর্ণ অন্য branch উপেক্ষা করে না; বিভ্রান্তি এড়াতে দুটোর পার্থক্য স্পষ্ট মনে রাখা জরুরি।

git reset Git-এর সবচেয়ে শক্তিশালী কিন্তু সবচেয়ে ভুল-বোঝা কমান্ডগুলোর একটা — কারণ এর তিনটা মোড (--soft/--mixed/--hard) তিনটা ভিন্ন এলাকা বদলায়, আর ভুল মোড বেছে নিলে কাজ হারানোর ঝুঁকি থাকে। এই মডিউলে reset-এর তিন স্তর স্পষ্টভাবে আলাদা করা হবে, git revert-এর সাথে তুলনা করা হবে (কখন কোনটা নিরাপদ), আর git clean দিয়ে untracked ফাইল পরিষ্কার করা কভার হবে — প্রতিটা destructive কমান্ডের সাথে স্পষ্ট সতর্কতা সহ।

Git-এর তিনটা এলাকা যা reset প্রভাবিত করে

Git-এর ওয়ার্কিং মডেলে তিনটা আলাদা স্তর আছে: HEAD/branch ref (বর্তমান commit কোথায় পয়েন্ট করছে), index/staging area (পরের commit-এ কী যাবে তার প্রস্তুতি), আর working directory (ডিস্কে থাকা প্রকৃত ফাইল)। git reset-এর তিনটা মোড ঠিক করে কতদূর পর্যন্ত এই তিনটা এলাকা বদলাবে।

ব্যবহারিক পার্থক্য

git reset --soft HEAD~1
# শেষ commit-টা "undo" হলো, কিন্তু তার পরিবর্তন সব staged অবস্থায় রয়ে গেলো —
# তক্ষুনি আবার git commit চালালে প্রায় একই commit ফিরে পাবেন (হয়তো ভিন্ন মেসেজ দিয়ে)

git reset --mixed HEAD~1    # (বা শুধু git reset HEAD~1)
# commit undo, staging area খালি — পরিবর্তন working directory-তে আছে কিন্তু unstaged

git reset --hard HEAD~1
# commit undo, staging area খালি, working directory-ও আগের commit-এর অবস্থায় ফিরে যায় —
# uncommitted পরিবর্তন থাকলে তাও হারিয়ে যাবে

⚠️ সতর্কতা: --hard destructive

--hard uncommitted কাজ স্থায়ীভাবে মুছে দিতে পারে — commit না করা পরিবর্তন কোনো object হিসেবে সংরক্ষিত থাকে না (শুধু commit হওয়া object-ই .git/objects-এ থাকে, working directory-র raw পরিবর্তন না)। চালানোর আগে সবসময় git status ও git diff দিয়ে নিশ্চিত হয়ে নিন কিছু হারানোর মতো নেই, অথবা আগে git stash করে রাখুন।

সমস্যা: পুরো commit না, শুধু একটা ফাইল unstage করা

মাঝেমধ্যে সব ফাইল git add . দিয়ে stage করার পর বুঝতে পারেন একটা ফাইল ভুলবশত স্টেজ হয়ে গেছে, যেটা এখনই commit করতে চান না — পুরো staging area খালি করতে চান না, শুধু সেই একটা ফাইল।

সমাধান: pathspec সহ reset

git add config.js secrets.env README.md

git reset HEAD secrets.env
# অথবা আধুনিক সিনট্যাক্স:
git restore --staged secrets.env

ভেতরে কী ঘটে

pathspec ছাড়া git reset <commit> পুরো branch ref-কেই নতুন commit-এ নিয়ে যায় (আগের টেবিলের behavior)। কিন্তু pathspec (একটা ফাইলের নাম) দিলে reset সম্পূর্ণ ভিন্ন মোডে কাজ করে — branch ref একদম বদলায় না, শুধু index-এর সেই নির্দিষ্ট ফাইলের এন্ট্রিটা নির্দিষ্ট commit-এর ভার্সন দিয়ে ওভাররাইট করা হয় (ডিফল্টে HEAD-এর ভার্সন দিয়ে, যেটা কার্যকরভাবে "unstage")। working directory-র ফাইল কখনোই স্পর্শ করা হয় না — তাই এই ফর্মটা --hard-এর মতো বিপজ্জনক না, uncommitted পরিবর্তন হারানোর ঝুঁকি নেই।

রিয়েল-লাইফ ব্যবহার

.env বা secret ফাইল ভুলবশত git add .-এ চলে এলে commit হওয়ার আগেই git restore --staged .env দিয়ে বের করে ফেলা — এটা একটা daily-driver নিরাপত্তা অভ্যাস, বিশেষ করে যখন .gitignore আপডেট করতে ভুলে গেছেন।

reset-এর বিপরীত দর্শন

git reset ইতিহাস মুছে/পুনর্লিখন করে — branch ref পিছনে টেনে নেয়। git revert সম্পূর্ণ ভিন্ন approach নেয়: পুরনো commit মুছে না, বরং তার বিপরীত পরিবর্তন নিয়ে একটা নতুন commit যোগ করে। ইতিহাস অক্ষত থাকে, শুধু একটা নতুন "undo" entry যুক্ত হয়।

git revert a1b2c3d
# একটা নতুন commit তৈরি হবে যা a1b2c3d-এর পরিবর্তনগুলো উল্টে দেয়

-n (--no-commit): একাধিক revert একসাথে squash করা

git revert -n commit1 commit2 commit3
# তিনটা revert-ই staged হবে কিন্তু কোনো commit হবে না
git commit -m "revert three problematic commits together"

-m (mainline): merge commit revert করা

একটা সাধারণ commit-এর একটাই parent থাকে, revert করা সহজ — সরাসরি বিপরীত diff। কিন্তু merge commit-এর দুটো parent থাকে, তাই Git জানে না কোন দিকের ইতিহাসকে "mainline" ধরে বিপরীত diff বানাবে — -m 1 বা -m 2 দিয়ে নির্দিষ্ট করতে হয় কোন parent number-কে ভিত্তি ধরা হবে (সাধারণত -m 1, কারণ parent 1 হলো যে branch-এ merge করা হয়েছিলো)।

git revert -m 1 <merge-commit-hash>

রিয়েল-লাইফ উদাহরণ

Production-এ একটা বাগযুক্ত ফিচার merge হয়ে গেছে, কিন্তু সেই কোড ইতিমধ্যে অন্যদের local branch-এ pull হয়ে গেছে — এখন reset --hard করলে অন্যদের সাথে ইতিহাস বিরোধ (diverge) তৈরি হবে। git revert -m 1 <merge-hash> দিয়ে একটা নতুন "undo" commit push করলে সবার ইতিহাস সুসংগত থাকে, কেউ force-push conflict-এ পড়ে না।

সোনার নিয়ম

Shared/pushed history-তে কখনো reset --hard বা history-rewriting rebase ব্যবহার করবেন না — সবসময় revert ব্যবহার করুন।

কেন

reset branch ref-কে পিছনে নিয়ে যায় — commit hash-গুলো "মুছে" ফেলে (আসলে unreachable করে)। যদি সেই commit-গুলো ইতিমধ্যে remote-এ push হয়ে গিয়ে অন্যরা pull করে ফেলেছে, তাহলে তাদের local ইতিহাস আর আপনার নতুন (ছোট) ইতিহাসের সাথে diverge করে যায়। পরের push করতে গেলে force-push (--force) লাগবে, যেটা অন্যদের কাজ ওভাররাইট করে দিতে পারে — একটা টিমের জন্য বিপর্যয়কর হতে পারে।

revert কোনো পুরনো commit মুছে না, শুধু নতুন commit যোগ করে — এটা সবসময় fast-forward-বান্ধব, অন্য কারো ইতিহাসের সাথে conflict তৈরি করে না।

সিদ্ধান্তের টেবিল

--force-with-lease বনাম --force

নিজের একার branch-এ reset-এর পর push করতে হলেও --force না দিয়ে --force-with-lease ব্যবহার করা ভালো অভ্যাস — এটা চেক করে remote-এ আপনার শেষ জানা অবস্থার পর কেউ নতুন কিছু push করেছে কিনা, করলে refuse করে (নিরাপত্তা গার্ড)।

কী করে

git clean working directory থেকে untracked ফাইল (যেগুলো কখনো git add হয়নি) মুছে ফেলে। এটা reset-এর সাথে সম্পর্কিত না সরাসরি, কিন্তু একই "undo/cleanup" পরিবারের কমান্ড — প্রায়ই reset --hard-এর পাশাপাশি ব্যবহার হয় একটা রিপোকে সম্পূর্ণ পরিষ্কার অবস্থায় ফেরাতে।

git clean -n     # dry-run: কী কী মুছে যেত তা দেখায়, আসলে কিছু মুছে না (সবসময় প্রথমে এটা চালান!)
git clean -f     # force: আসলেই মুছে ফেলে (ডিফল্টে সেফটির জন্য clean কিছু করে না -f ছাড়া)
git clean -fd    # ডিরেক্টরিসহ (untracked ডিরেক্টরি, যেমন node_modules-এর ভুল কপি)
git clean -fx    # .gitignore-এ থাকা ফাইলসহ (বিল্ড আর্টিফ্যাক্ট, .env, ইত্যাদিও মুছে যাবে!)

⚠️ সতর্কতা: -f এবং বিশেষত -x অত্যন্ত ধ্বংসাত্মক

-fd কোনো নিরাপত্তা নেট ছাড়াই untracked ফাইল ডিরেক্টরিসহ মুছে দেয় — এগুলো কখনো commit হয়নি, তাই git reflog-এও এদের কোনো ট্রেস নেই। একবার মুছে গেলে সম্পূর্ণ, স্থায়ীভাবে হারিয়ে যায়, filesystem-level রিকভারি টুল ছাড়া কোনো উপায় নেই।

-fx আরও বিপজ্জনক — এটা .gitignore-এ থাকা ফাইলও মুছে দেয়, যার মধ্যে থাকতে পারে .env (secrets), IDE কনফিগ, বা ম্যানুয়ালি তৈরি করা লোকাল কনফিগ ফাইল যা কখনো ইচ্ছাকৃতভাবে ট্র্যাক করা হয়নি।

নিয়ম: -f/-fd/-fx চালানোর আগে সবসময় -n দিয়ে dry-run করুন এবং আউটপুট মনোযোগ দিয়ে পড়ুন।

রিয়েল-লাইফ ব্যবহার

CI বিল্ড এজেন্টে প্রতিটা রান শুরুর আগে workspace সম্পূর্ণ পরিষ্কার নিশ্চিত করতে git clean -fdx চালানো সাধারণ প্র্যাকটিস — কিন্তু এটা শুধু ephemeral CI environment-এর জন্য নিরাপদ, ডেভেলপারের নিজের মেশিনে সাবধানে ব্যবহার করা উচিত।

লক্ষ্য

তিনটা reset মোড ঠিক কী বদলায় তা নিজের চোখে দেখা — নিরাপদ sandbox-এ (destructive কমান্ড আছে, তাই এই ল্যাবের বাইরে সাবধানে ব্যবহার করুন)।

mkdir git-reset-lab && cd git-reset-lab && git init
echo "v1" > file.txt && git add . && git commit -m "commit 1"
echo "v2" > file.txt && git add . && git commit -m "commit 2"
echo "v3" > file.txt && git add . && git commit -m "commit 3"
git log --oneline

# ১) --soft পরীক্ষা
git reset --soft HEAD~1
git status              # staged অবস্থায় "commit 3"-এর পরিবর্তন দেখুন
git log --oneline       # শুধু ২টা commit দেখাবে
git diff --staged       # স্টেজড ডিফ দেখুন

# পুনরায় কমিট করে ৩ নম্বরে ফিরুন
git commit -m "commit 3 again"

# ২) --mixed পরীক্ষা (ডিফল্ট)
git reset HEAD~1
git status              # unstaged অবস্থায় পরিবর্তন দেখুন
git diff                # working tree ডিফ (staged না)
git add . && git commit -m "commit 3 restored"

# ৩) --hard পরীক্ষা (সাবধানে!)
echo "uncommitted experiment" >> file.txt   # uncommitted পরিবর্তন যোগ করুন
git status
git reset --hard HEAD~1
git status              # কিছুই staged/unstaged নেই — uncommitted কাজও হারিয়ে গেছে!
cat file.txt            # "v2" দেখাবে, "uncommitted experiment" হারিয়ে গেছে

# ৪) pathspec reset
echo "secret" > .env
echo "code" > app.py
git add .env app.py
git status
git restore --staged .env
git status              # শুধু app.py staged, .env unstage হয়ে গেছে

চ্যালেঞ্জ (নিজে করুন)

git clean -n চালিয়ে .env ফাইলটা দেখুন (unstage করলেও এখনো untracked)। তারপর .gitignore-এ .env যোগ করে আবার git clean -n চালিয়ে দেখুন পার্থক্য — এখন এটা -x ছাড়া clean-এ দেখাবে না।

প্র.১ — reset --soft, --mixed, --hard-এর মধ্যে মূল পার্থক্য এক বাক্যে বলুন। উত্তর: তিনটাই HEAD/branch ref বদলায়। --soft এখানেই থামে (index, working dir অপরিবর্তিত)। --mixed (ডিফল্ট) index-ও reset করে (unstage হয়) কিন্তু working dir অপরিবর্তিত রাখে। --hard তিনটাই বদলে দেয় — working directory-র ফাইলও পুরনো commit-এর অবস্থায় ফিরিয়ে দেয়, uncommitted কাজ হারানোর ঝুঁকি সহ।

প্র.২ — git reset --hard কেন কখনো কখনো "স্থায়ীভাবে" ডেটা মুছে ফেলে? উত্তর: কারণ uncommitted পরিবর্তন কখনো কোনো Git object হিসেবে সংরক্ষিত হয় না — শুধু committed ডেটা .git/objects-এ থাকে। --hard working directory-র uncommitted পরিবর্তন ওভাররাইট করে দেয়, আর সেটার কোনো ব্যাকআপ Git-এর নিজস্ব স্টোরেজে থাকে না।

প্র.৩ — revert কেন reset-এর চেয়ে shared branch-এ নিরাপদ? উত্তর: revert পুরনো commit মুছে না, বরং একটা নতুন commit যোগ করে যা বিপরীত পরিবর্তন প্রয়োগ করে — ইতিহাস অক্ষত থাকে, ফলে যাদের কাছে ইতিমধ্যে পুরনো commit pull হয়ে গেছে তাদের সাথে কোনো diverge/conflict তৈরি হয় না। reset branch ref পিছনে নিয়ে ইতিহাস "মুছে" ফেলে, যা shared history-তে force-push প্রয়োজন করে।

প্র.৪ — merge commit revert করতে -m ফ্ল্যাগ কেন লাগে? উত্তর: সাধারণ commit-এর একটাই parent থাকে, বিপরীত diff স্পষ্ট। কিন্তু merge commit-এর দুটো parent — Git জানে না কোনটাকে mainline ধরে বিপরীত হিসাব করবে, তাই -m 1/-m 2 দিয়ে স্পষ্ট করতে হয়।

প্র.৫ — git clean -fdx কেন সবচেয়ে বিপজ্জনক ভ্যারিয়েন্ট? উত্তর: -f আসল ডিলিট এক্সিকিউট করে, -d untracked ডিরেক্টরিও মুছে, আর -x .gitignore-এ থাকা ফাইলও মুছে দেয় — যার মধ্যে .env/secrets/লোকাল কনফিগ থাকতে পারে যা ইচ্ছাকৃতভাবে কখনো ট্র্যাক করা হয়নি। এবং reflog-এ এর কোনো ট্রেস থাকে না কারণ এগুলো কখনো commit-ই হয়নি।

প্র.৬ — pathspec সহ git reset HEAD <file> আর সাধারণ git reset HEAD~1-এর আচরণ কীভাবে আলাদা? উত্তর: pathspec ছাড়া reset পুরো branch ref-কে অন্য commit-এ সরিয়ে দেয়। pathspec সহ reset branch ref একদমই বদলায় না — শুধু index-এর সেই নির্দিষ্ট ফাইলের এন্ট্রি নির্দিষ্ট commit-এর ভার্সন দিয়ে ওভাররাইট (সাধারণত unstage) করে, working directory স্পর্শ না করেই।

• ⚠️ git reset --hard করার আগে stash-এ থাকা পরিবর্তনও ঝুঁকিতে না থাকলেও, uncommitted staged/unstaged পরিবর্তন সাথে সাথে হারিয়ে যায় — কমান্ড চালানোর আগে git status/git diff দিয়ে দুবার চেক করুন, বা git stash করে নিরাপদ রাখুন।
• ⚠️ git clean -fd reflog দিয়ে রিকভার করা যায় না — reflog শুধু commit history ট্র্যাক করে, untracked ফাইল কখনো Git object হয়নি বলে কোনো ট্রেস অবশিষ্ট থাকে না। এটা reset --hard-এর চেয়েও বেশি বিপজ্জনক এই অর্থে যে কোনো recovery path নেই।
• reset --mixed (ডিফল্ট) চালালে বড় ডিরেক্টরিতে সময় লাগতে পারে কারণ পুরো index পুনর্গঠন করতে হয় — বড় মনোরিপোতে এটা লক্ষণীয় ধীর হতে পারে, --soft তুলনামূলক দ্রুত কারণ index স্পর্শ করে না।
• revert করার সময় যদি সেই commit-এর পরিবর্তন ইতিমধ্যে অন্য commit দ্বারা ওভাররাইট হয়ে গেছে, তাহলে revert নিজেই conflict তৈরি করতে পারে — এক্ষেত্রে সাধারণ conflict resolution flow (marker এডিট, git add, git revert --continue) প্রয়োজন হয়, ঠিক merge conflict-এর মতোই।

Interactive rebase হলো Git-এর সবচেয়ে শক্তিশালী history-editing টুল — commit reorder, combine, edit, বা মুছে ফেলা সম্ভব একটা ইন্টারঅ্যাক্টিভ এডিটরের মাধ্যমে। কিন্তু এই শক্তি আসে একটা গুরুত্বপূর্ণ শর্তে: rebase আসলে ইতিহাস "সম্পাদনা" করে না, এটা নতুন commit object তৈরি করে পুরনোগুলো প্রতিস্থাপন করে — যা কেন এটাকে "history rewriting" বলা হয় তার মূল কারণ। এই মডিউলে replay মডেল, প্রতিটা rebase action, --onto-এর advanced ব্যবহার, আর rebase-এর সবচেয়ে গুরুত্বপূর্ণ নিয়ম — কখনো shared branch rebase না করা — কভার হবে।

Rebase আসলে কী করে

git rebase main চালালে মনে হতে পারে বর্তমান branch-এর commit-গুলো "সরিয়ে" main-এর উপর বসানো হচ্ছে। কিন্তু ভেতরে ঘটনাটা সম্পূর্ণ ভিন্ন: Git বর্তমান branch-এর প্রতিটা commit এক এক করে main-এর সর্বশেষ tip-এর উপর নতুন করে "replay" (এক ধরনের cherry-pick) করে।

কেন নতুন hash

প্রতিটা commit object-এর hash তার কন্টেন্ট, মেসেজ, author, timestamp, এবং parent hash দিয়ে নির্ধারিত হয় (SHA-1/SHA-256 checksum)। rebase-এর পর প্রতিটা replay-করা commit-এর parent বদলে গেছে (আগে ছিলো পুরনো base, এখন নতুন base) — parent বদলালেই hash সম্পূর্ণ ভিন্ন হয়ে যায়, যদিও diff/content একই থাকতে পারে।

git log --oneline feature/x
# c3d4e5f add validation
# b2c3d4e add form

git rebase main
git log --oneline feature/x
# 9f8e7d6 add validation    ← সম্পূর্ণ নতুন hash!
# 8e7d6c5 add form          ← এটাও নতুন hash!

এইজন্যই "history rewriting"

পুরনো commit object (c3d4e5f, b2c3d4e) মুছে যায় না তক্ষুনি — শুধু কোনো branch থেকে reachable থাকে না (reflog-এ কিছুদিন থেকে যায়)। নতুন commit-গুলো (9f8e7d6, 8e7d6c5) সম্পূর্ণ নতুন object, একই কন্টেন্ট কিন্তু ভিন্ন পরিচয়। এই কারণেই rebase-করা branch যদি কেউ ইতিমধ্যে pull করে থাকে, তাদের কাছে পুরনো hash-ভিত্তিক ইতিহাস আর নতুন hash-ভিত্তিক ইতিহাস — দুটো সম্পূর্ণ আলাদা commit set হিসেবে দেখা দেবে, যদিও কন্টেন্ট একই — এটাই shared branch rebase না করার মূল কারণ (পরে বিস্তারিত)।

ইন্টারঅ্যাক্টিভ এডিটর খোলা

git rebase -i HEAD~4

এটা একটা এডিটরে সাম্প্রতিক ৪টা commit-এর তালিকা খুলে দেয়, প্রতিটার সামনে একটা action:

pick b2c3d4e add form
pick c3d4e5f add validation
pick d4e5f6a fix typo
pick e5f6a7b add tests

প্রতিটা action-এর আচরণ

উদাহরণ: চারটা commit-কে দুটোতে কমানো

pick b2c3d4e add form
fixup c3d4e5f add validation    ← form-এর সাথে নিঃশব্দে মিশে যাবে
pick d4e5f6a fix typo
squash e5f6a7b add tests        ← fix typo-এর সাথে মিশবে, মেসেজ এডিট করার সুযোগ পাবেন

রিয়েল-লাইফ ব্যবহার

একটা PR review-এর আগে ৮টা "wip", "fix typo", "actually fix" commit-কে ১-২টা পরিষ্কার, অর্থবহ commit-এ কমিয়ে আনা — টিমের কাছে PR history readable রাখার জন্য একটা সাধারণ অভ্যাস।

সমস্যা: ম্যানুয়ালি reorder করা ঝামেলার

squash/fixup ব্যবহার করতে হলে rebase editor খুলে ম্যানুয়ালি commit reorder করে সঠিক জায়গায় action বসাতে হয় — একটু ভুল হলেই ভুল commit-এর সাথে মিশে যেতে পারে।

সমাধান: --fixup দিয়ে টার্গেট commit নির্দিষ্ট করা

git commit --fixup=b2c3d4e
# একটা নতুন commit তৈরি হবে মেসেজ "fixup! add form" দিয়ে

এই বিশেষ মেসেজ ফরম্যাট (fixup! <original subject>) Git-কে বলে দেয় এই commit কোন commit-এর সাথে মিশতে চায়।

--autosquash: rebase নিজে থেকেই সাজিয়ে দেয়

git rebase -i --autosquash HEAD~5

rebase editor খুললে fixup!/squash! prefix থাকা commit-গুলো স্বয়ংক্রিয়ভাবে তাদের টার্গেট commit-এর ঠিক পরে, সঠিক action (fixup/squash) দিয়ে বসানো অবস্থায় দেখাবে — ম্যানুয়াল reorder করার দরকার নেই, শুধু save করলেই চলে।

git config --global rebase.autosquash true   # সবসময় ডিফল্টে চালু রাখা

রিয়েল-লাইফ ওয়ার্কফ্লো

git commit -am "add form"                     # b2c3d4e
git commit -am "add validation"               # c3d4e5f
# রিভিউতে ধরা পড়লো form-এ একটা bug —
git commit --fixup=b2c3d4e -am "fix bug in form"
git rebase -i --autosquash HEAD~3
# save করলেই fixup commit স্বয়ংক্রিয়ভাবে b2c3d4e-এর সাথে মিশে যাবে

এটা PR history পরিষ্কার রাখার সবচেয়ে দ্রুত পদ্ধতি — reviewer-এর কমেন্ট অনুযায়ী ফিক্স করার পর সেটা মূল commit-এর সাথেই মিশিয়ে দেওয়া, আলাদা "fix review comment" commit না রেখে।

সমস্যা: একটা branch-এর বেস বদলাতে হবে, কিন্তু মাঝের কিছু commit বাদ দিতে হবে

ধরুন feature/b, feature/a-এর উপরে তৈরি হয়েছিলো (feature/a থেকে branch করা), কিন্তু এখন feature/a বাতিল হয়ে গেছে এবং feature/b-কে সরাসরি main-এর উপর বসাতে হবে — শুধু feature/a-এর পরের commit-গুলো (যেগুলো feature/b-তে যোগ হয়েছে) রেখে।

সমাধান: --onto

git rebase --onto main feature/a feature/b
# অর্থ: feature/a থেকে feature/b পর্যন্ত commit-গুলো নাও, main-এর উপর replay করো

সিনট্যাক্স ভাঙা

git rebase --onto <newbase> <oldbase> <branch>:

• <newbase> — যেখানে replay হবে (main)
• <oldbase> — কোথা থেকে replay শুরু হবে, exclusive (feature/a, এর নিজের commit বাদ)
• <branch> — কোন branch-এর commit replay হবে (feature/b, checkout না করা থাকলেও কাজ করে)

ভিজ্যুয়াল

আগে:  main ─── A1 ─── A2 (feature/a) ─── B1 ─── B2 (feature/b)

পরে:  main ─┬── A1 ─── A2 (feature/a)
            └── B1' ─── B2' (feature/b)   ← শুধু B1, B2 replay হলো, নতুন hash সহ

অন্য বাস্তব ব্যবহার: একটা নির্দিষ্ট রেঞ্জের commit বাদ দেওয়া

git rebase --onto HEAD~5 HEAD~3 HEAD
# HEAD-এর সাম্প্রতিক ৩টা commit-এর মাঝের commit বাদ দিয়ে ৫টা আগের commit-এর উপর বসানো

--onto interactive rebase-এর সবচেয়ে সূক্ষ্ম নিয়ন্ত্রণ টুল — যখন -i দিয়ে drop/reorder যথেষ্ট না, branch-এর গোড়াই বদলাতে হয়, তখন এটাই একমাত্র পথ।

--autostash: uncommitted কাজ থাকলেও rebase শুরু করা

সাধারণত uncommitted পরিবর্তন থাকলে rebase শুরু হতে দেয় না ("cannot rebase: You have unstaged changes")। --autostash স্বয়ংক্রিয়ভাবে rebase শুরুর আগে stash করে, rebase শেষে আবার pop করে দেয়:

git rebase --autostash main
git config --global rebase.autoStash true   # ডিফল্ট করে দেওয়া ভালো অভ্যাস

conflict হলে তিনটা পথ

git rebase --continue   # conflict resolve করে (add করার পর) পরের commit replay চালিয়ে যাওয়া
git rebase --skip       # এই commit সম্পূর্ণ বাদ দিয়ে পরেরটায় চলে যাওয়া (এই commit-এর পরিবর্তন হারিয়ে যাবে)
git rebase --abort      # পুরো rebase বাতিল, শুরুর আগের অবস্থায় সম্পূর্ণ ফিরে যাওয়া

--skip সাবধানে ব্যবহার করা উচিত — এটা conflict resolve করে না, বরং পুরো commit-টাকেই ফেলে দেয়, যা ইচ্ছাকৃত না হলে ডেটা হারানোর কারণ হতে পারে।

--rebase-merges: merge commit structure বজায় রাখা

ডিফল্ট rebase merge commit-গুলো "flatten" করে ফেলে — merge structure হারিয়ে সব commit একটা linear সিকোয়েন্সে replay হয়। --rebase-merges merge commit topology বজায় রেখে rebase করে — জটিল branch history-সহ একটা বড় feature branch rebase করতে দরকার হয় যখন সেই branch-এর ভেতরেই sub-merge আছে।

git rebase -i --rebase-merges main

এই মোডে interactive editor-এ merge action-ও দেখা যায়, যা নির্দিষ্ট করে কোথায় merge commit আবার তৈরি হবে replay-এর সময়।

নিয়মটা

যে commit ইতিমধ্যে push হয়ে গেছে এবং অন্য কেউ pull করে ফেলেছে, সেটা কখনো rebase করবেন না।

কেন — hash বদলে যাওয়ার সরাসরি ফলাফল

আগের মডিউলে দেখা গেছে rebase প্রতিটা commit-এর নতুন hash তৈরি করে। ধরুন আপনি feature/x push করেছেন, সহকর্মী সেটা pull করে তার উপর নিজের কাজ করেছেন। এখন আপনি feature/x rebase করে আবার push (force) করলে:

• আপনার নতুন commit hash-গুলো সহকর্মীর কাছে সম্পূর্ণ অপরিচিত — তার local ইতিহাসের সাথে কোনো সংযোগ নেই।
• git pull করলে তার কাছে দেখাবে যেন হঠাৎ অনেক নতুন commit এসেছে, আর তার নিজের কাজ পুরনো (rebase-এর আগের) hash-চেইনের সাথে আটকে আছে — একটা বিশাল, বিভ্রান্তিকর conflict বা duplicate commit তৈরি হবে।
• তাকে ম্যানুয়ালি git rebase --onto বা পুরো branch আবার তৈরি করে সমাধান করতে হবে — বেদনাদায়ক, error-prone প্রক্রিয়া।

ব্যতিক্রম: নিজের একার branch

যদি একটা feature branch শুধুমাত্র আপনি একাই কাজ করছেন (কেউ pull করেনি), rebase করে force-push করা সম্পূর্ণ নিরাপদ ও স্বাভাবিক — এটাই বরং PR history পরিষ্কার রাখার প্রস্তাবিত উপায়।

টিম নিয়ম হিসেবে

সংক্ষেপে: rebase local/private history-এর জন্য, merge/revert public/shared history-এর জন্য।

লক্ষ্য

একগুচ্ছ এলোমেলো "wip" commit-কে interactive rebase দিয়ে পরিষ্কার, অর্থবহ ইতিহাসে রূপান্তর করা, আর --fixup/--autosquash এবং --onto ব্যবহার করা।

mkdir git-rebase-lab && cd git-rebase-lab && git init
echo "base" > app.py && git add . && git commit -m "initial commit"

git commit --allow-empty -m "wip: start login feature"
git commit --allow-empty -m "wip: more login work"
git commit --allow-empty -m "fix typo in login"
git commit --allow-empty -m "add login tests"
git log --oneline

# ১) interactive rebase দিয়ে squash/fixup/reword করুন
git rebase -i HEAD~4
# এডিটরে বদলান:
#   pick <hash1> wip: start login feature   → reword করে "add login form"
#   fixup <hash2> wip: more login work
#   fixup <hash3> fix typo in login
#   pick <hash4> add login tests
git log --oneline    # এখন মাত্র ২টা পরিষ্কার commit থাকবে

# ২) --fixup ও --autosquash পরীক্ষা
git config --global rebase.autosquash true
echo "form code" > form.py && git add . && git commit -m "add form validation"
echo "extra fix" >> form.py
git commit --fixup=HEAD -am "small fix"
git log --oneline -3    # "fixup! add form validation" commit দেখুন
git rebase -i --autosquash HEAD~3   # save করলেই fixup স্বয়ংক্রিয়ভাবে সাজানো থাকবে
git log --oneline

# ৩) --onto পরীক্ষা
git switch -c feature/a
git commit --allow-empty -m "feature a work 1"
git commit --allow-empty -m "feature a work 2"
git switch -c feature/b
git commit --allow-empty -m "feature b work 1"
git commit --allow-empty -m "feature b work 2"
git switch main
git rebase --onto main feature/a feature/b
git log --oneline feature/b    # শুধু feature b-এর ২টা commit, main-এর উপর বসানো

চ্যালেঞ্জ (নিজে করুন)

git rebase -i HEAD~2 চালিয়ে একটা commit-এ edit action সেট করুন, rebase থামলে git commit --amend দিয়ে সেই commit-এর মেসেজ ও কন্টেন্ট দুটোই বদলান, তারপর git rebase --continue দিয়ে শেষ করুন।

প্র.১ — rebase-এর পর commit hash কেন বদলে যায়, যদিও diff একই থাকে? উত্তর: commit hash কন্টেন্টের পাশাপাশি parent hash-এর উপরও নির্ভর করে (SHA checksum-এর অংশ)। rebase প্রতিটা commit-কে নতুন base-এর উপর replay করে, ফলে parent বদলে যায় — parent বদলালেই সম্পূর্ণ নতুন hash তৈরি হয়, যদিও diff/content অপরিবর্তিত থাকতে পারে।

প্র.২ — squash আর fixup-এর পার্থক্য কী? উত্তর: দুটোই বর্তমান commit-কে আগের commit-এর সাথে মিশিয়ে দেয়। squash দুই commit-এর মেসেজ একসাথে এডিট করার সুযোগ দেয়, fixup বর্তমান commit-এর মেসেজ সম্পূর্ণ বাদ দিয়ে নিঃশব্দে মিশিয়ে ফেলে।

প্র.৩ — --autosquash কীভাবে সময় বাঁচায়? উত্তর: git commit --fixup=<hash> দিয়ে টার্গেট commit উল্লেখ করে একটা fixup commit তৈরি করা যায়, আর --autosquash চালু থাকলে rebase editor স্বয়ংক্রিয়ভাবে সেই fixup commit-কে সঠিক টার্গেটের ঠিক পরে, সঠিক action সহ বসিয়ে দেখায় — ম্যানুয়াল reorder করার দরকার হয় না।

প্র.৪ — --onto-এর সিনট্যাক্সে তিনটা আর্গুমেন্ট কী বোঝায়? উত্তর: git rebase --onto <newbase> <oldbase> <branch> — <newbase> হলো নতুন যেখানে replay হবে, <oldbase> হলো replay শুরুর সীমা (exclusive, এই commit বাদ), <branch> হলো কোন branch-এর commit replay হবে।

প্র.৫ — rebase-এর সোনার নিয়ম কী, আর কেন লঙ্ঘন করলে সমস্যা হয়? উত্তর: ইতিমধ্যে push হয়ে যাওয়া এবং অন্য কেউ pull করে ফেলা commit কখনো rebase করা উচিত না। লঙ্ঘন করলে rebase-এর কারণে নতুন hash তৈরি হয়, যা সহকর্মীর local ইতিহাসের সাথে সম্পূর্ণ সম্পর্কহীন হয়ে যায় — পরের pull-এ বিশাল duplicate commit/conflict তৈরি হয়।

প্র.৬ — --rebase-merges কখন প্রয়োজন হয়? উত্তর: যখন rebase করা branch-এর ভেতরেই merge commit আছে যেগুলোর topology সংরক্ষণ করতে চান। ডিফল্ট rebase merge structure "flatten" করে সব commit-কে linear করে ফেলে; --rebase-merges সেই merge গঠন বজায় রেখে replay করে।

• git rebase --skip conflict resolve করে না, পুরো commit-ই ফেলে দেয় — অনেকে ভুলে conflict মার্কার এডিট না করেই --skip চালান, ভেবে এটা conflict বাদ দিয়ে এগিয়ে যাবে; আসলে পুরো commit-এর পরিবর্তনই বাদ পড়ে যায়।
• empty commit rebase-এর সময় নিঃশব্দে বাদ পড়ে যেতে পারে — যদি একটা commit-এর diff rebase-এর সময় খালি হয়ে যায় (যেমন আগেই একই পরিবর্তন অন্য commit-এ চলে এসেছে), ডিফল্টে Git সেটা বাদ দিয়ে দেয় (--keep-empty না দিলে) — commit history-তে গণনা মিলবে না বলে বিভ্রান্তি হতে পারে।
• --autostash rebase conflict হলে stash pop স্বয়ংক্রিয়ভাবে না-ও ঘটতে পারে — conflict সমাধানের পরে --continue/--abort করার পর ম্যানুয়ালি git stash list চেক করে নিশ্চিত হওয়া উচিত stash ঠিকমতো পপ হয়েছে কিনা।
• rebase চলাকালীন git status "interactive rebase in progress" দেখালেও git log স্বাভাবিক দেখাতে পারে বিভ্রান্তিকরভাবে — HEAD আসলে detached অবস্থায় থাকে rebase চলাকালীন (.git/rebase-merge/head-name ফাইলে আসল branch নাম সংরক্ষিত থাকে), rebase শেষ হলে তবেই branch ref আপডেট হয়ে আবার attach হয়।

git cherry-pick rebase-এর "replay" মেকানিজমেরই একটা single-commit, targeted সংস্করণ — পুরো branch না, শুধু একটা নির্দিষ্ট commit অন্য branch-এ নিয়ে আসা। এই মডিউলে single/multiple/range cherry-pick, -n/-x/-m ফ্ল্যাগ, conflict flow, আর সবচেয়ে সাধারণ বাস্তব ব্যবহার — hotfix backporting — কভার হবে।

একটা নির্দিষ্ট commit তুলে আনা

git cherry-pick একটা নির্দিষ্ট commit-এর diff নিয়ে বর্তমান branch-এ সেটা নতুন commit হিসেবে apply করে — অনেকটা rebase-এর একটামাত্র commit replay করার মতো, কিন্তু পুরো branch-এর বদলে ম্যানুয়ালি বেছে নেওয়া।

git switch release/v2.1
git cherry-pick a1b2c3d
# a1b2c3d-এর পরিবর্তন এখন release/v2.1-এ একটা নতুন commit হিসেবে যুক্ত হলো, নতুন hash সহ

একাধিক commit

git cherry-pick a1b2c3d e4f5g6h i7j8k9l
# তিনটা commit একের পর এক apply হবে, নিজস্ব ক্রমে

Range cherry-pick

git cherry-pick main~5..main~2
# main~5 (exclusive) থেকে main~2 (inclusive) পর্যন্ত সব commit apply হবে

সতর্কতা: A..B সিনট্যাক্স A-কে exclude করে, B-কে include করে — অনেকে ভুলে ভাবেন দুটোই inclusive। সঠিকভাবে A-সহ চাইলে A^..B ব্যবহার করতে হবে।

ভেতরে কী ঘটে

প্রতিটা cherry-pick আসলে তিনটা ধাপ: (১) সেই commit-এর tree-কে তার নিজের parent-এর tree-এর সাথে diff করে বের করা কী বদলেছে, (২) সেই diff বর্তমান working tree/index-এ apply করা, (৩) একটা নতুন commit object তৈরি করা — নতুন parent (বর্তমান HEAD), তাই নতুন hash, কিন্তু কন্টেন্ট (diff) মূল commit-এর মতোই।

রিয়েল-লাইফ উদাহরণ

main-এ একটা critical security fix commit হয়েছে, কিন্তু release/v2.1 branch অনেক আগেই main থেকে diverge করেছে — পুরো main merge করা সম্ভব না (অনেক অপ্রাসঙ্গিক পরিবর্তন চলে আসবে)। শুধু সেই একটা fix commit cherry-pick করে release/v2.1-এ আনা হয়।

-n / --no-commit: শুধু apply করা, commit না

git cherry-pick -n a1b2c3d
# পরিবর্তন staged হয়ে যাবে, কিন্তু কোনো commit তৈরি হবে না
git status   # "Changes to be committed"

ব্যবহার: একাধিক cherry-pick-এর ফলাফল একসাথে একটা commit-এ combine করতে চাইলে, বা apply করার পর আরও কিছু ম্যানুয়াল পরিবর্তন যোগ করে তারপর একবারে commit করতে চাইলে:

git cherry-pick -n commit1 commit2 commit3
# তিনটা diff-ই staged, এখন একসাথে commit
git commit -m "backport: combine three related fixes"

-x: মূল commit hash-এর রেফারেন্স রাখা

git cherry-pick -x a1b2c3d

এটা নতুন commit message-এর শেষে স্বয়ংক্রিয়ভাবে একটা লাইন যোগ করে:

fix null pointer in payment handler

(cherry picked from commit a1b2c3d4e5f6...)

কেন এটা ভালো প্র্যাকটিস

-x ছাড়া cherry-pick করা commit দেখতে সম্পূর্ণ স্বাধীন, নতুন commit মনে হয় — কেউ পরে জানতে পারবে না এটা কোথা থেকে এসেছে। -x দিয়ে ট্রেসেবিলিটি বজায় থাকে: git log --grep="cherry picked from" দিয়ে খুঁজে বের করা যায় কোন কোন commit backport হয়েছে, বা main-এর একটা commit release-branch-এ পৌঁছেছে কিনা যাচাই করা যায় সহজে। Open-source প্রজেক্টে (Linux kernel-সহ) এটা একটা প্রায়-বাধ্যতামূলক convention।

সমস্যা: merge commit-এর দুটো parent

সাধারণ commit-এর diff স্পষ্ট (parent-এর সাথে তুলনা)। কিন্তু merge commit-এর দুটো parent থাকে — কোন parent-এর সাপেক্ষে diff নেওয়া হবে সেটা নির্দিষ্ট না করলে Git জানে না কী apply করতে হবে।

git cherry-pick <merge-commit-hash>
# error: commit <hash> is a merge but no -m option was given.

সমাধান: -m দিয়ে mainline নির্দিষ্ট করা

git cherry-pick -m 1 <merge-commit-hash>

-m 1 মানে parent নাম্বার ১-কে ভিত্তি (mainline) ধরে diff বের করা হবে — সাধারণত parent 1 হলো যে branch-এ merge করা হয়েছিলো, আর parent 2 হলো যেটা merge করা হয়েছিলো। -m 1 দিলে merge commit-এ merge হওয়া branch-এর যোগ করা পরিবর্তনগুলোই apply হয়।

কখন প্রয়োজন হয়

একটা পুরো feature (merge commit হিসেবে main-এ এসেছে) সম্পূর্ণভাবে অন্য একটা release branch-এ backport করতে চাইলে, পুরো feature branch cherry-pick না করে শুধু সেই merge commit-টাই cherry-pick করা যায় -m 1 দিয়ে — merge-এর মধ্যে থাকা সব পরিবর্তন একসাথে একটা নতুন commit হিসেবে চলে আসবে।

সতর্কতা

merge commit cherry-pick করা জটিল হতে পারে যদি সেই merge-এর ভেতরে নিজেই conflict resolution ছিলো — -m দিয়ে বেছে নেওয়া mainline-এর ভুল দিক দিলে সম্পূর্ণ ভুল diff apply হয়ে যেতে পারে, তাই ব্যবহারের আগে git show <merge-hash> দিয়ে parent সংখ্যা ও দিক ভালোভাবে বুঝে নেওয়া জরুরি।

Cherry-pick-এও conflict হতে পারে

যেহেতু cherry-pick ভেতরে diff apply করার একটা প্রক্রিয়া (অনেকটা 3-way merge-এর মতো, commit আর তার parent-এর diff বর্তমান tree-তে apply করা), টার্গেট branch-এ একই লাইনে ভিন্ন পরিবর্তন থাকলে conflict দেখা দিতে পারে — ঠিক merge conflict-এর মতোই marker সহ।

git cherry-pick a1b2c3d
# CONFLICT (content): Merge conflict in payment.py
# error: could not apply a1b2c3d... fix null pointer

তিনটা পথ

# marker এডিট করে সমাধানের পর:
git add payment.py
git cherry-pick --continue

# এই cherry-pick সম্পূর্ণ বাদ দিয়ে (একাধিক cherry-pick চলাকালীন) পরেরটায় যাওয়া:
git cherry-pick --skip

# পুরো cherry-pick অপারেশন বাতিল, শুরুর আগের অবস্থায় ফেরা:
git cherry-pick --abort

একাধিক cherry-pick-এ conflict সিকোয়েন্স

git cherry-pick a1b2c3d e4f5g6h i7j8k9l
# a1b2c3d সফল
# e4f5g6h-এ conflict — resolve করে --continue করলে i7j8k9l-এ এগোবে

.git/CHERRY_PICK_HEAD ফাইলে চলমান cherry-pick-এর অবস্থা ট্র্যাক থাকে — git status চালালে "You are currently cherry-picking commit..." মেসেজ দেখা যায়, যা confirm করে কোন commit-এর প্রক্রিয়া চলছে।

সবচেয়ে সাধারণ বাস্তব দৃশ্য

একটা প্রোডাকশন incident ধরা পড়েছে — একটা critical bug। ফিক্স main branch-এ তৈরি ও merge হয়। কিন্তু production-এ এখন চলছে release/v2.1 branch, যেটা main-এর অনেক পুরনো একটা snapshot থেকে branch হয়েছিলো এবং তারপর main-এ অনেক নতুন, অসম্পূর্ণ ফিচার যোগ হয়ে গেছে যেগুলো এখনো production-এ যাওয়ার জন্য প্রস্তুত না।

# hotfix main-এ merge হয়েছে হিসেবে ধরে নিন hash: f1a2b3c

git switch release/v2.1
git cherry-pick -x f1a2b3c
# শুধু এই ফিক্স-টাই release/v2.1-এ এলো, main-এর অন্য কোনো অসম্পূর্ণ কাজ ছাড়াই

git push origin release/v2.1
# এখন হটফিক্স deploy করা যাবে production-এ, বাকি অস্থির ফিচার ছাড়াই

কেন merge না, cherry-pick

যদি এই মুহূর্তে git merge main করা হতো release/v2.1-এ, তাহলে main-এর সব অসম্পূর্ণ/অপরীক্ষিত ফিচার একসাথে release-এ চলে আসতো — একটা QA-না-করা অবস্থায় production-এ deploy করার ঝুঁকি। Cherry-pick সুনির্দিষ্টভাবে শুধু প্রয়োজনীয় একটা commit বেছে আনার সুযোগ দেয়, বাকি সব ইতিহাস থেকে আলাদা রেখে।

একাধিক release branch-এ একই fix

Multi-version সাপোর্ট করা প্রজেক্টে (যেমন একই সময়ে v2.1, v2.2, v3.0 branch maintain করা), একটা security fix সাধারণত main-এ প্রথমে যায়, তারপর -x সহ প্রতিটা active release branch-এ আলাদাভাবে cherry-pick হয় — প্রতিটাতে ট্রেসেবিলিটি বজায় রেখে।

লক্ষ্য

একটা main branch থেকে একটা নির্দিষ্ট bugfix commit release branch-এ cherry-pick করা, conflict সহ ও ছাড়া দুটো দৃশ্যই দেখা।

mkdir git-cherry-lab && cd git-cherry-lab && git init
echo "def process(): return 1" > payment.py
git add . && git commit -m "initial payment logic"

# release branch তৈরি (পুরনো snapshot হিসেবে)
git branch release/v1.0

# main-এ এগিয়ে যান — কয়েকটা ফিচার commit + একটা bugfix
echo "def process(): return None  # BUG!" > payment.py
git commit -am "feature: refactor payment (introduces bug)"
sed -i 's/return None  # BUG!/return 0  # fixed null bug/' payment.py
git commit -am "fix: null pointer bug in payment processing"
FIX_HASH=$(git rev-parse HEAD)
echo "def new_feature(): pass" >> payment.py
git commit -am "feature: add unrelated new feature"

git log --oneline

# ১) শুধু fix commit release-এ backport করুন
git switch release/v1.0
git cherry-pick -x $FIX_HASH
git log --oneline    # cherry-pick commit + "(cherry picked from...)" নোট সহ
cat payment.py       # শুধু fix আছে, unrelated feature নেই

# ২) conflict সহ দৃশ্য তৈরি করুন
git switch main
sed -i 's/return 0  # fixed null bug/return 0  # v2 style fix/' payment.py
git commit -am "refine fix message style"
CONFLICT_HASH=$(git rev-parse HEAD)

git switch release/v1.0
sed -i 's/return 0  # fixed null bug/return -1  # release specific value/' payment.py
git commit -am "release-specific tweak"

git cherry-pick $CONFLICT_HASH
# CONFLICT হবে — marker দেখুন, সমাধান করুন
cat payment.py
# marker resolve করে:
git add payment.py
git cherry-pick --continue

চ্যালেঞ্জ (নিজে করুন)

git cherry-pick -n দিয়ে দুটো ভিন্ন commit no-commit মোডে apply করে, তারপর একসাথে একটা মাত্র commit বানিয়ে দেখুন কীভাবে দুটো আলাদা fix একটা "combined backport" commit হয়ে যায়।

প্র.১ — cherry-pick আর rebase-এর মধ্যে conceptual মিল কী? উত্তর: দুটোই "replay" মেকানিজম — একটা কমিটের diff নিয়ে নতুন parent-এর উপর নতুন commit হিসেবে apply করা। rebase পুরো branch-এর একাধিক commit ক্রমান্বয়ে replay করে, cherry-pick একটা বা নির্বাচিত কয়েকটা নির্দিষ্ট commit replay করে।

প্র.২ — -x ফ্ল্যাগ কেন ব্যবহার করা ভালো প্র্যাকটিস? উত্তর: এটা নতুন commit message-এ "(cherry picked from commit ...)" লাইন যোগ করে ট্রেসেবিলিটি বজায় রাখে — পরে বোঝা যায় কোন commit কোথা থেকে এসেছে, যা multi-branch backport ট্র্যাক করতে গুরুত্বপূর্ণ।

প্র.৩ — merge commit cherry-pick করতে -m ফ্ল্যাগ কেন বাধ্যতামূলক? উত্তর: merge commit-এর দুটো parent থাকে, তাই কোন parent-এর সাপেক্ষে diff নেওয়া হবে তা স্পষ্ট না করলে Git জানে না কী apply করতে হবে। -m 1/-m 2 দিয়ে mainline নির্দিষ্ট করতে হয়।

প্র.৪ — A..B range cherry-pick-এ A ইনক্লুড হয় কি? উত্তর: না, A..B A-কে exclude করে, B পর্যন্ত (inclusive) সব commit নেয়। A-সহ চাইলে A^..B ব্যবহার করতে হয়।

প্র.৫ — hotfix backport-এ merge না করে cherry-pick করা হয় কেন? উত্তর: merge করলে source branch-এর সব ইতিহাস (সব অসম্পূর্ণ/অপরীক্ষিত ফিচার সহ) চলে আসবে টার্গেট branch-এ। cherry-pick শুধু নির্দিষ্ট, প্রয়োজনীয় একটা commit বেছে আনে, বাকি অপ্রাসঙ্গিক ইতিহাস থেকে বিচ্ছিন্ন রেখে।

প্র.৬ — -n ফ্ল্যাগ কখন কাজে লাগে? উত্তর: যখন একাধিক commit apply করে সেগুলোকে একসাথে একটা মাত্র commit-এ combine করতে চান, বা apply করার পর অতিরিক্ত ম্যানুয়াল পরিবর্তন যোগ করে একবারে commit করতে চান — -n commit স্কিপ করে শুধু staging পর্যন্ত করে।

• cherry-pick করা commit এবং মূল commit — দুটোর diff একই হলেও hash সম্পূর্ণ ভিন্ন — git log --all দুটোকেই আলাদা, স্বাধীন commit হিসেবে দেখাবে, -x ছাড়া কোনো লিংক দৃশ্যমান হবে না, ফলে duplicate work মনে হতে পারে যদি ট্রেসেবিলিটি না রাখা হয়।
• একই commit দুইবার cherry-pick করলে দ্বিতীয়বার conflict বা "empty commit" হতে পারে — Git ধরতে পারে diff ইতিমধ্যে apply হয়ে গেছে, তখন git cherry-pick --allow-empty বা --skip দরকার হতে পারে অবস্থাভেদে।
• git cherry-pick চলাকালীন git status "cherry-pick in progress" দেখাবে কিন্তু HEAD detached হয় না — cherry-pick rebase-এর থেকে ভিন্ন, এটা বর্তমান branch-এই সরাসরি নতুন commit যোগ করে, তাই branch attach-ই থাকে; conflict হলে branch-ই থেকে যায় resolve করার জন্য।
• range cherry-pick-এ merge commit থাকলে ডিফল্টে ব্যর্থ হবে — প্রতিটা merge commit-এর জন্য আলাদাভাবে -m লাগবে, নাহলে পুরো range cherry-pick মাঝপথে থেমে যাবে সেই merge commit-এ এসে।

এই Phase-এর শেষ মডিউল, এবং একটা অর্থে সবচেয়ে গুরুত্বপূর্ণ — কারণ git reflog হলো সেই সেফটি নেট যা আগের সব মডিউলের (reset --hard, rebase, cherry-pick conflict, detached HEAD) ভুল থেকে উদ্ধার করার শেষ ভরসা। কভার হবে: reflog কী ও কীভাবে HEAD movement ট্র্যাক করে, HEAD@{n} সিনট্যাক্স, একটা সম্পূর্ণ recovery ওয়াকথ্রু, expiry policy, আর git fsck --lost-found — reflog-ও ব্যর্থ হলে শেষ উপায়। মডিউলের শেষে Phase 4-এর একটা checkpoint gate থাকবে।

reflog কী

git reflog হলো একটা লোকাল লগ যা HEAD (এবং প্রতিটা branch) কোথায় কোথায় গিয়েছে তার প্রতিটা পদক্ষেপ রেকর্ড করে রাখে — commit, checkout, merge, rebase, reset, cherry-pick — HEAD যেকোনো কারণে move করলেই একটা entry যোগ হয়।

git reflog
# 7a1f9c2 (HEAD -> main) HEAD@{0}: commit: fix payment bug
# 3b8e0a1 HEAD@{1}: reset: moving to HEAD~1
# 9d2e7b1 HEAD@{2}: commit: add validation
# 5c1a0f3 HEAD@{3}: checkout: moving from feature/x to main

এটা commit history থেকে সম্পূর্ণ ভিন্ন জিনিস

git log দেখায় commit graph-এর ancestry — কোন commit কোন commit-এর parent। git reflog দেখায় সময়ের ক্রমানুসারে HEAD আক্ষরিকভাবে কোথায় কোথায় ছিলো — এটা একটা "activity log", ইতিহাসের গ্রাফ না। তাই একটা reset --hard-এর পর git log আর সেই "হারানো" commit দেখাবে না, কিন্তু git reflog-এ সেটা এখনো একটা entry হিসেবে থেকে যায়।

Branch-ভিত্তিক reflog আলাদা

শুধু HEAD-এরই না, প্রতিটা branch ref-এরও নিজস্ব reflog আছে:

git reflog show main
git reflog show feature/x

৯০ দিন ডিফল্ট expiry

reflog entry চিরকাল থাকে না — ডিফল্ট কনফিগ (gc.reflogExpire=90 days reachable commit-এর জন্য, gc.reflogExpireUnreachable=30 days unreachable commit-এর জন্য) অনুযায়ী পুরনো entry স্বয়ংক্রিয়ভাবে git gc চলাকালীন মুছে যায়। এইজন্যই reflog একটা সাময়িক সেফটি নেট, স্থায়ী ব্যাকআপ না।

রেফারেন্সিং সিনট্যাক্স

HEAD@{n} মানে HEAD এখন যেখানে আছে তার থেকে n ধাপ পেছনের reflog entry। এটা HEAD~n (commit ancestry-তে n ধাপ পেছনে) থেকে সম্পূর্ণ ভিন্ন জিনিস — একটা সময়-ভিত্তিক (reflog), আরেকটা গ্রাফ-ভিত্তিক (parent chain)।

git reflog
# HEAD@{0}: commit: fix bug
# HEAD@{1}: reset: moving to HEAD~2
# HEAD@{2}: rebase (finish): returning to refs/heads/main
# HEAD@{3}: commit: wip work

git checkout HEAD@{1}   # reset চালানোর ঠিক আগের অবস্থায় ফিরে যাওয়া
git diff HEAD@{3} HEAD@{0}   # রিবেসের আগে ও পরে তুলনা

সময়-ভিত্তিক সিনট্যাক্সও সম্ভব

git checkout 'HEAD@{5 minutes ago}'
git checkout 'HEAD@{yesterday}'
git checkout 'main@{2.days.ago}'

Git প্রতিটা reflog entry-র সাথে একটা timestamp রাখে, তাই human-readable সময় দিয়েও নির্দিষ্ট মুহূর্তের অবস্থা খুঁজে বের করা যায় — "গতকাল দুপুরে কোড কেমন ছিলো" জাতীয় প্রশ্নের উত্তর দিতে দরকারি।

branch-নির্দিষ্ট রেফারেন্স

git reflog show feature/x
git checkout feature/x@{2}   # feature/x branch-এর reflog-এর ২ ধাপ আগের অবস্থা

HEAD@{n} আর <branch>@{n} — দুটোই একই সিনট্যাক্স প্যাটার্ন, শুধু কোন ref-এর reflog দেখা হচ্ছে সেটা আলাদা।

দৃশ্য: ভুল করে reset --hard চালিয়ে ফেলা

mkdir git-reflog-lab && cd git-reflog-lab && git init
echo "v1" > work.txt && git add . && git commit -m "commit 1"
echo "v2" > work.txt && git commit -am "commit 2 - important feature"
echo "v3" > work.txt && git commit -am "commit 3 - another important fix"
git log --oneline
# c3d4e5f commit 3 - another important fix
# b2c3d4e commit 2 - important feature
# a1b2c3d commit 1

# ভুল করে দুই কমিট পিছিয়ে যাওয়া!
git reset --hard HEAD~2
git log --oneline
# a1b2c3d commit 1     ← আতঙ্ক! commit 2 আর 3 কোথায়?

ধাপে ধাপে রিকভারি

# ধাপ ১: reflog দেখুন
git reflog
# a1b2c3d HEAD@{0}: reset: moving to HEAD~2
# c3d4e5f HEAD@{1}: commit: commit 3 - another important fix   ← এটাই দরকার!
# b2c3d4e HEAD@{2}: commit: commit 2 - important feature
# a1b2c3d HEAD@{3}: commit: commit 1

# ধাপ ২: হারানো commit-এর hash শনাক্ত করুন (c3d4e5f, HEAD@{1})
git show c3d4e5f --stat   # নিশ্চিত হন এটাই সঠিক commit

# ধাপ ৩: HEAD সেই অবস্থায় ফিরিয়ে নিন
git reset --hard HEAD@{1}
# অথবা সরাসরি hash দিয়ে:
git reset --hard c3d4e5f

git log --oneline
# c3d4e5f commit 3 - another important fix    ← ফিরে এসেছে!
# b2c3d4e commit 2 - important feature
# a1b2c3d commit 1

বিকল্প: নতুন branch দিয়ে নিরাপদে রিকভার

যদি নিশ্চিত না থাকেন বর্তমান branch-এ সরাসরি reset করা ঠিক হবে কিনা, বরং একটা আলাদা branch-এ commit-টা বাঁচিয়ে রাখুন:

git branch recovered-work c3d4e5f
git log --oneline recovered-work

এই ওয়াকথ্রু-টাই প্রমাণ করে কেন Phase 4-এর প্রথম কথাটা সত্য: reset --hard "ভয়ংকর" মনে হলেও, reflog-এর কারণে এটা প্রায় সবসময় রিভার্সিবল — যতক্ষণ পর্যন্ত git gc reflog expire করে না দেয়।

reflog চিরস্থায়ী না

ডিফল্ট কনফিগারেশন:

git config --get gc.reflogExpire            # সাধারণত 90 days (reachable commit)
git config --get gc.reflogExpireUnreachable # সাধারণত 30 days (unreachable commit)

git gc (স্বয়ংক্রিয়ভাবে মাঝেমধ্যে চলে, অথবা ম্যানুয়ালি git gc চালানো যায়) এই সময়সীমা পার হওয়া reflog entry মুছে দেয়, আর তারপর সেই entry-র সাথে যুক্ত unreachable commit object-ও (যদি অন্য কোনো ref থেকে reachable না হয়) স্থায়ীভাবে মুছে ফেলা হয়।

ম্যানুয়ালি নিয়ন্ত্রণ করা

git reflog expire --expire=now --all
# সব reflog entry অবিলম্বে expire করা (বিপজ্জনক — টেস্টিং/ক্লিনআপের জন্য)

git reflog expire --expire-unreachable=now refs/heads/main
# শুধু main branch-এর unreachable entry-গুলো এক্ষুনি expire করা

দীর্ঘমেয়াদী প্রকল্পে retention বাড়ানো

কিছু টিম দীর্ঘমেয়াদী safety net চেয়ে expiry বাড়িয়ে দেয়:

git config --global gc.reflogExpire "180 days"
git config --global gc.reflogExpireUnreachable "90 days"

বাস্তব প্রভাব

মনে রাখা জরুরি: একটা "হারানো" commit রিকভার করার একটা সময়সীমা আছে। একটা ভুল করার সাথে সাথে reflog দিয়ে ঠিক করে নেওয়া সবসময় সবচেয়ে নিরাপদ — মাসের পর মাস অপেক্ষা করলে সেই সেফটি নেটও উবে যেতে পারে git gc চলার পর।

যখন reflog-ও কাজে আসে না

যদি reflog-এও কোনো entry না থাকে (যেমন reflog disabled ছিলো, bare repository-তে ডিফল্টে reflog off থাকে, অথবা expire হয়ে গেছে), তবুও একটা শেষ উপায় আছে — dangling object খোঁজা।

dangling object কী

Git কখনো commit object সাথে সাথে মুছে দেয় না, এমনকি কোনো ref থেকে reachable না হলেও — যতক্ষণ না git gc চলে এবং grace period (ডিফল্ট ~২ সপ্তাহ, gc.pruneExpire) পার হয়। এই সময়ের মধ্যে সেই object "dangling" অবস্থায় ডিস্কে পড়ে থাকে — কোনো ref এটাকে পয়েন্ট করছে না, কিন্তু object database-এ এখনো আছে।

git fsck --lost-found
# dangling commit c3d4e5f1a2b3...
# dangling blob 9f8e7d6c5b4a...

রিকভারি

git show c3d4e5f1a2b3    # কন্টেন্ট দেখে যাচাই করুন এটাই আপনার হারানো commit কিনা
git branch recovered c3d4e5f1a2b3   # নতুন branch তৈরি করে বাঁচিয়ে ফেলুন

dangling blob-এর ক্ষেত্রে (যেমন git add করা কিন্তু কখনো commit না হওয়া ফাইল), সরাসরি কন্টেন্ট বের করা যায়:

git cat-file -p 9f8e7d6c5b4a > recovered-file.txt

সীমাবদ্ধতা

git fsck --lost-found শুধু তখনই কাজ করে যখন object এখনো .git/objects-এ পুরোপুরি garbage-collect হয়নি। git gc --aggressive বা অনেক দিন পার হলে এটাও ব্যর্থ হবে — এটাই একদম শেষ, সীমিত-সময়ের সেফটি নেট, প্রথম পছন্দ কখনোই না (প্রথমে সবসময় git reflog চেক করুন)।

মূল কথা

git reflog সম্পূর্ণভাবে লোকাল — এটা .git/logs/ ডিরেক্টরিতে সংরক্ষিত থাকে, যেটা .git/objects-এর মতো কন্টেন্ট-অ্যাড্রেসেবল shared object store না, বরং প্রতিটা developer-এর নিজস্ব মেশিনের একটা ব্যক্তিগত activity log। git push/git fetch/git clone — এসব অপারেশন কখনোই reflog ট্রান্সফার করে না।

কেন এই ডিজাইন সিদ্ধান্ত

• reflog সাইজ ও প্রাসঙ্গিকতা ব্যক্তিগত — একজন developer-এর ১০০টা reset/checkout movement আরেকজনের কাছে অর্থহীন এবং অপ্রয়োজনীয় ডেটা।
• প্রাইভেসি — reflog দেখায় আপনি ঠিক কী কী পরীক্ষা-নিরীক্ষা করেছেন, কতবার ভুল করেছেন, কোন detached HEAD এক্সপ্লোর করেছেন — এগুলো ব্যক্তিগত workflow তথ্য, remote-এ শেয়ার করার প্রয়োজন নেই।
• Object model-এর সাথে সামঞ্জস্যপূর্ণ না — Git-এর মূল shared ডেটা হলো commit/tree/blob object আর ref — এগুলো immutable, ডিটারমিনিস্টিক hash দিয়ে চেনা যায়। reflog একটা mutable, সময়-ক্রমিক লগ — সম্পূর্ণ ভিন্ন ধরনের ডেটা, শেয়ার করার জন্য উপযুক্ত মডেল না।

ব্যবহারিক ফলাফল

একজন সহকর্মীর মেশিনে হারানো কমিট আপনার reflog দিয়ে রিকভার করতে পারবেন না — যদি সেই commit কখনো push না হয়ে থাকে, সেটা শুধু তার মেশিনের local object store-এ আছে, আপনার কাছে কোনো ট্রেসও নেই।

এইজন্যই গুরুত্বপূর্ণ কাজ নিয়মিত push করে রাখা উচিত (এমনকি একটা draft/wip branch-এ হলেও) — reflog শুধু নিজের ভুল থেকে নিজেকে বাঁচানোর টুল, টিমের ব্যাকআপ সিস্টেম না।

লক্ষ্য

reflog-এর retention behavior বোঝা এবং dangling object খুঁজে বের করার প্র্যাকটিস।

mkdir git-reflog-expiry-lab && cd git-reflog-expiry-lab && git init
echo "v1" > file.txt && git add . && git commit -m "commit 1"
echo "v2" > file.txt && git commit -am "commit 2"
LOST_HASH=$(git rev-parse HEAD)
git reset --hard HEAD~1

# ১) reflog-এ এখনো commit 2 দেখা যাচ্ছে কিনা যাচাই করুন
git reflog | grep "commit 2"

# ২) branch থেকে reflog-এর সম্পর্ক ভাঙুন (dangling অবস্থা সিমুলেট)
git reflog expire --expire=now --all
git reflog | grep "commit 2"   # আর দেখাবে না

# ৩) কিন্তু object এখনো object database-এ আছে কিনা দেখুন
git cat-file -t $LOST_HASH   # "commit" দেখাবে — এখনো আছে!
git fsck --lost-found
# dangling commit <LOST_HASH>

# ৪) fsck দিয়ে রিকভার করুন
git show $LOST_HASH --stat
git branch recovered-via-fsck $LOST_HASH
git log --oneline recovered-via-fsck

# ৫) dangling blob-ও পরীক্ষা করুন
echo "never committed" > staged-only.txt
git add staged-only.txt
BLOB_HASH=$(git rev-parse :staged-only.txt)
git reset --hard HEAD   # staged ফাইল হারিয়ে গেলো working dir থেকেও
git cat-file -p $BLOB_HASH   # কিন্তু blob content এখনো উদ্ধারযোগ্য!

চ্যালেঞ্জ (নিজে করুন)

git reflog expire --expire=now --all চালানোর পর সাথে সাথে git gc --prune=now চালিয়ে দেখুন dangling commit-টা কি এবার সত্যিই permanently মুছে যায় এবং git fsck --lost-found আর কিছু দেখায় না — এটাই "reflog + gc" মিলে সত্যিকারের ডেটা ধ্বংসের শেষ ধাপ।

প্র.১ — git reflog আর git log-এর মৌলিক পার্থক্য কী? উত্তর: git log commit ancestry (parent-child গ্রাফ) দেখায়। git reflog সময়ের ক্রমানুসারে HEAD/branch ref আক্ষরিকভাবে কোথায় কোথায় ছিলো তার activity log দেখায় — reset, checkout, rebase, commit সব movement সহ, এমনকি এখন unreachable commit-ও।

প্র.২ — git reset --hard-এর পর হারানো কমিট কীভাবে ধাপে ধাপে ফিরে পাবেন? উত্তর: প্রথমে git reflog চালিয়ে হারানো commit-এর hash/HEAD@{n} খুঁজে বের করুন, git show <hash> দিয়ে যাচাই করুন এটাই সঠিক commit কিনা, তারপর git reset --hard <hash> (বা নিরাপদে git branch recovered <hash>) দিয়ে সেটা ফিরিয়ে আনুন বা বাঁচিয়ে রাখুন।

প্র.৩ — reflog entry কি চিরকাল থাকে? উত্তর: না, ডিফল্টে reachable commit-এর entry ৯০ দিন (gc.reflogExpire) এবং unreachable commit-এর entry ৩০ দিন (gc.reflogExpireUnreachable) পর git gc চলাকালীন expire হয়ে যায়।

প্র.৪ — reflog-ও যদি expire হয়ে যায়, তাহলে রিকভারির আর কোনো উপায় আছে কি? উত্তর: হ্যাঁ, git fsck --lost-found দিয়ে dangling commit/blob object খোঁজা যায় — যদি সেগুলো এখনো git gc-এর prune grace period (ডিফল্ট প্রায় ২ সপ্তাহ) পার না হয়ে থাকে। এটা একদম শেষ উপায়, নিশ্চিত না।

প্র.৫ — reflog কি push/clone-এর মাধ্যমে অন্য কারো কাছে যায়? উত্তর: না, reflog সম্পূর্ণ লোকাল (.git/logs/-এ), কখনো push/fetch/clone-এর অংশ হয় না। এইজন্য একজনের local, un-pushed commit হারিয়ে গেলে অন্য কারো reflog দিয়ে সেটা রিকভার করা যায় না।

প্র.৬ — HEAD@{2} আর HEAD~2-এর পার্থক্য কী? উত্তর: HEAD@{2} হলো reflog-এর ২ ধাপ আগের entry (সময়-ভিত্তিক, HEAD আক্ষরিকভাবে যেখানে ছিলো)। HEAD~2 হলো commit ancestry-তে বর্তমান commit থেকে ২ ধাপ আগের parent (গ্রাফ-ভিত্তিক)। দুটো সম্পূর্ণ ভিন্ন এবং প্রায়ই আলাদা commit নির্দেশ করে।

• bare repository-তে reflog ডিফল্টে বন্ধ থাকে (core.logAllRefUpdates=false ডিফল্ট bare repo-তে) — server-side bare repo-তে reflog-নির্ভর রিকভারি আশা করলে হতাশ হতে হবে; সার্ভারে হারানো ডেটার জন্য backup/fsck-ই একমাত্র ভরসা।
• git reflog expire --expire=now --all টেস্টিং-এর জন্য চালালে বাস্তব প্রোডাকশন রিপোতে ভুলে চালানো বিপর্যয়কর — এটা সাথে সাথে সব reflog entry মুছে দেয়, সেফটি নেট নিজেই উবে যায়; এই কমান্ড শুধু শেখা/পরীক্ষার sandbox repo-তে চালানো উচিত।
• git gc স্বয়ংক্রিয়ভাবেও চলতে পারে (নির্দিষ্ট threshold-এর পর loose object সংখ্যা বেশি হলে) — মানে reflog expiry সবসময় ম্যানুয়াল কমান্ডের ফল না, দৈনন্দিন ব্যবহারেও নিঃশব্দে ঘটতে পারে, তাই "সময় থাকতে রিকভার করুন" নীতি বাস্তবিকই গুরুত্বপূর্ণ।
• git fsck --lost-found ফলাফল দুই ধরনের ফোল্ডারে সংরক্ষিত হয় — .git/lost-found/commit/ আর .git/lost-found/other/ — পুরনো Git ভার্সনে এই ফাইলে সরাসরি ফলাফল লেখা হতো; আধুনিক Git-এ টার্মিনাল আউটপুটেই hash দেখানো হয়, কিন্তু কিছু পুরনো ডকুমেন্টেশনে এই ফোল্ডার-ভিত্তিক আচরণের রেফারেন্স এখনো দেখা যায়, যা বিভ্রান্তির কারণ হতে পারে।

আপনি কি পারবেন?

Phase 4 শেষ করার আগে নিজেকে সৎভাবে যাচাই করুন — এই প্রশ্নগুলোর উত্তর "হ্যাঁ, ব্যাখ্যা করতে পারি" হওয়া উচিত:

• একটা ভুল করে push করা git reset --hard থেকে কি reflog দিয়ে ধাপে ধাপে রিকভার করতে পারবেন — reflog দেখা, সঠিক entry শনাক্ত করা, আর ফিরিয়ে আনা?
• fast-forward আর 3-way merge-এর মধ্যে পার্থক্য এবং কোনটা কখন ঘটে তা কি একটা উদাহরণ দিয়ে ব্যাখ্যা করতে পারবেন?
• merge আর rebase-এ "ours"/"theirs"-এর অর্থ কেন উল্টে যায় তা কি স্পষ্টভাবে কাউকে বোঝাতে পারবেন?
• reset --soft/--mixed/--hard এর মধ্যে HEAD, index, আর working directory-তে ঠিক কী প্রভাব পড়ে তা টেবিল আকারে মনে করতে পারবেন?
• কেন shared/pushed branch-এ কখনো rebase বা reset --hard করা উচিত না, আর তার বদলে কী ব্যবহার করা উচিত তা কি ব্যাখ্যা করতে পারবেন?
• হাতে-কলমে একটা hotfix commit cherry-pick -x দিয়ে একটা release branch-এ backport করতে পারবেন, প্রয়োজনে conflict সামলে?

কেন এই Phase-টা সবচেয়ে মূল্যবান

Phase 4-এর ছয়টা মডিউল একসাথে গঠন করে "undo mastery" — Git-এ ভুল করা অনিবার্য (ভুল branch-এ commit, ভুল merge, ভুল rebase, ভুল reset), কিন্তু আসল দক্ষতা হলো ভয় না পেয়ে, ঠান্ডা মাথায়, সঠিক টুল (reflog, revert, cherry-pick, --abort) দিয়ে যেকোনো ভুল থেকে ফিরে আসতে পারা। এটাই সেই একক দক্ষতা যা একজন নতুন Git ব্যবহারকারীকে একজন আত্মবিশ্বাসী, ভয়হীন Git ব্যবহারকারীতে রূপান্তরিত করে — কারণ জানা থাকে, প্রায় সবকিছুই আসলে reversible।

এতক্ষণ যা শেখা হয়েছে তার প্রায় সবটাই একটা single local repository-র ভেতরে ঘটেছে — commit, branch, merge, rebase। কিন্তু বাস্তব জীবনে Git-এর আসল শক্তি প্রকাশ পায় যখন একাধিক মানুষ, একাধিক মেশিন থেকে, একই history-তে অবদান রাখে। এই Phase-এ remote কনসেপ্ট — কীভাবে একটা local repo অন্য একটা repo-র (GitHub, GitLab, বা একটা bare repo) সাথে কথা বলে, ডেটা আদান-প্রদান করে, আর কনফ্লিক্ট এড়িয়ে টিমওয়ার্ক করে — এই পুরো মেকানিজম খোলা হবে।

তিনটা মডিউল: Module 17-এ remote কী এবং কীভাবে রেজিস্টার হয় (internally .git/config আর refs/remotes/), Module 18-এ ডেটা সিঙ্ক করার তিনটা মূল কমান্ড — fetch, pull, push — এবং তাদের বিপজ্জনক কোণাগুলো (force push!), আর Module 19-এ টিমগুলো বাস্তবে কীভাবে branch organize করে (Gitflow, trunk-based, forking) সেই প্যাটার্নগুলো। এই Phase শেষ হলে যেকোনো টিমের Git workflow-তে confidently যোগ দেওয়া যাবে।

একটা repository যত পুরনো হয়, তার history তত বেশি মূল্যবান — কিন্তু শুধু তখনই, যখন সেই history থেকে তথ্য বের করার হাতিয়ার আপনার হাতে আছে। এই Phase পুরোপুরি ফরেনসিক — কে, কখন, কেন একটা লাইন বদলেছে; কোন commit-এ একটা bug ঢুকেছে; দুইটা commit-এর মধ্যে ঠিক কী পরিবর্তন হয়েছে — এই প্রশ্নগুলোর উত্তর কীভাবে সেকেন্ডে বের করা যায়।

Module 20-এ git log-এর পুরো ফ্ল্যাগ ফ্যামিলি (filtering, pickaxe search সহ), Module 21-এ show/diff/blame দিয়ে নির্দিষ্ট commit বা লাইনের গভীরে যাওয়া, আর Module 22-এ git bisect — একটা বাইনারি-সার্চ অ্যালগরিদম যা হাজার commit-এর মধ্যে থেকে ঠিক কোনটা bug ঢুকিয়েছে তা O(log n) সময়ে খুঁজে বের করে। এই তিনটা মডিউল একসাথে একটা senior engineer-কে জুনিয়র থেকে আলাদা করে দেয় — "কোথায় bug আছে" জানার চেয়ে "কীভাবে খুঁজে বের করব" জানাটাই আসল দক্ষতা।

এই Phase দুইটা প্র্যাকটিক্যাল কিন্তু ভিন্ন সমস্যা সমাধান করে। প্রথমটা — একটা নির্দিষ্ট commit-কে "এটাই v2.0.0 রিলিজ" বলে স্থায়ীভাবে চিহ্নিত করা রাখার দরকার হয় release management-এ; Module 23-এ tag-এর দুই প্রকার (lightweight ও annotated), তাদের ভেতরের পার্থক্য, আর SemVer কনভেনশন কভার হবে।

দ্বিতীয়টা — কাজের মাঝপথে হঠাৎ context বদলাতে হলে (একটা জরুরি hotfix চলে এলো, কিন্তু আপনার working directory অগোছালো অবস্থায় আছে) commit না করেই সাময়িকভাবে কাজ সরিয়ে রাখার দরকার হয়; Module 24-এ stash — Git-এর built-in "আপাতত সরিয়ে রাখো" টুল — বিস্তারিত আলোচনা হবে, যেটা internally আসলে একটা বিশেষ ধরনের commit stack।

Git একটা distributed VCS — কোনো একটা central server ছাড়াই এটা কাজ করতে পারে, কারণ প্রতিটা clone-ই একটা সম্পূর্ণ repository (পুরো history সহ)। কিন্তু বাস্তবে টিমওয়ার্কের জন্য একটা কনভেনশনাল "কেন্দ্র" (GitHub-এ একটা repo) দরকার হয়, যেখানে সবাই push/pull করে সিঙ্ক থাকে। এই মডিউলে remote — একটা অন্য repository-র রেফারেন্স — কীভাবে যোগ, মুছে, রিনেম করা হয়, আর ভেতরে ঠিক কী স্টোর হয় (.git/config + refs/remotes/) তা কভার হবে।

সংজ্ঞা

একটা remote হলো অন্য একটা Git repository-র একটা named reference — সাধারণত একটা URL (HTTPS বা SSH), যেখানে আপনার local repo ডেটা push (পাঠানো) বা fetch (আনা) করতে পারে। এটা মূলত একটা "address book entry" — Git নিজে remote repo-টাকে কোনো বিশেষ ক্ষমতা দেয় না, এটা শুধু আরেকটা সাধারণ Git repository যেখানে নেটওয়ার্কের মাধ্যমে পৌঁছানো যায়।

কেন দরকার

Git-এর distributed nature-এর মানে এই না যে remote লাগবে না — বরং remote হলো সেই মেকানিজম যা distributed repository-গুলোর মধ্যে synchronization সম্ভব করে। কেন্দ্রীয় SVN/CVS-এর মতো একটাই "true" copy নেই — প্রতিটা clone সমান, কিন্তু কনভেনশন হিসেবে একটা repo (GitHub-এ hosted) কে "সত্যের উৎস" (source of truth) ধরে নেওয়া হয়, আর সেটার সাথে যোগাযোগের জন্য remote লাগে।

বাস্তব সিনারিও

ধরুন আপনি (Rakib) একটা নতুন মেশিনে কাজ শুরু করছেন। git clone https://github.com/company/backend.git চালালে Git স্বয়ংক্রিয়ভাবে একটা remote তৈরি করে দেয়, নাম origin, URL সেই GitHub লিংক। এরপর থেকে git push origin main, git fetch origin — এই কমান্ডগুলো ওই URL-এর সাথে কথা বলে।

git clone https://github.com/company/backend.git
cd backend
git remote -v
# origin  https://github.com/company/backend.git (fetch)
# origin  https://github.com/company/backend.git (push)

একাধিক remote থাকা স্বাভাবিক

একটা repo-র একাধিক remote থাকতে পারে — যেমন origin (আপনার নিজের fork) আর upstream (মূল প্রজেক্ট)। এটা একটা single centralized server-এর ধারণার সম্পূর্ণ বিপরীত — Git-এ যত ইচ্ছা remote যোগ করা যায়, প্রতিটাই স্বাধীন একটা sync target।

কমান্ড রেফারেন্স

উদাহরণ

git remote add upstream https://github.com/original-org/backend.git
git remote -v
# origin    https://github.com/rakib/backend.git (fetch)
# origin    https://github.com/rakib/backend.git (push)
# upstream  https://github.com/original-org/backend.git (fetch)
# upstream  https://github.com/original-org/backend.git (push)

# SSH-এ শিফট করা (deploy key ব্যবহারের জন্য common)
git remote set-url origin git@github.com:rakib/backend.git

# বিস্তারিত তথ্য
git remote show origin
# * remote origin
#   Fetch URL: git@github.com:rakib/backend.git
#   HEAD branch: main
#   Remote branches:
#     main            tracked
#     feature/old-x   stale (use 'git remote prune' to remove)
#   Local branch configured for 'git pull':
#     main merges with remote main

git remote prune কেন দরকার

টিমমেট যখন GitHub-এ একটা feature branch মুছে ফেলে, আপনার local repo-র refs/remotes/origin/feature-x এন্ট্রিটা সাথে সাথে মুছে যায় না — এটা "stale" হয়ে থেকে যায়। git remote prune origin (বা git fetch --prune, পরের মডিউলে) এই মৃত রেফারেন্সগুলো পরিষ্কার করে, ফলে git branch -r বা IDE-তে ভুতুড়ে পুরনো branch দেখা যায় না।

remote আসলে দুইটা জিনিসের সমষ্টি

একটা remote internally মাত্র দুইটা জিনিস দিয়ে তৈরি:

1. .git/config-এ একটা URL এন্ট্রি — remote-এর নাম, তার URL, আর কোন branch-গুলো fetch করতে হবে তার refspec।
2. refs/remotes/<name>/*-এ track করা branch pointer — remote repo-র প্রতিটা branch-এর একটা local snapshot (remote-tracking branch), যেটা শুধুমাত্র fetch/pull/push চালানোর সময় আপডেট হয়।

.git/config-এ যা দেখবেন

cat .git/config

[remote "origin"]
    url = git@github.com:rakib/backend.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
    remote = origin
    merge = refs/heads/main

লক্ষ্য করুন fetch লাইনটা — এটা একটা refspec: +refs/heads/*:refs/remotes/origin/* মানে "remote-এর refs/heads/ (তার সব local branch) fetch করে local refs/remotes/origin/-এ রাখো"। শুরুর + মানে non-fast-forward update-ও জোর করে গ্রহণ করো (force update remote-tracking ref)।

remote-tracking branch immutable read-only snapshot

refs/remotes/origin/main কোনো সাধারণ branch না — এটা সরাসরি git checkout/commit করার জন্য না (করা গেলেও detached HEAD অবস্থায় চলে যাবেন)। এটা শুধু "শেষবার fetch করার সময় remote-এর main branch কোথায় ছিল" তার একটা লোকাল ক্যাশ। git fetch চালালেই এটা আপডেট হয়; ততক্ষণ এটা পুরনো তথ্য দেখাতে থাকবে, remote-এ নতুন commit এলেও।

রিয়েল-লাইফ ইমপ্লিকেশন

দুইজন ডেভেলপার একই সময়ে একই branch-এ কাজ করলে, একজনের local refs/remotes/origin/main আরেকজনেরটার চেয়ে পুরনো হতে পারে — এটাই bug না, এটাই distributed model-এর স্বাভাবিক আচরণ। git fetch চালানো মানেই শুধু "আমার local cache আপডেট করো", কাজের ফাইল (working directory) স্পর্শ করে না।

কেন "origin" এত কমন নাম

git clone চালালে Git স্বয়ংক্রিয়ভাবে সেই remote-কে origin নাম দেয় — এটা শুধুই একটা কনভেনশন, technical requirement না। আপনি চাইলে git remote rename origin main-repo করে অন্য নাম দিতে পারতেন, সব কাজ করবে। কিন্তু পুরো Git ইকোসিস্টেম (ডকুমেন্টেশন, টুলিং, টিমমেটদের প্রত্যাশা) origin-কে ধরে নেয় "যেখান থেকে clone করা হয়েছে" — তাই এই নাম না বদলানোই ভালো প্র্যাকটিস।

কেন "upstream" নাম আসে

Fork workflow-এ (ওপেন সোর্স কনট্রিবিউশনের সাধারণ প্যাটার্ন, বিস্তারিত Phase 11-এ) আপনি একটা প্রজেক্ট GitHub-এ fork করেন (আপনার নিজের কপি তৈরি হয়), সেটা clone করেন — তখন origin হয় আপনার fork। কিন্তু মূল প্রজেক্টের নতুন commit পেতে হলে মূল রিপোকেও remote হিসেবে যোগ করতে হয় — কনভেনশন অনুযায়ী তার নাম দেওয়া হয় upstream ("যেখান থেকে আসল স্রোত আসছে", নদীর উৎসের মতো)।

git clone git@github.com:rakib/backend.git    # origin = আমার fork
cd backend
git remote add upstream git@github.com:original-org/backend.git
git remote -v
# origin    git@github.com:rakib/backend.git (fetch/push)
# upstream  git@github.com:original-org/backend.git (fetch/push — সাধারণত push নেই)

দুই-remote মডেলের সুবিধা

• origin থেকে push/pull — নিজের fork-এ নিজের কাজ।
• upstream থেকে শুধু fetch — মূল প্রজেক্টে নতুন কী এলো তা জানা, নিজের branch rebase করা (git rebase upstream/main)।
• সাধারণত upstream-এ সরাসরি push করার অনুমতি থাকে না — Pull Request-ই একমাত্র পথ (ঠিক এটাই ওপেন সোর্স কনট্রিবিউশন মডেলের ভিত্তি, Phase 11-এ বিস্তারিত)।

এক লাইনে

origin = "আমি যেখানে push করি", upstream = "আমি যেখান থেকে নতুন পরিবর্তন টেনে আনি" — নামটা শুধু কনভেনশন, কিন্তু এই কনভেনশন এত সর্বজনীন যে অন্য নাম ব্যবহার করলে টিমমেটরা বিভ্রান্ত হবে।

লক্ষ্য

একটা repo-তে একাধিক remote যোগ করে, তাদের ম্যানেজ করে, আর stale branch prune করে হাতে-কলমে শেখা।

ধাপ ১ — দুইটা bare repo বানিয়ে সিমুলেট করা

mkdir -p ~/git-lab/origin.git ~/git-lab/upstream.git
git init --bare ~/git-lab/origin.git
git init --bare ~/git-lab/upstream.git

git clone ~/git-lab/upstream.git ~/git-lab/seed
cd ~/git-lab/seed
git commit --allow-empty -m "initial commit"
git push origin main
git push ~/git-lab/origin.git main

ধাপ ২ — লোকাল কপি ক্লোন করা এবং দুই remote যোগ করা

git clone ~/git-lab/origin.git ~/git-lab/work
cd ~/git-lab/work
git remote add upstream ~/git-lab/upstream.git
git remote -v

ধাপ ৩ — রিনেম ও URL বদলানো

git remote rename origin my-fork
git remote -v
# my-fork এখন origin-এর জায়গায়

git remote set-url my-fork ~/git-lab/origin.git   # URL অপরিবর্তিত রেখে টেস্ট করুন এটা এখনো কাজ করে কিনা

ধাপ ৪ — একটা branch তৈরি করে remote-এ push, তারপর remote থেকে মুছে prune টেস্ট

git checkout -b feature/temp
git commit --allow-empty -m "temp work"
git push my-fork feature/temp

# এখন সরাসরি bare repo থেকে branch মুছে ফেলুন (সিমুলেট করছি টিমমেট মুছেছে)
git -C ~/git-lab/origin.git branch -D feature/temp

git branch -r
# my-fork/feature/temp এখনো দেখাবে — stale!

git remote prune my-fork
git branch -r
# my-fork/feature/temp এখন আর নেই

যা লক্ষ্য করবেন

.git/config ফাইলটা প্রতিটা ধাপে খুলে দেখুন (cat .git/config) — git remote rename কীভাবে [remote "..."] সেকশনের নাম বদলায় এবং সংশ্লিষ্ট branch-এর remote = লাইনও আপডেট করে দেয়।

প্র.১ — git remote add origin <url> চালালে ঠিক কী ঘটে ভেতরে? উত্তর: .git/config-এ একটা নতুন [remote "origin"] সেকশন যোগ হয়, যাতে URL আর একটা default fetch refspec (+refs/heads/*:refs/remotes/origin/*) থাকে। কোনো ডেটা তখনই ট্রান্সফার হয় না — আসল fetch/push না চালানো পর্যন্ত refs/remotes/origin/* খালি বা তৈরি হয় না।

প্র.২ — origin আর upstream নামের মধ্যে টেকনিক্যাল পার্থক্য কী? উত্তর: কোনো টেকনিক্যাল পার্থক্য নেই — দুটোই সাধারণ remote নাম, Git-এর কাছে সমান। পার্থক্যটা পুরোপুরি কনভেনশন: origin সাধারণত যেখান থেকে clone করা হয়েছে (আপনার push target), upstream সাধারণত মূল প্রজেক্ট (আপনি শুধু fetch করেন, push না) — fork workflow-এ ব্যবহৃত।

প্র.৩ — git remote prune origin না চালালে কী সমস্যা হতে পারে? উত্তর: remote-এ মুছে ফেলা branch-গুলোর local refs/remotes/origin/<branch> এন্ট্রি stale থেকে যায় — git branch -r বা IDE branch list-এ মৃত branch দেখাতে থাকবে, যেটা বিভ্রান্তিকর এবং কখনো কখনো ভুল branch থেকে ভুলবশত কাজ শুরু করার কারণ হতে পারে।

প্র.৪ — git remote rename origin upstream চালালে refs/remotes/origin/* রেফারেন্সগুলোর কী হয়? উত্তর: সবগুলো refs/remotes/upstream/*-এ move হয়ে যায়, এবং .git/config-এ সংশ্লিষ্ট [branch "..."] সেকশনের remote = লাইনও নতুন নামে আপডেট হয়ে যায় — যাতে ট্র্যাকিং সম্পর্ক ভেঙে না যায়।

প্র.৫ — একটা repo-তে remote ছাড়াই কি কমিট, branch, merge করা যায়? উত্তর: হ্যাঁ, সম্পূর্ণভাবে। remote শুধু একাধিক repository-র মধ্যে sync করার জন্য দরকার — Git-এর core object model (commit, tree, blob, branch, merge) সম্পূর্ণ local-first, কোনো remote-এর ওপর নির্ভরশীল না। এটাই "distributed" VCS হওয়ার মূল অর্থ।

প্র.৬ — git remote show origin আর git remote -v-এর মধ্যে পার্থক্য কী? উত্তর: -v শুধু remote নাম আর URL (fetch/push) দ্রুত লিস্ট করে। show <name> নেটওয়ার্কে গিয়ে remote-এর সাথে যোগাযোগ করে বিস্তারিত তথ্য আনে — কোন branch tracked, কোনটা stale, local branch কোন remote branch-এর সাথে merge/push configured।

• git remote remove শুধু রেফারেন্স মুছে, actual remote repo-তে কোনো প্রভাব ফেলে না। নতুনরা মাঝে মাঝে ভয় পান যে এটা GitHub-এর repo মুছে দেবে — এটা শুধু আপনার local .git/config থেকে entry আর refs/remotes/<name>/* মুছে দেয়।
• URL-এ typo থাকলে git remote add কোনো error দেয় না — কারণ URL-এর ভ্যালিডিটি শুধু actual network operation (fetch/push) চালানোর সময় চেক হয়, add করার সময় না। ভুল URL দিয়ে remote যোগ করলে অনেক পরে fetch করার সময় error দেখা যাবে।
• একই URL দুইবার দুইটা ভিন্ন নামে remote হিসেবে যোগ করা টেকনিক্যালি বৈধ — Git কোনো বাধা দেয় না, কিন্তু এটা করলে দুইটা refs/remotes/ ট্রি একই ডেটার ডুপ্লিকেট রাখবে, disk space নষ্ট আর বিভ্রান্তির কারণ।
• git remote set-url push আর fetch URL আলাদা করে সেট করা যায় (--push ফ্ল্যাগ দিয়ে) — বিরল কিন্তু বাস্তব ব্যবহার: read-only mirror থেকে fetch করা, কিন্তু push করা অন্য একটা লেখার-অনুমতিসহ URL-এ। ডিফল্টভাবে এই দুটো URL একই থাকে।
• refs/remotes/origin/HEAD একটা বিশেষ সিমবলিক রেফারেন্স যা বলে দেয় remote-এর "default branch" কোনটা (যেমন main) — এটা git remote show origin-এর "HEAD branch" লাইনে দেখা যায়। remote-এ default branch বদলালে (GitHub সেটিংসে) local এই তথ্য নিজে থেকে আপডেট হয় না, git remote set-head origin -a দিয়ে সরাসরি রিফ্রেশ করতে হয়।

এটাই দৈনন্দিন Git ব্যবহারের কেন্দ্রবিন্দু — remote-এর সাথে ডেটা আদান-প্রদান। কিন্তু তিনটা কমান্ড-এর (fetch, pull, push) মধ্যে সম্পর্ক প্রায়ই ভুল বোঝা হয় — বিশেষ করে pull যে আসলে একটা composite কমান্ড (fetch + merge/rebase) সেটা অনেকে জানেন না। এই মডিউলে প্রতিটা কমান্ডের ফ্ল্যাগ ফ্যামিলি, non-fast-forward reject-এর কারণ, আর force push-এর তিন প্রকার — --force, --force-with-lease, --force-if-includes — এর মধ্যে নিরাপত্তার পার্থক্য কভার হবে।

তিনটা কমান্ডের ভূমিকা

কেন এই পার্থক্য গুরুত্বপূর্ণ

git fetch সম্পূর্ণ নিরাপদ — এটা শুধু তথ্য আনে, আপনার বর্তমান কাজে কোনো হাত দেয় না। git pull তুলনামূলক ঝুঁকিপূর্ণ কারণ এটা স্বয়ংক্রিয়ভাবে merge/rebase চালিয়ে দেয় — যদি আপনার local branch-এ uncommitted পরিবর্তন থাকে বা conflict তৈরি হওয়ার সম্ভাবনা থাকে, pull মাঝপথে থেমে যেতে পারে একটা অগোছালো অবস্থায়।

রিয়েল-লাইফ সিনারিও

আপনি যদি প্রতিদিন সকালে কাজ শুরুর আগে টিমমেটদের নতুন commit দেখতে চান কিন্তু নিজের local branch-এ এখনই merge করতে না চান, git fetch চালিয়ে শুধু git log main..origin/main দিয়ে দেখে নিতে পারেন কী নতুন এসেছে — আসলে merge না করেই। এটাই অভিজ্ঞ ডেভেলপারদের pull-এর বদলে fetch + ম্যানুয়াল merge/rebase পছন্দ করার একটা বড় কারণ — নিয়ন্ত্রণ নিজের হাতে থাকে।

git fetch origin
git log --oneline main..origin/main   # remote-এ নতুন কী কমিট এসেছে দেখুন
git merge origin/main                  # সন্তুষ্ট হলে তবেই merge করুন

মূল ফ্ল্যাগ

কেন -p/--prune গুরুত্বপূর্ণ

মুছে যাওয়া remote branch লোকালেও ক্লিন করা দরকার কারণ না হলে refs/remotes/origin/* ধীরে ধীরে ভুতুড়ে entry-তে ভরে যায় — git branch -r বা git checkout <tab-complete> করার সময় এমন branch দেখাবে যা GitHub-এ আর নেই, বিভ্রান্তির সৃষ্টি করে।

git fetch origin --prune
# From github.com:company/backend
#  - [deleted]         (none)     -> origin/feature/old-experiment

অনেক টিম git config --global fetch.prune true সেট করে রাখেন যাতে প্রতিটা fetch/pull-এ স্বয়ংক্রিয়ভাবে prune হয়।

shallow fetch-এর বাস্তব ব্যবহার

CI/CD পাইপলাইনে পুরো history দরকার নেই, শুধু সাম্প্রতিক commit — git fetch --depth=1 দিয়ে GB-সাইজের history স্কিপ করে সেকেন্ডে clone সম্পন্ন হয়। কিন্তু shallow repo-তে git log, git blame পুরো history দেখাতে পারে না যতক্ষণ না git fetch --unshallow চালানো হয়।

git clone --depth=1 https://github.com/company/backend.git
# একটামাত্র commit — বাকি history নেই
git log --oneline
# a1b2c3d (HEAD -> main, origin/main) latest commit only

pull একটা কম্পোজিট কমান্ড

git pull আসলে দুইটা ধাপের shortcut:

git pull origin main
# ভেতরে ভেতরে ঠিক এই দুইটা কমান্ড চলে:
git fetch origin main
git merge origin/main

git pull --rebase দিলে দ্বিতীয় ধাপ merge-এর বদলে rebase হয়:

git pull --rebase origin main
# সমতুল্য:
git fetch origin main
git rebase origin/main

কেন এই ব্যাখ্যা গুরুত্বপূর্ণ

pull-কে একটা "ম্যাজিক আপডেট বাটন" হিসেবে দেখলে বিভ্রান্তি হয় — merge conflict এলে, git status "you have unmerged paths" দেখালে, বোঝা যায় না কী হচ্ছে। কিন্তু pull-কে fetch+merge হিসেবে বুঝলে, conflict resolution ঠিক আগের merge মডিউলের মতোই স্বাভাবিক মনে হয় — কারণ এটা সেই একই merge অপারেশন, শুধু fetch-এর সাথে স্বয়ংক্রিয়ভাবে চেইন করা।

--ff-only — নিরাপদ pull

git pull --ff-only

এই ফ্ল্যাগ merge commit তৈরি হতে দেয় না — শুধু তখনই pull সফল হবে যখন local branch-এ কোনো নতুন commit নেই (fast-forward সম্ভব)। যদি local branch-এ কোনো commit থাকে যা remote-এ নেই, --ff-only pull প্রত্যাখ্যান করবে এবং একটা স্পষ্ট error দেবে — অনিচ্ছাকৃত merge commit তৈরি হওয়া থেকে রক্ষা করে। অনেক টিম pull.ff = only কনফিগ ডিফল্ট করে রাখে যাতে ভুলে অগোছালো merge history তৈরি না হয়।

git config --global pull.ff only

বেসিক ও ট্র্যাকিং সেটআপ

git push origin feature/new-api

প্রথমবার একটা নতুন local branch push করলে, -u (বা --set-upstream) দিলে ভবিষ্যতে শুধু git push/git pull লিখলেই চলবে, কোন remote/branch বলতে হবে না:

git push -u origin feature/new-api
# পরবর্তী push শুধু: git push

.git/config-এ এটা [branch "feature/new-api"] সেকশনে remote = আর merge = এন্ট্রি হিসেবে সেভ হয় — ঠিক Module 17-এ দেখা .git/config স্ট্রাকচারের মতোই।

অন্যান্য গুরুত্বপূর্ণ ফ্ল্যাগ

--dry-run কেন উপকারী

বড়, জটিল push-এর আগে (বিশেষ করে rebase-এর পর) --dry-run দিয়ে নিশ্চিত হওয়া যায় ঠিক কোন commit push হতে যাচ্ছে, ভুলবশত অতিরিক্ত branch বা tag push হয়ে যাচ্ছে কিনা:

git push --dry-run origin main
# To github.com:company/backend.git
#    a1b2c3d..e4f5g6h  main -> main

remote branch মোছা

git push origin --delete feature/old-experiment
# বিকল্প সিনট্যাক্স (কম common কিন্তু কাজ করে):
git push origin :feature/old-experiment

দ্বিতীয় ফর্মটা refspec সিনট্যাক্স <src>:<dst>-এর একটা বিশেষ কেস — খালি <src> মানে "কিছু push কোরো না", যা কার্যকরভাবে destination branch মুছে ফেলে।

কেন force push দরকার হয়

rebase বা commit --amend-এর পর history rewrite হয়ে যায় — commit hash বদলে যায়। এই অবস্থায় সাধারণ git push reject হবে (non-fast-forward) কারণ remote branch-এর history আর আপনার local history "সরলরৈখিকভাবে এগোয়নি" — remote যা জানে তার চেয়ে ভিন্ন commit আপনার কাছে আছে। force push দিয়ে remote branch-কে জোর করে আপনার local history-তে rewrite করতে বলা হয়।

তিনটা ফ্ল্যাগের পার্থক্য

কেন --force-with-lease নিরাপদ

ধরুন আপনি সকাল ১০টায় origin/feature-x fetch করলেন, rebase করলেন, এবং দুপুর ২টায় push করতে চাইলেন। এর মাঝে যদি একজন টিমমেট দুপুর ১২টায় সেই branch-এ নতুন commit push করে থাকে, --force সেই commit নিঃশব্দে মুছে দেবে — ডেটা লস, কেউ টেরও পাবে না। কিন্তু --force-with-lease push করার আগে চেক করবে remote-এর বর্তমান অবস্থা আপনার শেষ fetch-এর সাথে মেলে কিনা — না মিললে push reject হবে একটা স্পষ্ট error সহ, যাতে আপনি আগে fetch করে দেখে নিতে পারেন কী বদলেছে।

git push --force-with-lease origin feature-x
# ! [rejected] feature-x -> feature-x (stale info)
# হিন্ট: fetch করে দেখুন কী পরিবর্তন হয়েছে

সাধারণ নিয়ম

শেয়ার্ড branch (main, develop)-এ কখনো force push করবেন না। নিজের feature branch-এ rebase-এর পর force push দরকার হলে সবসময় --force-with-lease ব্যবহার করুন, খালি --force না।

error message যা সবাই দেখেছে

git push origin main
# ! [rejected]        main -> main (fetch first)
# error: failed to push some refs to 'github.com:company/backend.git'
# hint: Updates were rejected because the remote contains work that you do
# hint: not have locally.

ভেতরে ঠিক কী চেক হচ্ছে

প্রতিটা branch push আসলে একটা compare-and-swap অপারেশন — remote server চেক করে: "client যে commit-কে branch-এর current tip মনে করছে (তার local refs/remotes/origin/main), সেটা কি আসলেই remote branch-এর বর্তমান tip-এর সাথে মেলে?" যদি না মেলে (কারণ মাঝে অন্য কেউ push করেছে), remote push reject করে দেয় — এটাই non-fast-forward reject।

কেন এটা প্রয়োজনীয়, বিরক্তিকর না

এই মেকানিজম ছাড়া দুইজন ডেভেলপার একই সময়ে push করলে, দ্বিতীয়জনের push প্রথমজনের commit নিঃশব্দে মুছে দিতে পারত — কারণ push মানে "remote branch pointer-কে এই নতুন commit-এ নিয়ে যাও"। non-fast-forward চেক এই সাইলেন্ট ডেটা-লস প্রতিরোধ করে, force করে যে আপনাকে আগে remote-এর নতুন commit নিজের history-তে integrate করতে হবে (merge বা rebase দিয়ে), তারপরই push করতে দেওয়া হবে।

সমাধানের স্বাভাবিক ধাপ

git fetch origin
git rebase origin/main    # অথবা: git merge origin/main
git push origin main

এই মেকানিজম আর force push-এর সম্পর্ক

force push (--force/--force-with-lease) হলো এই compare-and-swap চেক ইচ্ছাকৃতভাবে বাইপাস করার উপায় — "আমি জানি remote-এ ভিন্ন কিছু আছে, তবুও আমার local history দিয়ে সেটা প্রতিস্থাপন করো"। এই জন্যই force push এত ঝুঁকিপূর্ণ — এটা ঠিক সেই সুরক্ষা যন্ত্রটাকেই নিষ্ক্রিয় করে দেয় যেটা সাধারণ push অপারেশন ডেটা-লস থেকে বাঁচানোর জন্য রাখা হয়েছিল।

লক্ষ্য

দুইটা লোকাল ক্লোন একই bare repo-র সাথে সিঙ্ক করে non-fast-forward reject, fetch+rebase, আর force-with-lease হাতে-কলমে দেখা।

সেটআপ

mkdir -p ~/git-lab2 && cd ~/git-lab2
git init --bare team.git

git clone team.git dev-a
git clone team.git dev-b

cd dev-a
git commit --allow-empty -m "initial commit"
git push origin main
cd ../dev-b
git pull origin main

ধাপ ১ — dev-a থেকে push, dev-b না জেনেই push করার চেষ্টা

cd ../dev-a
echo "feature A" > a.txt && git add a.txt
git commit -m "add feature A"
git push origin main   # সফল

cd ../dev-b
echo "feature B" > b.txt && git add b.txt
git commit -m "add feature B"
git push origin main
# ! [rejected]  main -> main (fetch first)

ধাপ ২ — সঠিক সমাধান: fetch + rebase

git fetch origin
git rebase origin/main
git push origin main   # এখন সফল, linear history বজায় থাকলো

ধাপ ৩ — force-with-lease টেস্ট

cd ../dev-a
git commit --allow-empty --amend -m "amended commit"
git push --force-with-lease origin main   # সফল, কারণ dev-a-র জানা remote state ঠিক আছে

cd ../dev-b
git commit --allow-empty --amend -m "different amend"
git push --force-with-lease origin main
# ! [rejected] (stale info) — কারণ dev-b এখনো পুরনো remote state জানে
git fetch origin
git push --force-with-lease origin main   # fetch-এর পর সফল

যা লক্ষ্য করবেন

--force (lease ছাড়া) দিয়ে ধাপ ৩ পুনরাবৃত্তি করলে dev-a-র commit নিঃশব্দে মুছে যাবে dev-b-র push-এ — কোনো warning ছাড়াই। এই পার্থক্যটাই --force-with-lease ব্যবহারের আসল যুক্তি।

প্র.১ — git pull আর git fetch-এর মূল পার্থক্য কী? উত্তর: git fetch শুধু remote-এর নতুন ডেটা local refs/remotes/-এ আনে, working directory স্পর্শ করে না। git pull হলো fetch + স্বয়ংক্রিয় merge (বা --rebase দিলে rebase) — এটা working directory-ও আপডেট করে দেয়। pull আসলে একটা composite/shortcut কমান্ড।

প্র.২ — git fetch --prune কেন দরকার? উত্তর: remote-এ কোনো branch মুছে ফেলা হলে local refs/remotes/origin/<branch> এন্ট্রি স্বয়ংক্রিয়ভাবে মোছে না — stale থেকে যায়। --prune এই মৃত রেফারেন্স পরিষ্কার করে, git branch -r তালিকা সঠিক রাখে।

প্র.৩ — --force আর --force-with-lease-এর মধ্যে পার্থক্য কী, আর কেন --force-with-lease নিরাপদ? উত্তর: --force কোনো চেক ছাড়াই remote branch overwrite করে — মাঝে কেউ push করলে তার commit নিঃশব্দে মুছে যেতে পারে। --force-with-lease push করার আগে যাচাই করে remote branch এখনো ঠিক সেখানেই আছে যেখানে শেষবার fetch করার সময় ছিল — মাঝে অন্য কেউ push করলে reject হয়ে যায়, ডেটা লস প্রতিরোধ হয়।

প্র.৪ — non-fast-forward push reject কেন হয়, ভেতরে ঠিক কী চেক হয়? উত্তর: push একটা compare-and-swap অপারেশন — remote চেক করে client-এর জানা branch tip আসলেই remote-এর বর্তমান tip-এর সাথে মেলে কিনা। না মিললে (মাঝে অন্য কেউ push করেছে) reject হয়, যাতে সাইলেন্ট ডেটা-লস না ঘটে।

প্র.৫ — git pull --ff-only ব্যবহার করলে কী সুবিধা হয়? উত্তর: এটা শুধু fast-forward pull সফল হতে দেয় — local-এ কোনো divergent commit থাকলে pull ব্যর্থ হয়ে স্পষ্ট error দেয়, অনিচ্ছাকৃত merge commit তৈরি হওয়া থেকে বাঁচায়। অনেক টিম এটা pull.ff = only কনফিগ করে ডিফল্ট করে রাখে।

প্র.৬ — git fetch --depth=1 (shallow clone/fetch)-এর সীমাবদ্ধতা কী? উত্তর: শুধু সাম্প্রতিক কমিটটুকু আনে, পুরো history আসে না — তাই git log, git blame, বা পুরনো commit-এ checkout করার মতো অপারেশন সীমিত থাকে যতক্ষণ না git fetch --unshallow দিয়ে বাকি history আনা হয়। CI/CD-তে দ্রুত clone-এর জন্য উপকারী কিন্তু forensic কাজের জন্য অনুপযুক্ত।

• git pull conflict-এ থেমে গেলে merge আর rebase-এর resolution আলাদা। pull-এর ভেতরে merge চলছে না rebase চলছে সেটা প্রথমে git status দিয়ে নিশ্চিত হওয়া দরকার — দুটোর abort কমান্ড আলাদা (git merge --abort বনাম git rebase --abort), ভুল কমান্ড দিলে error আসবে বা অবস্থা আরও জটিল হবে।
• git push করার সময় কোনো branch উল্লেখ না করলে, push.default কনফিগের ওপর নির্ভর করে আচরণ বদলায় — আধুনিক Git-এ ডিফল্ট simple (শুধু বর্তমান branch, শুধু যদি upstream সেট করা থাকে), কিন্তু পুরনো কনফিগে matching (সব same-name branch push) সেট থাকলে অপ্রত্যাশিতভাবে একাধিক branch push হয়ে যেতে পারে।
• --force-with-lease কোনো argument ছাড়া ব্যবহার করলে এটা সব branch-এর জন্য "যা শেষবার fetch করেছি" ধরে নেয় — কিন্তু যদি অন্য কোনো টুল/CI ব্যাকগ্রাউন্ডে fetch চালিয়ে রাখে (auto-fetch), lease-এর তথ্য আপনার অজান্তেই "stale" হতে পারে, push অপ্রত্যাশিতভাবে সফল বা ব্যর্থ হতে পারে।
• shallow clone-এ push করলে সমস্যা হতে পারে — কারণ shallow repo-তে পূর্ণ history নেই, ফলে rebase বা history-নির্ভর অপারেশন অস্বাভাবিক আচরণ করতে পারে। shallow clone সাধারণত শুধু read-only CI ব্যবহারের জন্য, active development-এর জন্য না।
• git push origin :branch-name (কোলনের আগে খালি) দিয়ে remote branch মোছা টাইপো-প্রবণ — একটা বাড়তি স্পেস বা ভুল কোলন বসালে অপ্রত্যাশিত refspec তৈরি হতে পারে। git push origin --delete branch-name স্পষ্ট এবং নিরাপদ, তাই এটাই প্রেফার করা উচিত।

Git নিজে কোনো "সঠিক" branching workflow বাধ্যতামূলক করে না — এটা শুধু primitive (branch, merge, rebase, tag) দেয়, বাকিটা কনভেনশন। এই মডিউলে বাস্তবে ব্যবহৃত চারটা প্রধান workflow প্যাটার্ন — feature-branch, Gitflow, trunk-based development, আর forking workflow — এবং কোন টিমের জন্য কোনটা মানানসই তা কভার হবে। এটা কোনো একক "সঠিক উত্তর" মডিউল না — বরং trade-off বোঝার মডিউল।

সমস্যাটা কী

Git প্রযুক্তিগতভাবে যেকোনো ধরনের branch/merge প্যাটার্ন সাপোর্ট করে — কোনো নিয়ম নেই যে কবে branch তৈরি করতে হবে, কবে merge করতে হবে, কে review করবে। এই স্বাধীনতা একদিকে শক্তি, অন্যদিকে বিশৃঙ্খলার উৎস — যদি একটা টিমের সবাই ভিন্ন ভিন্ন কনভেনশন অনুসরণ করে, history অগোছালো, অনুমানযোগ্য না হয়ে যায়।

Workflow প্যাটার্ন আসলে কী

একটা workflow প্যাটার্ন হলো টিমের সম্মত নিয়মের সেট: কোন branch-এর নাম কী কনভেনশন মানবে, কখন merge করতে হবে, কোন branch থেকে release হবে, কীভাবে hotfix হ্যান্ডল হবে। এটা কোনো Git ফিচার না — এটা টিমের প্রসেস, যেটা Git-এর primitive দিয়ে বাস্তবায়িত হয়।

রিয়েল-লাইফ ইমপ্লিকেশন

একটা ৩ জনের স্টার্টআপ টিম আর একটা ৫০ জনের এন্টারপ্রাইজ টিমের প্রয়োজন সম্পূর্ণ ভিন্ন। ছোট টিমে ভারী প্রসেস (Gitflow-এর মতো একাধিক দীর্ঘস্থায়ী branch) শুধু overhead তৈরি করে; বড় টিমে হালকা প্রসেস (সরাসরি main-এ কমিট) বিশৃঙ্খলা ও প্রোডাকশন রিস্ক তৈরি করে। এই মডিউলের বাকি অংশে চারটা প্যাটার্ন দেখে বোঝা যাবে কোনটা কখন উপযুক্ত।

সাধারণ থিম

প্রায় সব আধুনিক workflow-এর মূল নীতি এক: কখনো সরাসরি main-এ কাজ করবেন না, সবসময় একটা আলাদা branch-এ কাজ করে review-এর পর merge করুন। পার্থক্য হলো তার চারপাশের কাঠামোর জটিলতায়।

কীভাবে কাজ করে

সবচেয়ে সাধারণ ও সরল প্যাটার্ন। প্রতিটা নতুন ফিচার/বাগফিক্সের জন্য main থেকে একটা নতুন branch তৈরি করা হয়, সেখানে কাজ শেষ হলে Pull Request/Merge Request-এর মাধ্যমে review করে main-এ merge করা হয়, তারপর branch মুছে ফেলা হয়।

git checkout main
git pull origin main
git checkout -b feature/user-notifications
# ... কাজ, একাধিক কমিট ...
git push -u origin feature/user-notifications
# GitHub-এ Pull Request খোলা → review → approve → merge
git checkout main
git pull origin main
git branch -d feature/user-notifications

কেন এত জনপ্রিয়

• সরল — একটাই দীর্ঘস্থায়ী branch (main), বাকি সব ক্ষণস্থায়ী।
• CI/CD-বান্ধব — main-এ merge মানেই deploy-যোগ্য অবস্থা (যদি টিম main-কে সবসময় deployable রাখার শৃঙ্খলা মানে)।
• Review গেট — প্রতিটা পরিবর্তন PR-এর মাধ্যমে যায়, code review বাধ্যতামূলক করা সহজ।

রিয়েল-লাইফ উদাহরণ

আপনার (Rakib) backend প্রজেক্টে একটা নতুন notification-retry-logic ফিচারের জন্য feature/notification-retry branch তৈরি করে কাজ করবেন, PR-এ টিমমেট review করবে, merge হবে, GitHub Actions CI/CD পাইপলাইন (এই ব্লগেরই deploy workflow-এর মতো) স্বয়ংক্রিয়ভাবে deploy করবে।

সীমাবদ্ধতা

খুব বড় টিমে (৫০+ ডেভেলপার) একা feature-branch যথেষ্ট না — release timing, hotfix urgency, আর একাধিক ভার্সন সমান্তরাল maintain করার জন্য অতিরিক্ত কাঠামো (Gitflow) দরকার হতে পারে।

কাঠামো

Gitflow একটা কঠোরভাবে সংজ্ঞায়িত মডেল, একাধিক দীর্ঘস্থায়ী branch নিয়ে:

git checkout develop
git checkout -b feature/payment-retry
# ... কাজ ...
git checkout develop && git merge --no-ff feature/payment-retry

git checkout develop
git checkout -b release/2.1.0
# ... bugfix only ...
git checkout main && git merge --no-ff release/2.1.0 && git tag v2.1.0
git checkout develop && git merge --no-ff release/2.1.0

কবে ব্যবহার করা উচিত

যেসব প্রজেক্টে একাধিক ভার্সন সমান্তরাল maintain করতে হয় (যেমন desktop software, একাধিক client-এর জন্য আলাদা release cycle), অথবা release process-এ scheduled QA/staging ধাপ আছে — সেখানে Gitflow-এর কাঠামো উপকারী, কারণ release/* branch একটা স্পষ্ট "freeze" পয়েন্ট দেয়।

কবে ওভারকিল

Continuous deployment করা ওয়েব সার্ভিসে (যেখানে প্রতিদিন বহুবার production-এ deploy হয়) Gitflow-এর multi-branch overhead অপ্রয়োজনীয় জটিলতা যোগ করে — develop আর main-এর মধ্যে sync রাখা, দুই জায়গায় merge করা, এসব শুধু ধীর গতি তৈরি করে। এই কারণেই আধুনিক SaaS টিমগুলো প্রায়ই trunk-based development বেছে নেয় (পরের লিফ)।

কাঠামো

Trunk-based development-এ একটাই দীর্ঘস্থায়ী branch — main (trunk)। ডেভেলপাররা খুব ছোট, স্বল্পস্থায়ী branch (কয়েক ঘণ্টা থেকে ১-২ দিন) তৈরি করে দ্রুত main-এ merge করে দেন — কোনো দীর্ঘস্থায়ী develop বা release branch নেই।

অসম্পূর্ণ ফিচার কীভাবে সামলানো হয়

সমস্যা: যদি সবাই ঘন ঘন main-এ merge করে, অসম্পূর্ণ ফিচার production-এ চলে যাওয়ার ঝুঁকি থাকে। সমাধান: feature flags (feature toggles) — কোড merge হয়ে যায় main-এ, কিন্তু runtime-এ একটা কনফিগ ফ্ল্যাগ দিয়ে নিয়ন্ত্রণ করা হয় ফিচারটা ব্যবহারকারীদের কাছে visible কিনা।

if feature_flags.is_enabled("new_notification_engine", user):
    send_via_new_engine(user, message)
else:
    send_via_legacy_engine(user, message)

এভাবে অসম্পূর্ণ বা টেস্ট-চলমান কোড production-এ deploy হয়ে গেলেও ব্যবহারকারীরা এটা দেখেন না, যতক্ষণ না flag চালু করা হয় (ধীরে ধীরে rollout, A/B test, বা instant rollback-এর জন্যও flag off করাই যথেষ্ট, নতুন deploy লাগে না)।

কেন মডার্ন high-velocity টিমগুলো এটা পছন্দ করে

• Merge conflict কম — branch যত কম দিন বাঁচে, তত কম সম্ভাবনা যে অন্যদের কাজের সাথে সাংঘর্ষিক হবে।
• Continuous Integration-এর প্রকৃত অর্থ বাস্তবায়ন — "integrate ঘন ঘন করো" নীতির আক্ষরিক প্রয়োগ, যেটা Gitflow-এর দীর্ঘস্থায়ী feature/release branch-এর সাথে সাংঘর্ষিক।
• Rollback দ্রুত — কোনো bug এলে নতুন deploy না করে শুধু flag off করলেই সমস্যা মিটে যায়।
• Google, Facebook, Netflix-এর মতো কোম্পানির internal practice — হাজার হাজার ইঞ্জিনিয়ার একই main-এ দিনে বহুবার merge করেন, feature flag দিয়ে risk আলাদা করে রাখা হয়।

ট্রেড-অফ

feature flag ব্যবস্থাপনা নিজেই একটা অতিরিক্ত জটিলতা যোগ করে — পুরনো flag পরিষ্কার না করলে কোডবেস flag-এর জঞ্জালে ভরে যায় ("flag debt")। ছোট টিমে এই ইনফ্রাস্ট্রাকচার (flag management system) বানানোর খরচ যৌক্তিকতা হারাতে পারে যদি deploy frequency কম হয়।

Forking Workflow — সংক্ষেপে

ওপেন সোর্স প্রজেক্টে সাধারণত কন্ট্রিবিউটরদের সরাসরি মূল repo-তে push করার অনুমতি থাকে না (নিরাপত্তা ও কোয়ালিটি কন্ট্রোলের জন্য)। তার বদলে প্রতিটা কন্ট্রিবিউটর প্রজেক্টের নিজস্ব fork (কপি) বানায়, সেখানে কাজ করে, তারপর মূল প্রজেক্টে একটা Pull Request পাঠায়। মূল প্রজেক্টের maintainer রিভিউ করে merge করেন। এটাই Module 17-এ দেখা origin/upstream দুই-remote মডেলের ভিত্তি — বিস্তারিত মেকানিক্স ও PR ইটিকেট Phase 11-এ কভার হবে।

# সংক্ষিপ্ত ছবি — বিস্তারিত Phase 11-এ
git clone git@github.com:rakib/open-source-project.git   # নিজের fork
git remote add upstream git@github.com:original-org/open-source-project.git
git checkout -b fix/typo-in-docs
# ... কাজ ...
git push origin fix/typo-in-docs
# GitHub-এ "Compare & Pull Request" → upstream-এর দিকে PR

চারটা প্যাটার্নের তুলনা টেবিল

সিদ্ধান্ত নেওয়ার প্রশ্ন

1. টিমের সবার কি একই central repo-তে push করার অনুমতি আছে? না হলে → forking।
2. একাধিক ভার্সন সমান্তরাল maintain করতে হয়? হ্যাঁ হলে → Gitflow বিবেচনা করুন।
3. দিনে একাধিকবার deploy হয়, দ্রুত iteration দরকার? → trunk-based + feature flags।
4. উপরের কোনোটাই না, সাধারণ টিম প্রজেক্ট? → feature-branch workflow, ডিফল্ট নিরাপদ পছন্দ।

লক্ষ্য

একটা ছোট repo-তে সম্পূর্ণ feature-branch workflow — branch তৈরি থেকে merge ও cleanup পর্যন্ত — হাতে-কলমে চালানো।

সেটআপ

mkdir -p ~/git-lab3 && cd ~/git-lab3
git init --bare team-repo.git
git clone team-repo.git local-repo
cd local-repo
git commit --allow-empty -m "initial commit"
git push origin main

ধাপ ১ — ফিচার branch তৈরি

git checkout -b feature/add-readme
echo "# My Project" > README.md
git add README.md
git commit -m "docs: add README"
git push -u origin feature/add-readme

ধাপ ২ — সিমুলেট করুন main-এ অন্য একটা পরিবর্তন এসেছে (টিমমেটের কাজ)

git checkout main
echo "config" > config.txt
git add config.txt
git commit -m "chore: add config"
git push origin main

ধাপ ৩ — feature branch-কে আপডেটেড main-এর সাথে sync করা (rebase দিয়ে)

git checkout feature/add-readme
git fetch origin
git rebase origin/main
git push --force-with-lease origin feature/add-readme

ধাপ ৪ — merge ও cleanup (PR merge-এর সিমুলেশন)

git checkout main
git merge --no-ff feature/add-readme -m "Merge feature/add-readme"
git push origin main

git branch -d feature/add-readme
git push origin --delete feature/add-readme
git fetch --prune

যা লক্ষ্য করবেন

git log --graph --oneline --all চালিয়ে দেখুন — --no-ff merge কীভাবে একটা স্পষ্ট merge commit রেখে দেয় যেখান থেকে বোঝা যায় ঠিক কোন commit-গুলো একসাথে একটা ফিচার হিসেবে merge হয়েছিল, এমনকি rebase-এর ফলে history linear হওয়ার পরও।

প্র.১ — Gitflow আর trunk-based development-এর মূল দার্শনিক পার্থক্য কী? উত্তর: Gitflow দীর্ঘস্থায়ী branch (develop, release, feature) দিয়ে কাজ আলাদা রাখে এবং একটা নির্দিষ্ট release process অনুসরণ করে। Trunk-based development শুধু একটা main branch রেখে খুব ঘন ঘন, ছোট merge করে — অসম্পূর্ণ কাজ feature flag দিয়ে লুকিয়ে রাখে। একটা branch-centric, অন্যটা integration-frequency-centric।

প্র.২ — একটা ওয়েব SaaS প্রজেক্ট, দিনে ১০ বার deploy হয় — কোন workflow বেছে নেবেন এবং কেন? উত্তর: Trunk-based development + feature flags। ঘন ঘন deploy-এর সাথে Gitflow-এর দীর্ঘস্থায়ী branch এবং একাধিক-জায়গায়-merge মডেল মানানসই না — এটা গতি কমায়। ছোট, ঘন ঘন merge আর feature flag দিয়ে risk আলাদা রাখাই এই স্কেলে উপযোগী।

প্র.৩ — feature flag ব্যবহারের সবচেয়ে বড় ঝুঁকি কী? উত্তর: "Flag debt" — সময়ের সাথে সাথে পুরনো, আর প্রয়োজন নেই এমন flag কোডবেসে জমে থাকে, কোড জটিল ও পড়া কঠিন হয়ে যায়। নিয়মিত পুরনো flag পরিষ্কার করার শৃঙ্খলা না থাকলে এটা টেকনিক্যাল ঋণে পরিণত হয়।

প্র.৪ — forking workflow কেন feature-branch workflow-এর বদলে ব্যবহার করা হয় ওপেন সোর্সে? উত্তর: ওপেন সোর্স প্রজেক্টে হাজারো অপরিচিত কন্ট্রিবিউটর থাকতে পারে — সবাইকে মূল repo-তে সরাসরি push access দেওয়া নিরাপত্তা ও কোয়ালিটি ঝুঁকি। Forking প্রতিটা কন্ট্রিবিউটরকে নিজের আলাদা কপিতে কাজ করতে দেয়, শুধু maintainer-রাই মূল repo-তে merge করার ক্ষমতা রাখেন (PR review-এর মাধ্যমে)।

প্র.৫ — Gitflow-এ hotfix/* branch কেন main থেকে branch হয়, develop থেকে না? উত্তর: hotfix জরুরি প্রোডাকশন বাগ ফিক্স করার জন্য — develop-এ হয়তো আধা-সম্পূর্ণ নতুন ফিচার আছে যা এখনো production-ready না। main থেকে branch করলে fix শুধু production-এ যা আছে তার ওপর ভিত্তি করে হয়, অপ্রাসঙ্গিক in-progress কাজ জড়ায় না। শেষে fix দুই জায়গাতেই (main ও develop) merge হয় যাতে develop-ও ফিক্সটা পায়।

প্র.৬ — একটা টিম বলছে "আমরা কখনো main-এ সরাসরি push করি না, সবসময় PR ব্যবহার করি" — এটা কোন নির্দিষ্ট workflow-এর অংশ, নাকি সাধারণ নীতি? উত্তর: এটা প্রায় সব আধুনিক workflow-এর (feature-branch, Gitflow, trunk-based, forking) একটা সাধারণ ভিত্তি নীতি — কোড review গেট নিশ্চিত করা। নির্দিষ্ট workflow-গুলো এই নীতির ওপর ভিন্ন ভিন্ন branch-কাঠামো যোগ করে, কিন্তু "সরাসরি push না করা" নীতিটা সবগুলোতেই সাধারণত মেনে চলা হয়।

• Gitflow-এ release/* branch থেকে bugfix করলে সেটা develop-এ manually merge না করলে হারিয়ে যায় — অনেক টিম শুধু main-এ merge করে ভুলে যায় develop-এও merge করতে, ফলে পরবর্তী রিলিজে সেই bugfix আবার ফিরে আসে (regression)।
• Trunk-based development-এ যদি feature flag ইনফ্রাস্ট্রাকচার না থাকে, টিম আসলে "gitflow ছাড়া bare trunk" চালাচ্ছে — যেটা বিপজ্জনক, কারণ অসম্পূর্ণ কাজ সরাসরি production কোডে চলে যায় কোনো toggle ছাড়াই। Trunk-based শুধুমাত্র feature flag-সহ কার্যকর, খালি "সবাই main-এ কমিট করো" যথেষ্ট না।
• ওপেন সোর্স ছাড়া প্রাইভেট কোম্পানি প্রজেক্টেও অনেকে অকারণে fork ব্যবহার করে ফেলেন — যদি সবার push access আছে (কোম্পানির নিজস্ব টিম), সাধারণ feature-branch workflow-ই যথেষ্ট, forking-এর অতিরিক্ত সিঙ্ক জটিলতা অপ্রয়োজনীয়।
• Workflow বদলানো (যেমন Gitflow থেকে trunk-based-এ মাইগ্রেশন) মাঝপথে বিশৃঙ্খলা তৈরি করতে পারে — যদি অর্ধেক টিম পুরনো কনভেনশন মেনে চলে, অর্ধেক নতুন, branch নামকরণ ও merge policy সাংঘর্ষিক হয়ে পড়ে। মাইগ্রেশনের সময় একটা স্পষ্ট কাট-অফ তারিখ ও টিম-ওয়াইড ঘোষণা জরুরি।

git log সবচেয়ে বেশি ব্যবহৃত কমান্ডগুলোর একটা, কিন্তু বেশিরভাগ মানুষ এর ক্ষমতার ১০ শতাংশও ব্যবহার করেন না। এই মডিউলে git log-এর পুরো ফ্ল্যাগ ফ্যামিলি — visual graph, filtering (author/date/message), diff দেখানো, আর সবচেয়ে শক্তিশালী forensic টুল pickaxe search (-S/-G) — কভার হবে। এগুলো একসাথে "কে, কখন, কী, কেন বদলেছে" প্রশ্নের উত্তর সেকেন্ডে বের করার হাতিয়ার।

সমস্যাটা কী

git log ফ্ল্যাগ ছাড়া চালালে প্রতিটা commit-এর পুরো hash, author, date, message আলাদা ব্লকে দেখায় — বড় repo-তে এটা প্রায় অকেজো। বাস্তব ব্যবহারে সবসময় নির্দিষ্ট প্রশ্নের উত্তর দরকার হয়: "কে এই ফাইলটা শেষ বদলেছে?", "গত সপ্তাহে কী কী commit এসেছে?", "কোন commit-এ এই ফাংশনটা যোগ হয়েছিল?" — প্রতিটা প্রশ্নের জন্য git log-এর আলাদা ফ্ল্যাগ কম্বিনেশন আছে।

ফ্ল্যাগ ফ্যামিলির ভাগ

রিয়েল-লাইফ উদাহরণ

git log --oneline --author="Rakib" --since="2 weeks ago" -- src/notifications/

এই একটা কমান্ড উত্তর দেয়: "গত দুই সপ্তাহে আমি src/notifications/ ডিরেক্টরিতে কী কী commit করেছি?" — এটাই git log-এর আসল শক্তি: ফ্ল্যাগ কম্বাইন করে অত্যন্ত নির্দিষ্ট প্রশ্নের উত্তর বের করা।

কেন এটা ফরেনসিক স্কিলের ভিত্তি

পরের দুইটা মডিউলে (show/diff/blame, bisect) যে সব টুল দেখা যাবে, সেগুলোর অনেকটাই আসলে git log-এরই বিশেষায়িত রূপ বা git log-এর সাথে মিলিয়ে ব্যবহৃত হয়। git log ভালোভাবে আয়ত্ত করা মানেই বাকি ফরেনসিক টুলিং সহজ হয়ে যাওয়া।

মূল ফ্ল্যাগ

সবচেয়ে ব্যবহৃত কম্বো

git log --oneline --graph --all --decorate -n 15

* e4f5g6h (HEAD -> feature/retry, origin/feature/retry) fix retry backoff
* a1b2c3d add exponential backoff logic
|\
| * 9f8e7d6 (origin/main, main) hotfix: null check in notifier
* | 3c2b1a0 wip: retry counter
|/
* 7d6c5b4 initial retry skeleton

কেন --all গুরুত্বপূর্ণ

ডিফল্টে git log শুধু বর্তমান branch-এর history দেখায় — অন্য branch-এ কী হচ্ছে তা দেখা যায় না। --all দিলে local সব branch এবং remote-tracking branch (refs/remotes/*) একসাথে graph-এ দেখা যায়, ফলে বোঝা যায় বিভিন্ন branch একে অপরের সাপেক্ষে কোথায় আছে — এটা মার্জ conflict predict করা বা কোন branch পুরনো হয়ে গেছে বোঝার জন্য অমূল্য।

alias হিসেবে সেভ করা

এই কম্বো এত বেশি ব্যবহৃত হয় যে প্রায় সব অভিজ্ঞ Git ব্যবহারকারী একে alias করে রাখেন:

git config --global alias.lg "log --oneline --graph --all --decorate"
git lg -n 20

কমান্ড ফ্যামিলি

উদাহরণ

# গত মাসে Rakib-এর করা সব bugfix commit
git log --author="Rakib" --since="1 month ago" --grep="fix:"

# একটা নির্দিষ্ট তারিখ রেঞ্জ
git log --since="2026-08-01" --until="2026-08-15" --oneline

--since/--until মানব-পাঠযোগ্য তারিখ পার্স করে

Git-এর তারিখ পার্সার বেশ নমনীয় — "2 weeks ago", "yesterday", "2026-08-01", "last Monday" সবই কাজ করে। এটা internally একটা "approxidate" পার্সার ব্যবহার করে যা প্রায় সব সাধারণ human-readable তারিখ ফরম্যাট বুঝতে পারে।

--grep আর -S/-G-এর মধ্যে পার্থক্য (পরের লিফে বিস্তারিত)

--grep শুধু commit message-এ সার্চ করে, কোড কনটেন্টে না। "কোন commit-এ 'refactor' লেখা মেসেজ আছে" জানতে --grep ব্যবহার হবে, কিন্তু "কোন commit-এ একটা নির্দিষ্ট function name কোডে যোগ হয়েছে" জানতে -S/-G (pickaxe) লাগবে — সম্পূর্ণ ভিন্ন সার্চ স্পেস।

একাধিক ফিল্টার কম্বাইন করা

git log --author="Rakib" --grep="notification" --since="3 weeks ago" --oneline

সব ফিল্টার AND লজিকে কাজ করে (ডিফল্টে) — সবগুলো শর্ত মিললেই commit দেখাবে। একাধিক --author দিলে অবশ্য সেগুলো OR লজিকে কাজ করে (যেকোনো একজন মিললেই দেখাবে) — এটা একটা সূক্ষ্ম কিন্তু গুরুত্বপূর্ণ ব্যতিক্রম।

মূল ফ্ল্যাগ

-p বনাম --stat

git log --stat -3

commit e4f5g6h
Author: Rakib <rakib@example.com>
Date:   Fri Aug 21 2026

    fix retry backoff

 src/retry.py | 12 +++++++-----
 tests/test_retry.py | 5 +++++
 2 files changed, 12 insertions(+), 5 deletions(-)

--stat দ্রুত ওভারভিউ দেয় (কতগুলো ফাইল, কত লাইন), কিন্তু -p পুরো actual diff দেখায় লাইন-বাই-লাইন — গভীর review-এর জন্য -p, দ্রুত স্ক্যানের জন্য --stat।

--follow কেন দরকার

ডিফল্টে git log <file> শুধু বর্তমান নামের ফাইলের history দেখায় — যদি ফাইলটা কখনো rename হয়ে থাকে (যেমন utils.py থেকে helpers.py), rename-এর আগের history দেখা যায় না। --follow Git-কে বলে rename detection চালিয়ে পুরনো নামের history-ও যুক্ত করে দেখাতে।

git log --follow --oneline -- src/helpers.py
# e4f5g6h rename utils.py to helpers.py
# a1b2c3d add caching logic          <- এটা তখন utils.py নামে ছিল
# 7d6c5b4 initial utils functions    <- এটাও utils.py নামে ছিল

গুরুত্বপূর্ণ সীমাবদ্ধতা

--follow শুধু একটা ফাইলের সাথে কাজ করে — একাধিক pathspec দিলে (git log --follow file1.py file2.py) Git error দেবে বা অপ্রত্যাশিত আচরণ করবে। এছাড়া rename detection heuristic-ভিত্তিক (content similarity threshold), তাই খুব বেশি বদলে যাওয়া ফাইল rename হিসেবে ধরা নাও পড়তে পারে।

সমস্যাটা কী

ধরুন আপনি জানতে চান "কোন commit-এ MAX_RETRY_COUNT variable-টা যোগ বা মুছে গেছে?" — --grep কাজ করবে না কারণ এটা commit message খোঁজে, কোড না। এখানে দরকার pickaxe — কোড কনটেন্টের ভেতরে সার্চ করার ফিচার।

-S<string> — occurrence count পরিবর্তন খোঁজে

git log -S"MAX_RETRY_COUNT" --oneline

-S একটা commit দেখায় শুধু তখনই যখন সেই commit-এ MAX_RETRY_COUNT স্ট্রিং-এর সংখ্যা (occurrence count) বদলেছে — যোগ হয়েছে বা মুছে গেছে (শুধু একটা লাইনের ভেতরে সরে যাওয়া/পুনর্বিন্যাস হলে count অপরিবর্তিত থাকে, তখন -S দেখাবে না)।

-G<regex> — regex ম্যাচিং লাইনে যেকোনো পরিবর্তন খোঁজে

git log -G"retry_count\s*=\s*\d+" --oneline

-G একটা commit দেখায় যদি diff-এর কোনো যোগ/মোছা লাইন সেই regex-এর সাথে ম্যাচ করে — occurrence count বদলাক বা না বদলাক। -G আরও broad — এটা যেকোনো লাইন-লেভেল পরিবর্তন ধরে যা প্যাটার্নের সাথে মেলে।

পার্থক্য এক টেবিলে

রিয়েল-লাইফ উদাহরণ

একটা production bug ট্রেস করতে গিয়ে জানা দরকার কবে একটা নির্দিষ্ট SQL query pattern যোগ হয়েছিল:

git log -S"SELECT * FROM orders" --oneline -p -- src/db/

-p-র সাথে কম্বাইন করলে সরাসরি সেই commit-এর diff-ও দেখা যায়, আলাদা করে git show চালানো লাগে না।

কেন কাস্টম ফরম্যাট দরকার

--oneline দ্রুত কিন্তু সীমিত — author, ফুল তারিখ, বা কমা-সেপারেটেড CSV-এর মতো আউটপুট দরকার হলে --pretty=format:"..." দিয়ে সম্পূর্ণ কাস্টম টেমপ্লেট বানানো যায়।

প্লেসহোল্ডার রেফারেন্স

উদাহরণ

git log --pretty=format:"%h | %ad | %an | %s" --date=short -5

e4f5g6h | 2026-08-21 | Rakib Hasan | fix retry backoff
a1b2c3d | 2026-08-20 | Rakib Hasan | add exponential backoff logic
9f8e7d6 | 2026-08-19 | Team Member | hotfix: null check in notifier

স্ক্রিপ্টিং-এ ব্যবহার

CI/CD পাইপলাইনে changelog স্বয়ংক্রিয় জেনারেট করার জন্য এটা খুব কাজে লাগে:

git log --pretty=format:"- %s (%h)" v1.2.0..HEAD > CHANGELOG_DRAFT.md

এই কমান্ড শেষ ট্যাগ থেকে এখন পর্যন্ত সব commit message-এর একটা bullet-list তৈরি করে দেয় — রিলিজ নোট লেখার প্রথম খসড়া হিসেবে ব্যবহারযোগ্য।

alias-এ সেভ করা

git config --global alias.changelog 'log --pretty=format:"- %s (%h)"'

লক্ষ্য

একটা repo তৈরি করে, ইচ্ছাকৃতভাবে একটা কনফিগ ভ্যালু কয়েকবার বদলে, -S/-G দিয়ে সেই পরিবর্তনের ইতিহাস খুঁজে বের করা।

সেটআপ

mkdir -p ~/git-lab4 && cd ~/git-lab4 && git init

echo "TIMEOUT_SECONDS = 30" > config.py
git add config.py && git commit -m "initial config"

echo "TIMEOUT_SECONDS = 30
RETRY_COUNT = 3" > config.py
git add config.py && git commit -m "add retry count"

sed -i 's/RETRY_COUNT = 3/RETRY_COUNT = 5/' config.py
git add config.py && git commit -m "bump retry count to 5"

echo "TIMEOUT_SECONDS = 60
RETRY_COUNT = 5" > config.py
git add config.py && git commit -m "increase timeout"

ধাপ ১ — -S দিয়ে কবে RETRY_COUNT যোগ/মোছা হয়েছে খোঁজা

git log -S"RETRY_COUNT" --oneline
# শুধু "add retry count" commit দেখাবে — কারণ এটাই যেখানে RETRY_COUNT প্রথম আবির্ভূত হয়েছে
# (occurrence count 0 থেকে 1 হয়েছে)

ধাপ ২ — -G দিয়ে RETRY_COUNT-এর সংখ্যা-পরিবর্তন সহ যেকোনো লাইন-বদল খোঁজা

git log -G"RETRY_COUNT = [0-9]+" --oneline
# "add retry count" এবং "bump retry count to 5" — দুইটাই দেখাবে
# কারণ দ্বিতীয়টা লাইন বদলেছে কিন্তু occurrence count বদলায়নি (তাই -S এটা মিস করত)

ধাপ ৩ — পার্থক্য যাচাই

git log -S"RETRY_COUNT" --oneline | wc -l   # ১টা commit
git log -G"RETRY_COUNT" --oneline | wc -l   # ২টা commit

চ্যালেঞ্জ

-p-র সাথে -G কম্বাইন করে (git log -G"RETRY_COUNT" -p -- config.py) সরাসরি দেখুন প্রতিটা matched commit-এ ঠিক কোন লাইনটা বদলেছে।

প্র.১ — --grep আর -S (pickaxe)-এর মধ্যে পার্থক্য কী? উত্তর: --grep commit message-এ টেক্সট খোঁজে। -S (pickaxe) actual কোড কনটেন্টে একটা স্ট্রিং-এর occurrence count কোন commit-এ বদলেছে তা খোঁজে। সম্পূর্ণ ভিন্ন সার্চ স্পেস — একটা মেসেজে, আরেকটা কোডে।

প্র.২ — -S আর -G-এর মধ্যে পার্থক্য কী? উত্তর: -S<string> শুধু তখন commit দেখায় যখন স্ট্রিং-এর occurrence count বদলেছে (যোগ/মোছা)। -G<regex> broader — regex-ম্যাচিং যেকোনো লাইনে diff হলেই দেখায়, occurrence count অপরিবর্তিত থাকলেও (যেমন লাইন পুনর্বিন্যাস বা ভ্যালু বদল)।

প্র.৩ — git log --follow-এর সীমাবদ্ধতা কী? উত্তর: শুধু একটা ফাইলের সাথে কাজ করে (একাধিক pathspec দিলে error/অপ্রত্যাশিত আচরণ), এবং rename detection heuristic-ভিত্তিক (content similarity threshold) — খুব বেশি বদলে যাওয়া ফাইল rename হিসেবে ধরা নাও পড়তে পারে।

প্র.৪ — git log --author="A" --author="B" চালালে কী হবে? উত্তর: A অথবা B — যেকোনো একজনের commit দেখাবে (OR লজিক)। এটা একটা ব্যতিক্রম, কারণ সাধারণত একাধিক ভিন্ন ফিল্টার (যেমন --author আর --since একসাথে) AND লজিকে কাজ করে, কিন্তু একই ফ্ল্যাগ একাধিকবার দিলে OR হয়ে যায়।

প্র.৫ — একটা changelog স্বয়ংক্রিয় জেনারেট করতে চান শেষ রিলিজ ট্যাগ থেকে এখন পর্যন্ত — কোন কমান্ড ব্যবহার করবেন? উত্তর: git log --pretty=format:"- %s (%h)" v1.2.0..HEAD — এটা v1.2.0 ট্যাগের পর থেকে HEAD পর্যন্ত সব commit-এর subject আর short hash একটা bullet-list ফরম্যাটে দেখায়, changelog draft হিসেবে ব্যবহারযোগ্য।

প্র.৬ — --stat আর -p-এর মধ্যে কোনটা কখন ব্যবহার করবেন? উত্তর: --stat দ্রুত ওভারভিউয়ের জন্য (কতগুলো ফাইল, কত লাইন যোগ/মোছা হয়েছে) — বড় সংখ্যক commit স্ক্যান করার সময় উপযোগী। -p পুরো actual diff দেখায় লাইন-বাই-লাইন — একটা নির্দিষ্ট commit-এর গভীর review-এর জন্য।

• -S স্ট্রিং-এ regex special character (যেমন ., *) থাকলে ডিফল্টে literal string হিসেবে treat হয়, regex হিসেবে না — regex হিসেবে ব্যবহার করতে চাইলে --pickaxe-regex ফ্ল্যাগ যোগ করতে হবে, না হলে অপ্রত্যাশিত (কোনো) ফলাফল আসতে পারে।
• merge commit-এ ডিফল্টে -p diff দেখায় না — কারণ merge commit-এর দুইটা parent, কোন দিক থেকে diff দেখাবে তা অস্পষ্ট। -p দিয়ে merge commit-এর diff দেখতে হলে --diff-merges বা -m ফ্ল্যাগ যোগ করতে হয়।
• --since/--until কমিটের author date-এর ওপর ভিত্তি করে ফিল্টার করে, commit date-এর ওপর না — rebase-এর পরে author date অপরিবর্তিত থাকে কিন্তু commit date বদলে যায়, তাই কখনো কখনো --since দিয়ে ফিল্টার করলে প্রত্যাশার চেয়ে বেশি বা কম commit দেখা যেতে পারে।
• git log --all সব local branch/tag/remote-tracking ref দেখায়, কিন্তু stash বা reflog-only commit না — git stash list-এ যা আছে তা --all-এ দেখাবে না যদি না আলাদা করে git log --all --source $(git rev-parse --all) refs/stash এর মতো কিছু করা হয়। এটা প্রায়ই ভুলে যাওয়া হয় যে stash আসলাদা namespace-এ থাকে।

git log দিয়ে বোঝা যায় "কী কী commit হয়েছে", কিন্তু "একটা নির্দিষ্ট commit-এ ঠিক কী বদলেছে" বা "এই লাইনটা কে লিখেছিল" জানতে দরকার আরও নির্দিষ্ট টুল — git show, git diff, git blame। এই মডিউলে এই তিনটা কমান্ড, তাদের সিনট্যাক্স ভ্যারিয়েশন (two-dot vs three-dot), আর দুইটা সহায়ক কমান্ড — git shortlog (কন্ট্রিবিউটর র‍্যাংকিং) ও git describe (build version string) — কভার হবে।

তিনটা টুলের ভূমিকা

রিয়েল-লাইফ ফরেনসিক ফ্লো

একটা bug রিপোর্ট আসলে সাধারণ ফ্লো: প্রথমে git blame দিয়ে সন্দেহজনক লাইনটা কোন commit-এ এসেছে খুঁজে বের করা, তারপর git show <commit> দিয়ে সেই commit-এর পুরো প্রেক্ষাপট (message, পুরো diff, author) দেখা, প্রয়োজনে git diff <commit>^..<commit> দিয়ে আরও সূক্ষ্মভাবে ওই একটা commit-এর আগে-পরে তুলনা করা।

git blame -L 45,50 src/payment.py
# একটা সন্দেহজনক লাইনের কমিট hash পাওয়া গেলো: a1b2c3d
git show a1b2c3d
# পুরো commit context — message, author, diff

এগুলো git log-এর সাথে সম্পর্ক

git show আসলে git log -1 -p <commit>-এর সমতুল্য (একটা মাত্র commit-এর জন্য patch mode log) — আলাদা কমান্ড হলেও ভেতরে একই diff-generation মেশিনারি ব্যবহার করে। git diff ভিন্ন — এটা কোনো commit history দেখায় না, শুধু দুইটা নির্দিষ্ট point-এর মধ্যে পার্থক্য গণনা করে।

রূপ ১ — একটা commit দেখানো

git show a1b2c3d

পুরো commit metadata (author, date, message) + diff দেখায় — parent commit-এর সাথে তুলনা করে।

রূপ ২ — একটা tag দেখানো

git show v1.2.0

Annotated tag হলে প্রথমে tag object-এর নিজের তথ্য (tagger, date, message) দেখায়, তারপর যে commit-এ tag পয়েন্ট করছে তার diff। Lightweight tag হলে সরাসরি commit-এর তথ্যই দেখাবে (কারণ lightweight tag-এর নিজস্ব কোনো object নেই — Module 23-এ বিস্তারিত)।

রূপ ৩ — commit:path দিয়ে একটা নির্দিষ্ট সময়ের ফাইল দেখা

git show a1b2c3d:src/config.py

এটা diff দেখায় না — বরং সেই commit-এর মুহূর্তে src/config.py ফাইলটা ঠিক কেমন ছিল তার সম্পূর্ণ কনটেন্ট দেখায় (যেমন সেই সময় cat করলে যা দেখতেন)। এটা internally git cat-file -p দিয়ে সেই commit-এর tree object থেকে blob-টা resolve করে বের করে আনে (Phase 1-এর object model-এর সরাসরি প্রয়োগ)।

রিয়েল-লাইফ উদাহরণ

একটা পুরনো bug ডিবাগ করতে গিয়ে জানা দরকার ৩ মাস আগে একটা কনফিগ ফাইল কেমন দেখতে ছিল, বর্তমান branch checkout না করেই:

git show HEAD~50:src/config.py > /tmp/old_config.py
diff /tmp/old_config.py src/config.py

git show দিয়ে merge commit

merge commit-এ git show ডিফল্টে কম্বাইন্ড diff দেখায় (শুধু conflict resolution-এর অংশ) — পুরো diff দেখতে -m ফ্ল্যাগ লাগে, ঠিক git log -p-এর মতো একই আচরণ (Module 20-এর corner case-এ উল্লেখিত)।

সিনট্যাক্স

git diff-এ পার্থক্য

git diff main..feature-x
# main-এর বর্তমান অবস্থা আর feature-x-এর বর্তমান অবস্থার মধ্যে সরাসরি ফাইল-content পার্থক্য

git diff main...feature-x
# main আর feature-x-এর common ancestor (merge-base) থেকে feature-x পর্যন্ত পার্থক্য
# — অর্থাৎ "feature-x branch তৈরি হওয়ার পর থেকে feature-x-এ কী কী বদলেছে",
#   main-এ এর মাঝে নতুন commit এলেও তা এই diff-এ আসবে না

git diff-এ আসলে two-dot আর A B (স্পেস দিয়ে, ডট ছাড়া) একই জিনিস — সরাসরি দুইটা point-এর snapshot তুলনা। Three-dot প্রথমে merge-base বের করে, তারপর সেখান থেকে তুলনা করে।

git log-এ পার্থক্য

git log main..feature-x
# শুধু feature-x-এ আছে কিন্তু main-এ নেই এমন commit

git log main...feature-x
# main এবং feature-x — দুই দিকেই যা একে অপরের নেই এমন সব commit (উভয়ের ইউনিক অংশ)
# --left-right ফ্ল্যাগ দিলে কোনটা কোন দিক থেকে এসেছে তাও দেখায়

রিয়েল-লাইফ ব্যবহার: PR review-এর আগে

একটা Pull Request review করার আগে জানতে চান "আমার feature branch-এ ঠিক কী কী নতুন কাজ আছে, main-এ এর মাঝে যা এসেছে তা বাদে":

git diff main...feature-x    # শুধু feature-x-এর নিজস্ব পরিবর্তন
git log --oneline main...feature-x --left-right
# < a1b2c3d main-only commit
# > e4f5g6h feature-x-only commit

মনে রাখার শর্টকাট

Two-dot = "সরাসরি একজন থেকে আরেকজনে যাওয়ার পথ"। Three-dot = "দুইজনের শেয়ার্ড বিন্দু থেকে হিসাব"।

সমস্যাটা কী

git diff সাধারণত repository-র ভেতরের কমিট/staged/working state তুলনা করে — কিন্তু মাঝে মাঝে দুইটা সম্পূর্ণ আলাদা, Git-এর ট্র্যাকিং-এর বাইরের ফাইল তুলনা করা দরকার হয় (যেমন দুইটা আলাদা প্রজেক্টের কনফিগ ফাইল, বা কোনো ডাউনলোড করা দুইটা ভার্সনের ফাইল)।

সমাধান

git diff --no-index /path/to/file-a.txt /path/to/file-b.txt

এটা কোনো Git repository-র প্রয়োজন ছাড়াই কাজ করে (এমনকি একটা non-Git ডিরেক্টরিতেও চলবে) — শুধু Git-এর চমৎকার diff algorithm আর coloring ব্যবহার করে দুইটা ফাইল তুলনা করে, diff -u-এর একটা আরও সুন্দর বিকল্প হিসেবে।

রিয়েল-লাইফ উদাহরণ

দুইটা environment-এর কনফিগ ফাইল তুলনা করা (production বনাম staging), যেগুলো একই repo-তে নেই:

git diff --no-index config/production.env config/staging.env

diff --git a/config/production.env b/config/staging.env
index a1b2c3d..e4f5g6h 100644
--- a/config/production.env
+++ b/config/staging.env
@@ -1,3 +1,3 @@
 DATABASE_HOST=prod-db.internal
-DEBUG=false
+DEBUG=true
 MAX_CONNECTIONS=100

গুরুত্বপূর্ণ আচরণ

--no-index মোডে exit code অন্যান্য diff-এর মতোই — ফাইল দুইটা অভিন্ন হলে 0, ভিন্ন হলে 1 রিটার্ন করে, যা script-এ conditional check করার জন্য ব্যবহারযোগ্য। এছাড়া দুইটা ডিরেক্টরি দিলে recursively সব ফাইল তুলনা করবে।

বেসিক ব্যবহার

git blame src/payment.py

প্রতিটা লাইনের পাশে কোন commit, কে, কবে লিখেছে তা দেখায়।

-L — লাইন রেঞ্জ সীমাবদ্ধ করা

পুরো ফাইলের blame দরকার নেই সবসময় — নির্দিষ্ট লাইন রেঞ্জে সীমাবদ্ধ করা যায়:

git blame -L 40,60 src/payment.py
git blame -L /def calculate_fee/,+15 src/payment.py   # ফাংশন খুঁজে সেখান থেকে ১৫ লাইন

-w — whitespace পরিবর্তন উপেক্ষা করা

শুধু indentation/whitespace বদলানো একটা commit-কে blame-এ "আসল লেখক" হিসেবে দেখানো অনুপযুক্ত — -w সেই noise বাদ দিয়ে প্রকৃত content পরিবর্তনকারী commit দেখায়।

git blame -w src/payment.py

--ignore-rev/--ignore-revs-file — বড় reformat commit বাদ দেওয়া

একটা টিম যদি কখনো পুরো কোডবেসে একটা bulk black/prettier reformat commit চালায়, সেই commit blame-এ প্রতিটা লাইনের "লেখক" হিসেবে দেখাতে শুরু করবে — আসল ঐতিহাসিক লেখক হারিয়ে যাবে। সমাধান:

git blame --ignore-rev a1b2c3d src/payment.py

# অথবা স্থায়ীভাবে একটা ফাইলে সব reformat commit রেখে
echo "a1b2c3d" >> .git-blame-ignore-revs
git blame --ignore-revs-file .git-blame-ignore-revs src/payment.py

# পুরো টিমের জন্য স্থায়ী কনফিগ (GitHub-ও এই ফাইল অটো-ডিটেক্ট করে)
git config blame.ignoreRevsFile .git-blame-ignore-revs

রিয়েল-লাইফ প্রভাব

.git-blame-ignore-revs ফাইলটা GitHub/GitLab-এর web UI blame view-ও সম্মান করে — এটা এখন একটা de facto স্ট্যান্ডার্ড কনভেনশন বড় reformat commit-এর blame noise এড়াতে।

git shortlog -sn — কন্ট্রিবিউটর র‍্যাংকিং

git shortlog -sn

   142  Rakib Hasan
    38  Team Member A
    12  Team Member B

-s মানে summary (শুধু সংখ্যা, কমিট লিস্ট না), -n মানে সংখ্যা অনুযায়ী sort (বেশি থেকে কম)। এটা রিলিজ নোটে "Contributors" সেকশন বানাতে, বা কোন অংশে কে সবচেয়ে বেশি সক্রিয় বোঝার জন্য ব্যবহার হয়।

# একটা নির্দিষ্ট রেঞ্জে (শেষ রিলিজ থেকে) কন্ট্রিবিউটর
git shortlog -sn v1.2.0..HEAD

git describe --tags --always — build version string

CI/CD পাইপলাইনে প্রতিটা build-কে একটা মানুষ-পাঠযোগ্য, ইউনিক ভার্সন স্ট্রিং দেওয়া দরকার। git describe কাছের tag থেকে current commit পর্যন্ত দূরত্ব গণনা করে একটা স্ট্রিং বানায়:

git describe --tags --always
# v1.2.0-14-ga1b2c3d

এই আউটপুট ভাঙলে: v1.2.0 (সবচেয়ে কাছের ancestor tag) + -14 (সেই tag-এর পর ১৪টা commit হয়েছে) + -g (git-এর সংক্ষিপ্ত রূপ) + a1b2c3d (বর্তমান commit-এর short hash)। যদি current commit-ই একটা tag হয়, শুধু v1.2.0 দেখাবে (এক্সট্রা suffix ছাড়া)।

--always কেন গুরুত্বপূর্ণ

যদি repo-তে কোনো tag-ই না থাকে, git describe (ফ্ল্যাগ ছাড়া) error দেয়। --always দিলে tag না পেলেও fallback হিসেবে শুধু commit hash রিটার্ন করে — CI স্ক্রিপ্ট কখনো crash করবে না।

রিয়েল-লাইফ ব্যবহার: Docker image ট্যাগিং

VERSION=$(git describe --tags --always)
docker build -t myapp:$VERSION .

এভাবে প্রতিটা Docker image build-এর সাথে ঠিক কোন commit থেকে বানানো হয়েছে তার একটা ট্রেসেবল রেকর্ড থাকে — production-এ কোনো bug এলে ঠিক কোন কোড চলছিল তা image ট্যাগ থেকেই সরাসরি বোঝা যায়।

লক্ষ্য

একটা সিমুলেটেড bug-এর উৎস git blame দিয়ে খুঁজে বের করে git show দিয়ে পুরো প্রেক্ষাপট বুঝে নেওয়া, তারপর two-dot/three-dot diff দিয়ে branch তুলনা।

সেটআপ

mkdir -p ~/git-lab5 && cd ~/git-lab5 && git init

cat > payment.py << 'EOF'
def calculate_fee(amount):
    return amount * 0.02
EOF
git add payment.py && git commit -m "add fee calculation"

sed -i 's/0.02/0.05/' payment.py
git add payment.py && git commit -m "update fee rate per new policy"

echo "# payment module" >> payment.py
git add payment.py && git commit -m "add module comment"

ধাপ ১ — blame দিয়ে সন্দেহজনক লাইন খোঁজা

git blame payment.py
# ^xxxxx (author, date, line 1) def calculate_fee(amount):
# xxxxxxx (author, date, line 2)     return amount * 0.05

দেখুন লাইন ২-এর commit hash কোনটা — সেটাই fee rate বদলের commit।

ধাপ ২ — show দিয়ে পুরো প্রেক্ষাপট

git show <hash-from-blame>
# পুরো diff: 0.02 -> 0.05, message: "update fee rate per new policy"

ধাপ ৩ — branch তৈরি করে two-dot/three-dot পার্থক্য দেখা

git checkout -b experiment
sed -i 's/0.05/0.10/' payment.py
git add payment.py && git commit -m "experiment: higher fee"

git checkout main
echo "logging = true" >> payment.py
git add payment.py && git commit -m "add logging flag on main"

git diff main..experiment    # সরাসরি বর্তমান দুই অবস্থার তুলনা (দুটো পরিবর্তনই দেখাবে)
git diff main...experiment   # শুধু experiment branch তৈরি হওয়ার পর থেকে experiment-এ কী বদলেছে

যা লক্ষ্য করবেন

main..experiment আর main...experiment-এর আউটপুট আলাদা হবে কারণ main-এ experiment branch তৈরি হওয়ার পরও নতুন commit (logging flag) এসেছে — three-dot সেটা বাদ দিয়ে শুধু experiment-এর নিজস্ব পরিবর্তন দেখাবে।

প্র.১ — git diff main..feature-আর git diff main...feature-এর পার্থক্য কী? উত্তর: main..feature (two-dot) main আর feature-এর বর্তমান অবস্থার সরাসরি তুলনা। main...feature (three-dot) প্রথমে তাদের common ancestor (merge-base) বের করে, তারপর সেখান থেকে feature পর্যন্ত পার্থক্য দেখায় — main-এ পরে আসা নতুন commit বাদ দিয়ে।

প্র.২ — git show <commit>:<path> কী রিটার্ন করে, আর এটা git diff-এর থেকে কীভাবে আলাদা? উত্তর: এটা ওই commit-এর মুহূর্তে সেই ফাইলের সম্পূর্ণ কনটেন্ট রিটার্ন করে (একটা diff না, পুরো স্ন্যাপশট) — internally commit-এর tree object থেকে blob resolve করে। git diff কোনো একক ফাইলের কনটেন্ট দেখায় না, দুইটা অবস্থার মধ্যে পার্থক্য দেখায়।

প্র.৩ — টিমের একটা bulk code-formatting commit git blame-কে অকেজো করে দিয়েছে — কীভাবে ঠিক করবেন? উত্তর: সেই formatting commit-এর hash .git-blame-ignore-revs ফাইলে যোগ করে git config blame.ignoreRevsFile .git-blame-ignore-revs সেট করুন — এরপর git blame (এবং GitHub-এর web UI) সেই commit-কে স্কিপ করে আসল content-পরিবর্তনকারী commit দেখাবে।

প্র.৪ — git describe --tags --always কমান্ডের আউটপুট v1.2.0-14-ga1b2c3d-এর অর্থ কী? উত্তর: v1.2.0 হলো সবচেয়ে কাছের ancestor tag, 14 মানে সেই tag-এর পর ১৪টা commit হয়েছে, g git-এর সংক্ষিপ্ত রূপ, a1b2c3d বর্তমান commit-এর short hash। এটা CI/CD-তে build version string বানাতে ব্যবহৃত হয়।

প্র.৫ — git diff --no-index কেন দরকার হতে পারে, যেখানে সাধারণ diff -u কমান্ডও আছে? উত্তর: --no-index Git repository ছাড়াই দুইটা যেকোনো ফাইল/ডিরেক্টরি তুলনা করতে দেয়, Git-এর উন্নত diff algorithm ও syntax-aware coloring ব্যবহার করে — diff -u-এর তুলনায় আউটপুট পড়া সহজ এবং একই টুলিং (যেমন git diff --color-words) ব্যবহার করা যায়।

প্র.৬ — git shortlog -sn-এর -s আর -n ফ্ল্যাগ কী করে? উত্তর: -s (summary) শুধু প্রতিটা author-এর commit সংখ্যা দেখায়, পূর্ণ commit লিস্ট না। -n সেই সংখ্যা অনুযায়ী descending order-এ sort করে — সবচেয়ে বেশি অবদানকারী শীর্ষে আসে।

• git blame একটা লাইনকে "সর্বশেষ কে বদলেছে" তার কমিট দেখায়, "কে মূলত লিখেছে" তা না — একটা লাইন যদি অনেকবার সামান্য বদলানো হয়ে থাকে (এমনকি শুধু একটা indentation ফিক্সেও), blame সবসময় সর্বশেষ পরিবর্তনকারীকে দেখাবে, মূল লেখককে না — এই জন্যই -w আর --ignore-revs-file গুরুত্বপূর্ণ।
• git diff main...feature-এ merge-base বের করতে ব্যর্থ হলে (দুইটা branch-এর কোনো common history না থাকলে) error আসে, বিশেষ করে git checkout --orphan দিয়ে তৈরি সম্পূর্ণ আলাদা history-র branch-এ।
• git show কোনো argument ছাড়া চালালে সবসময় HEAD দেখায়, staged বা unstaged পরিবর্তন না — নতুনরা মাঝে মাঝে ভুলে ভাবেন এটা working directory-র পরিবর্তন দেখাবে, কিন্তু staged/unstaged diff দেখতে git diff/git diff --staged লাগবে।
• git describe ট্যাগ ছাড়া repo-তে ফ্ল্যাগ ছাড়া চালালে fatal error দেয় ("No names found") — --always ফ্ল্যাগ ছাড়া এটা স্ক্রিপ্টে ব্যবহার করলে CI pipeline crash করতে পারে যদি কোনো কারণে tag missing থাকে (যেমন shallow clone-এ tag আনা না হলে)।

কল্পনা করুন একটা bug production-এ ধরা পড়েছে, কিন্তু ঠিক কোন commit-এ এটা ঢুকেছে তা অজানা — আর মাঝে হাজার commit আছে। প্রতিটা commit ম্যানুয়ালি চেক করা অবাস্তব। git bisect এই সমস্যার সমাধান — একটা বিল্ট-ইন বাইনারি সার্চ টুল যা মাত্র log₂(n) ধাপে bug-introducing commit খুঁজে বের করে। এই মডিউলে bisect-এর ম্যানুয়াল আর অটোমেটেড (bisect run) — দুই রূপই কভার হবে।

সমস্যা

একটা production bug রিপোর্ট এসেছে: "checkout page ভেঙে গেছে"। জানা যায় ২ সপ্তাহ আগে এটা ঠিক ছিল, এখন নেই — মাঝে ২০০টা commit হয়ে গেছে। কোন commit-এ bug ঢুকেছে তা খুঁজে বের করাই সমস্যা — bug-টা ঠিক হলে root cause বোঝা সহজ হয়ে যায় (ওই commit-এর diff দেখেই বোঝা যায় কী বদলেছে)।

নাইভ সমাধানের অক্ষমতা

২০০টা commit একে একে (linear search) চেক করলে গড়ে ১০০টা চেক করতে হতে পারে — প্রতিটা চেকে checkout + build + test = কয়েক মিনিট ধরলে এটা কয়েক ঘণ্টার কাজ।

git bisect-এর সমাধান

git bisect একটা binary search algorithm প্রয়োগ করে commit history-র ওপর। আপনি শুধু একটা "known good" আর একটা "known bad" commit বলে দেন, bisect মাঝখানের commit-এ checkout করে, আপনি টেস্ট করে বলেন good/bad, bisect পরের অর্ধেক অংশে আবার একই কাজ করে — যতক্ষণ না ঠিক এক commit বাকি থাকে, যেটাই bug-introducing commit।

রিয়েল-লাইফ ইমপ্যাক্ট

২০০টা commit-এর জন্য linear search-এ গড়ে ১০০টা চেক লাগত, bisect-এ মাত্র log₂(200) ≈ 8 টা চেক লাগবে — ১২ গুণেরও বেশি দ্রুত। এই পার্থক্য যত বড় হয় history, তত বেশি প্রকট হয় (২০০০ commit-এ মাত্র log₂(2000) ≈ 11 ধাপ)।

এক লাইনে

bisect একটা "20 প্রশ্নে সংখ্যা অনুমান" গেমের মতো, শুধু সংখ্যার বদলে commit history নিয়ে খেলা হয়।

অ্যালগরিদমের মূল ধারণা

ধরুন commit history-টা একটা sorted array (ধরে নেওয়া হয় bug একবার ঢোকার পর সব commit-এই থেকে যায় — monotonicity assumption, নিচে বিস্তারিত)। bisect প্রতিবার সার্চ স্পেসের ঠিক মাঝখানের commit বেছে নেয়:

good ----------------- ? ----------------- bad
     [    100 commit    ]  [   100 commit   ]

মাঝখানের commit টেস্ট করে good/bad বলার পর, bisect সার্চ স্পেস অর্ধেক করে ফেলে — good হলে ডান অর্ধেকে খোঁজা চলবে, bad হলে বাম অর্ধেকে।

গাণিতিক ভিত্তি

nটা commit-এর মধ্যে খুঁজতে সর্বোচ্চ ⌈log₂(n)⌉ ধাপ লাগে, কারণ প্রতিটা ধাপে সার্চ স্পেস অর্ধেক হয়ে যায়:

Monotonicity Assumption — গুরুত্বপূর্ণ পূর্বশর্ত

bisect ধরে নেয় bug একবার ঢোকার পর সরে যায় না (একটা single "boundary" আছে good আর bad-এর মধ্যে)। বাস্তবে যদি bug flaky হয় (মাঝে মাঝে দেখা দেয়, মাঝে মাঝে না) অথবা একটা bug ফিক্স হয়ে আবার অন্য কারণে ফিরে আসে (non-monotonic history), bisect ভুল ফলাফল দিতে পারে — এই সীমাবদ্ধতা মাথায় রাখা জরুরি।

git bisect-এর ভেতরে কী ট্র্যাক হয়

bisect internally .git/BISECT_LOG, .git/BISECT_START, আর refs/bisect/* ব্যবহার করে সার্চ স্পেসের বর্তমান অবস্থা ট্র্যাক করে — এই জন্যই git bisect মাঝপথে থামিয়ে অন্য কাজ করে পরে ফিরে এসেও চালিয়ে যাওয়া যায়, রাজ্য হারায় না।

পুরো ওয়ার্কফ্লো

git bisect start
git bisect bad                  # বর্তমান commit খারাপ (bug আছে)
git bisect good v1.5.0          # v1.5.0 ট্যাগে bug ছিল না

# Git এখন মাঝখানের commit-এ checkout করে দেবে
# আপনি ম্যানুয়ালি টেস্ট করে বলবেন:
git bisect good     # অথবা
git bisect bad

# এভাবে চলতেই থাকবে যতক্ষণ না bisect বলে:
# "a1b2c3d is the first bad commit"

প্রতিটা সাব-কমান্ড

skip কেন দরকার

মাঝে মাঝে একটা মাঝপথের commit টেস্ট করা যায় না — হয়তো সেই commit-এ কোড কম্পাইলই হয় না (অসম্পর্কিত কারণে), অথবা সেই সময়ে একটা dependency ভাঙা ছিল। git bisect skip সেই commit বাদ দিয়ে bisect-কে পাশের একটা commit চেষ্টা করতে বলে, পুরো প্রসেস আটকে না গিয়ে।

git bisect skip
# পরবর্তী কাছের commit-এ চলে যাবে টেস্টের জন্য

git bisect reset-এর গুরুত্ব

bisect চলাকালীন repo detached HEAD অবস্থায় থাকে (একের পর এক commit checkout হচ্ছে)। কাজ শেষে git bisect reset অবশ্যই চালাতে হবে, নাহলে repo সেই detached অবস্থায় আটকে থাকবে — আসল branch-এ ফিরে আসা হবে না।

ম্যানুয়াল bisect-এর সীমাবদ্ধতা

প্রতিটা ধাপে ম্যানুয়ালি checkout, build, test করে good/bad বলা সময়সাপেক্ষ — বিশেষ করে যদি টেস্ট প্রক্রিয়াটা সহজেই স্ক্রিপ্ট করা যায় (একটা unit test চালানো, একটা exit code চেক করা)।

bisect run — একটা স্ক্রিপ্ট দিয়ে পুরো প্রসেস অটোমেট করা

git bisect start
git bisect bad HEAD
git bisect good v1.5.0
git bisect run ./test-script.sh

test-script.sh একটা exit code রিটার্ন করবে: 0 মানে good, নন-জিরো (১২৫ ছাড়া) মানে bad, 125 মানে skip (untestable)। bisect স্বয়ংক্রিয়ভাবে প্রতিটা মাঝখানের commit-এ checkout করে স্ক্রিপ্ট চালাবে, exit code দেখে good/bad সিদ্ধান্ত নেবে, এবং শেষে সরাসরি bug-introducing commit বলে দেবে — কোনো ম্যানুয়াল হস্তক্ষেপ ছাড়াই।

রিয়েল-লাইফ স্ক্রিপ্ট উদাহরণ

#!/bin/bash
# test-script.sh
pip install -q -e . 2>/dev/null
python -m pytest tests/test_checkout.py::test_apply_discount -q
exit $?

git bisect start HEAD v1.5.0
git bisect run ./test-script.sh
# Output চলার পর:
# a1b2c3d is the first bad commit

কেন এটা এত শক্তিশালী

bisect run মানুষের বিচার-বুদ্ধি সরিয়ে সম্পূর্ণ deterministic test দিয়ে replace করে — এটা CI pipeline-এও ব্যবহার করা যায় (একটা nightly job যা automatically একটা regression-এর root cause খুঁজে বের করে টিমকে জানিয়ে দেয়)। একটা জটিল, কয়েক ঘণ্টার ম্যানুয়াল ডিবাগিং প্রসেস এভাবে কয়েক মিনিটের একটা স্বয়ংক্রিয় কমান্ডে পরিণত হয়ে যায়।

সতর্কতা

স্ক্রিপ্টটা অবশ্যই deterministic হতে হবে এবং সাইড-ইফেক্ট মুক্ত (একটা পুরনো commit-এ চালালে যেন সিস্টেমের অন্য কোনো state নষ্ট না হয়) — না হলে bisect ভুল ফলাফল দিতে পারে বা bisect সেশনই নষ্ট হয়ে যেতে পারে।

লক্ষ্য

ইচ্ছাকৃতভাবে একটা bug কয়েক commit আগে ঢুকিয়ে, একটা test script লিখে, git bisect run দিয়ে সম্পূর্ণ স্বয়ংক্রিয়ভাবে সেটা খুঁজে বের করা।

সেটআপ — একটা ছোট ফাংশন আর টেস্ট

mkdir -p ~/git-lab6 && cd ~/git-lab6 && git init

cat > calc.py << 'EOF'
def add(a, b):
    return a + b
EOF
git add calc.py && git commit -m "c0: initial add function"

cat > test_calc.py << 'EOF'
from calc import add
def test_add():
    assert add(2, 3) == 5
EOF
git add test_calc.py && git commit -m "c1: add test"

echo "# comment c2" >> calc.py && git add calc.py && git commit -m "c2: unrelated comment"
echo "# comment c3" >> calc.py && git add calc.py && git commit -m "c3: another comment"

# এখানে ইচ্ছাকৃতভাবে বাগ ঢোকানো হলো
sed -i 's/return a + b/return a - b/' calc.py
git add calc.py && git commit -m "c4: refactor add (accidentally broke it)"

echo "# comment c5" >> calc.py && git add calc.py && git commit -m "c5: another unrelated comment"
echo "# comment c6" >> calc.py && git add calc.py && git commit -m "c6: final comment"

ধাপ ১ — test script বানানো

cat > test-script.sh << 'EOF'
#!/bin/bash
python3 -m pytest test_calc.py -q
exit $?
EOF
chmod +x test-script.sh

ধাপ ২ — bisect run চালানো

git bisect start
git bisect bad HEAD
git bisect good c0-commit-hash   # প্রথম commit-এর hash বসান (git log --oneline দিয়ে বের করুন)
git bisect run ./test-script.sh

প্রত্যাশিত আউটপুট

running ./test-script.sh
...
c4-commit-hash is the first bad commit
commit c4-commit-hash
    c4: refactor add (accidentally broke it)

যা লক্ষ্য করবেন

মোট ৭টা commit-এর মধ্যে bisect মাত্র ৩টা চেক করেই bug commit খুঁজে বের করেছে (log₂(7) ≈ 3) — linear search করলে গড়ে ৩-৪টা লাগত, কিন্তু ১০০০ commit হলে এই পার্থক্য বিশাল হয়ে যেত। শেষে git bisect reset চালাতে ভুলবেন না।

প্র.১ — git bisect কেন O(log n) সময়ে bug-introducing commit খুঁজে পায়, linear search-এ O(n) কেন লাগবে? উত্তর: bisect প্রতিটা ধাপে সার্চ স্পেস অর্ধেক করে ফেলে (একটা মাঝখানের commit টেস্ট করে good/bad অনুযায়ী বাম বা ডান অর্ধেক বাদ দেয়) — এটা ক্লাসিক বাইনারি সার্চ অ্যালগরিদম। Linear search প্রতিটা commit একে একে চেক করে, তাই গড়ে n/2 চেক লাগে।

প্র.২ — git bisect কাজ করার জন্য কোন পূর্বশর্ত (assumption) প্রয়োজন? উত্তর: Monotonicity — bug একবার ঢোকার পর history-তে একটা single boundary তৈরি করে, বারবার আসা-যাওয়া করে না। flaky bug বা bug একবার ফিক্স হয়ে আবার ফিরে এলে (non-monotonic) bisect ভুল ফলাফল দিতে পারে।

প্র.৩ — git bisect skip কখন ব্যবহার করবেন? উত্তর: যখন মাঝপথের একটা নির্দিষ্ট commit টেস্ট করাই সম্ভব না — যেমন সেই commit-এ কোড অসম্পর্কিত কারণে কম্পাইল হয় না, বা কোনো dependency তখন ভাঙা ছিল। এটা সেই commit বাদ দিয়ে bisect-কে পাশের একটা commit-এ চেষ্টা করতে বলে।

প্র.৪ — git bisect run স্ক্রিপ্টের exit code-এর অর্থ কী? উত্তর: 0 মানে good (bug নেই), নন-জিরো (১২৫ বাদে) মানে bad (bug আছে), আর 125 মানে এই commit টেস্ট করা সম্ভব না (skip)। bisect run স্ক্রিপ্ট নিজে চালিয়ে exit code দেখে স্বয়ংক্রিয়ভাবে good/bad/skip সিদ্ধান্ত নেয়।

প্র.৫ — bisect সেশন চলাকালীন repo কোন অবস্থায় থাকে, আর কাজ শেষে কী করা জরুরি? উত্তর: detached HEAD অবস্থায় থাকে, কারণ bisect একের পর এক নির্দিষ্ট commit-এ checkout করে। কাজ শেষে git bisect reset চালানো জরুরি — এটা bisect সেশন বন্ধ করে আসল branch-এ ফিরিয়ে আনে।

প্র.৬ — git bisect run-এর টেস্ট স্ক্রিপ্ট কেন deterministic হওয়া জরুরি? উত্তর: bisect স্ক্রিপ্টের exit code-এর ওপর সম্পূর্ণ নির্ভর করে সিদ্ধান্ত নেয় — স্ক্রিপ্ট যদি নন-deterministic হয় (flaky test) বা সাইড-ইফেক্ট রেখে যায় (যেমন একটা পুরনো commit-এ চালানোর ফলে database state নষ্ট করে), bisect ভুল ফলাফল দিতে পারে বা পুরো সেশন অবিশ্বাস্য হয়ে যেতে পারে।

• bisect মাঝপথে থামিয়ে অন্য কাজ করলেও রাজ্য হারায় না — .git/BISECT_LOG আর refs/bisect/*-এ প্রগ্রেস সেভ থাকে, git bisect log দিয়ে এখন পর্যন্ত কী কী good/bad মার্ক করা হয়েছে তা দেখা যায়, এমনকি আরেকটা টার্মিনাল সেশন থেকেও।
• git bisect start <bad> <good> — আর্গুমেন্টের ক্রম উল্টালে ভুল ফলাফল আসবে — প্রথমে bad, তারপর good, এই ক্রম মেনে চলা জরুরি; উল্টো দিলে Git confusing error দেবে বা ভুল দিকে সার্চ করবে।
• build/dependency পরিবর্তন হওয়া পুরনো commit-এ bisect চালালে false positive আসতে পারে — যদি পুরনো commit-এ একটা dependency ভিন্ন ভার্সনের ছিল যা এখন আর নেই, টেস্ট ব্যর্থ হবে bug-এর কারণে না, পরিবেশগত অসামঞ্জস্যের কারণে — git bisect skip দিয়ে এই commit বাদ দেওয়া উচিত, ভুল commit-কে "bad" বলা ঠিক না।
• git bisect run স্ক্রিপ্টে git commit/git checkout জাতীয় কমান্ড রাখা বিপজ্জনক — bisect নিজেই checkout ম্যানেজ করে; স্ক্রিপ্টের ভেতর থেকে repo state পরিবর্তন করলে bisect-এর নিজস্ব ট্র্যাকিং এলোমেলো হয়ে যেতে পারে।

একটা commit history সময়ের সাথে সামনে এগোতেই থাকে, কিন্তু কখনো কখনো একটা নির্দিষ্ট মুহূর্তকে স্থায়ীভাবে চিহ্নিত করে রাখা দরকার — "এই commit-টাই আমাদের v2.0.0 রিলিজ"। branch দিয়ে এটা করা যায় না ভালোভাবে, কারণ branch pointer নড়তে থাকে। এই কাজের জন্য Git-এর tag — একটা স্থায়ী, (সাধারণত) অপরিবর্তনীয় রেফারেন্স। এই মডিউলে lightweight বনাম annotated tag-এর ভেতরের পার্থক্য, signed tag, আর SemVer কনভেনশন কভার হবে।

সমস্যাটা কী

একটা branch pointer প্রতিটা নতুন commit-এর সাথে এগিয়ে যায় — main আজকের commit-এ পয়েন্ট করছে, কালকের নতুন commit এলে সেটাতেই সরে যাবে। কিন্তু "v2.0.0 রিলিজ ঠিক কোন commit ছিল" — এই তথ্য কখনো বদলানো উচিত না। branch দিয়ে এই স্থায়িত্ব নিশ্চিত করা যায় না।

Tag-এর সমাধান

একটা tag একটা নির্দিষ্ট commit-এ স্থায়ীভাবে আটকে থাকা একটা নাম — এটা branch-এর মতো নতুন commit-এর সাথে এগোয় না। একবার v2.0.0 ট্যাগ একটা commit-এ বসিয়ে দিলে, সেই নাম চিরকাল সেই একই commit নির্দেশ করবে (যদি না ইচ্ছাকৃতভাবে ট্যাগ মুছে আবার তৈরি করা হয়)।

রিয়েল-লাইফ উদাহরণ

git tag v2.0.0
git push origin v2.0.0

এখন যে কেউ এই repo clone করলে git checkout v2.0.0 দিয়ে ঠিক সেই মুহূর্তের কোডে ফিরে যেতে পারবে — production-এ কোন কোড চলছিল তা পুনরুৎপাদন করার জন্য এটাই standard পদ্ধতি। একটা incident-এর সময় "production-এ কোন version চলছে" জানা থাকলে সরাসরি সেই tag checkout করে সমস্যা reproduce করা যায়।

Branch বনাম Tag — এক টেবিলে

দুই প্রকার — সংক্ষিপ্ত প্রিভিউ

Git-এ দুই ধরনের tag আছে — lightweight (শুধু একটা pointer) আর annotated (নিজেই একটা পূর্ণাঙ্গ object, author/date/message সহ) — পরের লিফে ভেতরের পার্থক্য বিস্তারিত।

Lightweight Tag — শুধু একটা ref

git tag v1.0.0-lw

এটা internally .git/refs/tags/v1.0.0-lw-এ শুধু একটা commit hash লিখে রাখে — অবিকল একটা branch pointer-এর মতো, শুধু এটা নড়ে না। এর নিজস্ব কোনো metadata (কে তৈরি করেছে, কবে, কেন) নেই — সরাসরি সেই commit-এর author/date/message-ই দেখা যাবে।

Annotated Tag — একটা সম্পূর্ণ Git Object

git tag -a v1.0.0 -m "First stable release"

এটা Git-এর object database-এ (Phase 1-এর object model মনে করুন) একটা সম্পূর্ণ নতুন tag object তৈরি করে — যার নিজস্ব SHA-1/SHA-256 hash, tagger name/email, tag date, আর tag message আছে। এই tag object-টা তারপর সেই নির্দিষ্ট commit-কে পয়েন্ট করে। অর্থাৎ refs/tags/v1.0.0 আসলে tag object-কে পয়েন্ট করছে, tag object commit-কে পয়েন্ট করছে — একটা extra ইনডিরেকশন লেয়ার।

git cat-file -p v1.0.0

object a1b2c3d4e5f6...
type commit
tag v1.0.0
tagger Rakib Hasan <rakib@example.com> 1755781200 +0600

First stable release

পার্থক্য এক টেবিলে

কেন annotated tag প্রেফার করা হয়

release marking-এর মতো গুরুত্বপূর্ণ কাজে annotated tag-ই standard practice — কারণ এটা কে, কবে, কেন ট্যাগ করেছে তার একটা স্থায়ী রেকর্ড রাখে, আর signing সাপোর্ট করে (পরের লিফে)। Git নিজেও ডিফল্টে git tag -a না দিয়ে শুধু -m দিলেও annotated tag বানায়, কিন্তু -m ছাড়া git tag <name> দিলে lightweight হয়ে যায় — এই সূক্ষ্ম পার্থক্যটা নতুনরা প্রায়ই মিস করেন।

ট্যাগ মোছা

git tag -d v1.0.0-beta

শুধু local ট্যাগ মোছে — remote-এ push করা থাকলে সেটা আলাদাভাবে মুছতে হবে (পরের লিফে)।

ট্যাগ লিস্ট করা, গ্লব প্যাটার্ন দিয়ে ফিল্টার

git tag -l                  # সব ট্যাগ
git tag -l "v1.*"           # শুধু v1.x সিরিজ
git tag -l "*-beta"         # শুধু beta ট্যাগ
git tag -l --sort=-v:refname  # semantic version অনুযায়ী descending sort

গ্লব প্যাটার্ন বড় প্রজেক্টে (শত শত tag) নির্দিষ্ট রিলিজ সিরিজ খুঁজতে অপরিহার্য — যেমন সব v2.* রিলিজ একসাথে দেখা।

পুরনো commit-এ ট্যাগ দেওয়া

ট্যাগ সবসময় বর্তমান HEAD-এ দিতে হবে এমন না — যেকোনো পুরনো commit-এও দেওয়া যায়, hash উল্লেখ করে:

git log --oneline
# e4f5g6h fix critical bug
# a1b2c3d add feature X (এটাই ছিল সেই সময়ের রিলিজ পয়েন্ট, ভুলে ট্যাগ করা হয়নি)

git tag -a v1.1 a1b2c3d -m "Retroactively tagging v1.1 release point"

রিয়েল-লাইফ সিনারিও

একটা টিম মনে করে তারা v2.0.0 ট্যাগ দিতে ভুলে গেছে, কিন্তু জানে ঠিক কোন commit থেকে সেই রিলিজ deploy হয়েছিল (deployment log থেকে hash পাওয়া গেছে)। git tag -a v2.0.0 <that-hash> -m "..." দিয়ে retroactively সঠিক জায়গায় ট্যাগ বসানো যায় — HEAD-এ ভুল জায়গায় ট্যাগ দিতে হয় না।

ওভাররাইট প্রতিরোধ

git tag v1.0.0
# fatal: tag 'v1.0.0' already exists

বিদ্যমান ট্যাগ নাম আবার তৈরি করতে গেলে Git error দেয় — ইচ্ছাকৃতভাবে ওভাররাইট করতে -f/--force লাগবে, যেটা সতর্কতার সাথে ব্যবহার করা উচিত (কারণ কেউ আগেই সেই ট্যাগ fetch করে থাকলে তার local কপি stale হয়ে যাবে)।

Signed Tag কী

git tag -s v2.0.0 -m "Signed release v2.0.0"

এটা annotated tag-এরই একটা সম্প্রসারণ — tag object-এ tagger-এর GPG (বা SSH key-based) স্বাক্ষর যোগ হয়। এটা প্রমাণ করে যে ট্যাগটা সত্যিই সেই ব্যক্তি তৈরি করেছেন যার কাছে সংশ্লিষ্ট প্রাইভেট key আছে — নাম স্পুফ করা যায় না।

কেন এটা গুরুত্বপূর্ণ (সংক্ষেপে — বিস্তারিত Security ফেজে)

ওপেন সোর্স প্রজেক্টে বা সাপ্লাই-চেইন-সংবেদনশীল সফটওয়্যারে, একটা release tag আসলেই "official maintainer" থেকে এসেছে তা যাচাই করা জরুরি — কেউ যদি repo-তে write access পেয়ে যায় (compromised account), signed tag ছাড়া সে সহজেই একটা ভুয়া "official release" ট্যাগ বসিয়ে দিতে পারত।

যাচাই করা

git verify-tag v2.0.0

gpg: Signature made ...
gpg: Good signature from "Rakib Hasan <rakib@example.com>"

git verify-tag কমান্ড tag object-এর স্বাক্ষর যাচাই করে — GPG public key ring-এ সংশ্লিষ্ট public key থাকতে হবে যাচাই সফল হতে।

রিয়েল-লাইফ প্রেক্ষাপট

Linux kernel-এর মতো বড় ওপেন সোর্স প্রজেক্টে প্রতিটা রিলিজ tag Linus Torvalds বা তার মনোনীত maintainer-দের GPG key দিয়ে signed — কেউ যদি একটা compromised mirror থেকে কোড টানে, signed tag verify করলে বোঝা যাবে সেটা আসল maintainer থেকেই এসেছে কিনা। এই বিস্তারিত মেকানিজম, key management, আর CI-তে automatic verification — এসব Phase-এর Security মডিউলে গভীরে আলোচনা হবে।

এখনকার জন্য যথেষ্ট মানসিক মডেল

Signed tag = annotated tag + cryptographic প্রমাণ "এটা আমিই বানিয়েছি"।

ট্যাগ push করা — ডিফল্টে হয় না

গুরুত্বপূর্ণ: git push সাধারণ ফর্মে (কোনো ফ্ল্যাগ ছাড়া) tag push করে না — এটা ইচ্ছাকৃতভাবে আলাদা করে রাখা হয়েছে যাতে ব্যক্তিগত/সাময়িক tag ভুলবশত সবার কাছে চলে না যায়।

git push origin v2.0.0        # একটা নির্দিষ্ট tag push
git push origin --tags        # সব local tag push (bulk)

--follow-tags — একটা মাঝামাঝি বিকল্প

git push --follow-tags

এটা branch commit push করার সাথে সাথে শুধু সেইসব annotated tag-ও push করে যেগুলো push হতে যাওয়া commit-গুলোর মধ্যে reachable। lightweight tag push করে না, আর অপ্রাসঙ্গিক পুরনো tag-ও push করে না — --tags (সব bulk push) আর কিছুই push না করা, এই দুইয়ের মাঝামাঝি একটা নিরাপদ ডিফল্ট।

git config --global push.followTags true   # স্থায়ীভাবে ডিফল্ট করে রাখা

Remote থেকে tag মোছা

git push origin --delete v1.0.0-beta

# বিকল্প সিনট্যাক্স (refspec-based, কম common)
git push origin :refs/tags/v1.0.0-beta

মনে রাখবেন — remote থেকে tag মোছা মানে শুধু remote-এর refs/tags/-এ entry মোছা, যারা আগেই fetch করে নিয়েছে তাদের local কপিতে এখনো থেকে যাবে যতক্ষণ না তারাও নিজেরা git tag -d চালায়।

রিয়েল-লাইফ ওয়ার্কফ্লো

# একটা রিলিজ তৈরি ও প্রকাশ করা
git tag -a v3.0.0 -m "Release v3.0.0: notification engine rewrite"
git push origin v3.0.0

# ভুল ট্যাগ সংশোধন (ভুল commit-এ দিয়ে ফেলেছিলেন)
git tag -d v3.0.0
git push origin --delete v3.0.0
git tag -a v3.0.0 <correct-hash> -m "Release v3.0.0: notification engine rewrite"
git push origin v3.0.0

SemVer ফরম্যাট

Semantic Versioning (MAJOR.MINOR.PATCH, যেমন v2.4.1) একটা সর্বজনীন কনভেনশন যা ভার্সন নম্বর দিয়েই বলে দেয় পরিবর্তনটা কতটা "বিপজ্জনক":

কেন এই কনভেনশন গুরুত্বপূর্ণ

একটা লাইব্রেরির user শুধু ভার্সন নম্বর দেখেই সিদ্ধান্ত নিতে পারে upgrade নিরাপদ কিনা — v2.4.0 থেকে v2.4.1-এ upgrade করলে কোড ভাঙার ঝুঁকি প্রায় নেই (শুধু bugfix), কিন্তু v1.x থেকে v2.0.0-এ upgrade করার আগে changelog পড়া উচিত (breaking change সম্ভাবনা)। dependency manager (npm, pip) SemVer রেঞ্জ (^2.4.0, ~2.4.0) ব্যবহার করে স্বয়ংক্রিয়ভাবে "নিরাপদ" আপডেট নির্ধারণ করে।

Git tagging-এ প্রয়োগ

git tag -a v2.4.1 -m "Fix null pointer in notification retry logic"
git tag -a v2.5.0 -m "Add support for SMS notifications"
git tag -a v3.0.0 -m "BREAKING: remove legacy notification API"

v prefix (যেমন v2.4.1 বনাম 2.4.1) দুটোই common, কিন্তু একটা repo-তে সামঞ্জস্যপূর্ণ থাকা উচিত — নাহলে git describe, sort, বা tooling বিভ্রান্ত হতে পারে।

Pre-release ট্যাগ

git tag -a v3.0.0-rc.1 -m "Release candidate 1 for v3.0.0"
git tag -a v3.0.0-beta.2 -m "Beta 2"

SemVer একটা optional pre-release suffix (-rc.1, -beta.2, -alpha) সাপোর্ট করে যা precedence-এ সংশ্লিষ্ট stable ভার্সনের আগে আসে (v3.0.0-rc.1 < v3.0.0) — dependency resolver এগুলোকে সাধারণত ডিফল্টে বাদ দেয় যতক্ষণ না স্পষ্টভাবে চাওয়া হয়।

রিয়েল-লাইফ ইন্টিগ্রেশন

CI/CD পাইপলাইনে একটা নতুন SemVer tag push হওয়া প্রায়ই একটা স্বয়ংক্রিয় release trigger — GitHub Actions on: push: tags: ['v*.*.*'] দিয়ে ট্যাগ push detect করে automatic build, changelog generation, আর npm/PyPI publish চালায়।

লক্ষ্য

দুই ধরনের ট্যাগ তৈরি করে internal পার্থক্য দেখা, পুরনো commit-এ ট্যাগ দেওয়া, এবং push/delete cycle সম্পূর্ণ করা।

সেটআপ

mkdir -p ~/git-lab7 && cd ~/git-lab7 && git init --initial-branch=main

git commit --allow-empty -m "c0: init"
git commit --allow-empty -m "c1: feature A"
git commit --allow-empty -m "c2: feature B"
git commit --allow-empty -m "c3: bugfix"

ধাপ ১ — দুই ধরনের ট্যাগ তৈরি ও তুলনা

git tag v1.0.0-lw               # lightweight
git tag -a v1.0.0 -m "First release"   # annotated

git cat-file -t v1.0.0-lw   # commit
git cat-file -t v1.0.0      # tag  <- ভিন্ন object type!

git show v1.0.0-lw   # সরাসরি commit info
git show v1.0.0       # প্রথমে tag object info (tagger/date/message), তারপর commit info

ধাপ ২ — পুরনো commit-এ retroactive tag

git log --oneline
# ধরুন c1 (feature A)-এর hash হলো xxxxx

git tag -a v0.9.0 xxxxx -m "Retroactive tag for feature A milestone"
git show v0.9.0

ধাপ ৩ — remote সিমুলেট করে push/delete

git init --bare ~/git-lab7-remote.git
git remote add origin ~/git-lab7-remote.git
git push origin main

git push origin v1.0.0          # শুধু annotated tag push
git push origin --tags          # সব ট্যাগ (lightweight-সহ) push

# ভুল করে দেওয়া ট্যাগ মোছা
git push origin --delete v1.0.0-lw
git tag -d v1.0.0-lw

চ্যালেঞ্জ

git push --follow-tags টেস্ট করুন — নতুন commit করে একটা নতুন annotated tag বসান কিন্তু --tags না দিয়ে শুধু git push --follow-tags চালান, দেখুন commit-এর সাথে সেই tag-ও push হয়ে যায় কিনা।

প্র.১ — lightweight আর annotated tag-এর ভেতরের পার্থক্য কী? উত্তর: lightweight tag শুধু refs/tags/-এ একটা commit hash-এর pointer — কোনো নতুন object তৈরি হয় না। annotated tag Git-এর object database-এ একটা সম্পূর্ণ নতুন tag object তৈরি করে যাতে tagger, date, message থাকে, এবং সেই object commit-কে পয়েন্ট করে — একটা এক্সট্রা ইনডিরেকশন লেয়ার।

প্র.২ — git push করলে ট্যাগ push হয় না কেন — এটা কি একটা bug? উত্তর: এটা ইচ্ছাকৃত ডিজাইন সিদ্ধান্ত — ট্যাগ প্রায়ই ব্যক্তিগত বা সাময়িক মার্কার হতে পারে, তাই ডিফল্টে push না করে ব্যবহারকারীকে explicit ভাবে git push origin <tag> বা --tags বলতে হয়, যাতে অনিচ্ছাকৃতভাবে ট্যাগ শেয়ার না হয়ে যায়।

প্র.৩ — git push --tags আর git push --follow-tags-এর পার্থক্য কী? উত্তর: --tags সব local tag (lightweight এবং annotated, সব — প্রাসঙ্গিক-অপ্রাসঙ্গিক নির্বিশেষে) push করে। --follow-tags শুধু সেইসব annotated tag push করে যেগুলো push হওয়া commit-গুলোর মধ্যে reachable — একটা নিরাপদ, বেশি নির্বাচনী বিকল্প।

প্র.৪ — signed tag (-s) কেন annotated tag-এর ওপর ভিত্তি করে তৈরি, lightweight-এর ওপর না? উত্তর: signing-এর জন্য একটা object দরকার যাতে cryptographic signature যোগ করা যায় (tagger info, date, message-সহ)। lightweight tag-এর নিজস্ব কোনো object নেই — শুধু একটা pointer, তাই তাতে signature যোগ করার কোনো জায়গা নেই।

প্র.৫ — SemVer-এ v2.4.0 থেকে v3.0.0-এ আপগ্রেড করার আগে একজন ডেভেলপারের কী বিশেষভাবে করা উচিত? উত্তর: changelog/release notes পড়া, কারণ MAJOR ভার্সন বৃদ্ধি মানে breaking change — পুরনো API বা behavior-এর সাথে backward compatibility নেই। MINOR (v2.4→v2.5) বা PATCH (v2.4.0→v2.4.1) upgrade সাধারণত নিরাপদ, কিন্তু MAJOR না।

প্র.৬ — একটা ভুল commit-এ ট্যাগ দিয়ে ফেলেছেন এবং সেটা push-ও করে ফেলেছেন — সংশোধনের সঠিক ধাপ কী? উত্তর: প্রথমে local ট্যাগ মুছুন (git tag -d v1.0.0), তারপর remote থেকে মুছুন (git push origin --delete v1.0.0), তারপর সঠিক commit hash-এ নতুন করে ট্যাগ তৈরি করে push করুন। মনে রাখতে হবে যারা আগেই fetch করেছে তাদের local কপি এখনো পুরনো থেকে যাবে যতক্ষণ না তারাও নিজে থেকে আপডেট করে।

• git tag <name> (কোনো -a/-m ছাড়া) lightweight tag তৈরি করে, কিন্তু git tag <name> -m "..." আসলে annotated tag তৈরি করে — শুধু -m উপস্থিতিই যথেষ্ট, -a ছাড়াই। এই সূক্ষ্ম নিয়ম প্রায়ই নতুনদের বিভ্রান্ত করে যারা মনে করেন -a ছাড়া কখনো annotated হবে না।
• git describe ছাড়া কোনো tag ছাড়া history-তে fatal error দেয়, কিন্তু annotated এবং lightweight উভয় ধরনের tag থাকলে git describe ডিফল্টে শুধু annotated tag খুঁজে বের করে — lightweight tag থাকলেও উপেক্ষা করে, যদি না --tags ফ্ল্যাগ যোগ করা হয় (git describe --tags)।
• দুইটা ভিন্ন commit-এ একই নামে ট্যাগ থাকা যায় না, কিন্তু একই commit-এ একাধিক ট্যাগ থাকতে পারে (যেমন v2.0.0 আর stable দুটোই একই commit পয়েন্ট করতে পারে) — এটা confusion তৈরি করতে পারে যদি টিম না জানে কোন ট্যাগ "primary"।
• git tag -f দিয়ে বিদ্যমান ট্যাগ force-overwrite করলে remote-এ push না করা পর্যন্ত অন্য কেউ জানবে না — কিন্তু push করার সময় git push origin <tag> সাধারণত reject হবে (ট্যাগ ইতিমধ্যে remote-এ আছে) যদি না --force যোগ করা হয় push কমান্ডেও, যেটা অত্যন্ত সতর্কতার সাথে করা উচিত কারণ যারা আগে fetch করেছে তাদের সাথে ইতিহাস বিচ্যুত হয়ে যাবে।

কাজের মাঝপথে হঠাৎ context বদলাতে হয় প্রায় সবার — একটা জরুরি hotfix, একটা মিটিং-এ আগে দেখাতে হবে এমন কিছু, বা শুধু branch বদলে অন্য কিছু চেক করতে হবে — কিন্তু working directory তখন অগোছালো, commit করার মতো প্রস্তুত না। git stash এই সমস্যার সমাধান — commit না করেই কাজ সাময়িকভাবে "সরিয়ে রাখা"। এই মডিউলে stash-এর পুরো কমান্ড ফ্যামিলি, internal মেকানিজম (এটা আসলে একটা special commit stack), আর partial stash-এর সূক্ষ্মতা কভার হবে।

সমস্যাটা কী

আপনি একটা বড় ফিচার নিয়ে কাজ করছেন — feature/notification-batching branch-এ ৫টা ফাইল edit করা, কিন্তু কোনোটাই commit করার মতো সম্পূর্ণ না (মাঝপথে, কম্পাইলও হয়তো হবে না)। ঠিক তখনই একটা জরুরি production bug রিপোর্ট এলো, যেটা এখনই main-এ গিয়ে fix করে deploy করতে হবে।

সরাসরি branch বদলানোর সমস্যা

git checkout main
# error: Your local changes to the following files would be overwritten by checkout

Git branch বদলাতে দেবে না যদি uncommitted পরিবর্তন conflict করে বর্তমান আর target branch-এর মধ্যে। commit করাও সমাধান না — অসম্পূর্ণ, ভাঙা কোড history-তে যোগ করা ভালো প্র্যাকটিস না।

git stash-এর সমাধান

git stash push -m "wip: notification batching, mid-refactor"
git checkout main
git checkout -b hotfix/null-check
# ... hotfix করে merge/push ...
git checkout feature/notification-batching
git stash pop

stash uncommitted পরিবর্তন (staged + unstaged) সাময়িকভাবে একটা আলাদা জায়গায় সরিয়ে working directory-কে HEAD-এর মতো পরিষ্কার করে দেয় — এখন নির্দ্বিধায় branch বদলানো যায়। কাজ শেষে stash pop দিয়ে ঠিক সেই অবস্থায় ফিরে আসা যায়।

কেন এটা কমিটের চেয়ে ভালো এখানে

stash কোনো permanent history তৈরি করে না (commit history-তে দেখা যায় না) — এটা একটা সাময়িক, লোকাল-only "shelf"। hotfix শেষে ফিরে এসে আবার ঠিক যেখানে ছিলেন সেখান থেকে কাজ চালিয়ে যাওয়া যায়, কোনো অসম্পূর্ণ/ভাঙা commit history-তে না রেখেই।

মূল কমান্ড রেফারেন্স

apply বনাম pop

git stash apply stash@{0}   # প্রয়োগ হবে, কিন্তু stash@{0} তালিকায় থেকে যাবে
git stash pop stash@{0}     # প্রয়োগ হবে এবং stash@{0} মুছে যাবে

apply উপকারী যখন একই stash একাধিক branch-এ প্রয়োগ করতে চান (যেমন দুইটা ভিন্ন branch-এ একই সাময়িক পরিবর্তন টেস্ট করা) — pop করলে প্রথমবার প্রয়োগের পরই stash মুছে যাবে, দ্বিতীয়বার আর সম্ভব না।

উদাহরণ ফ্লো

git stash push -m "experiment: caching layer"
git stash list
# stash@{0}: On feature/cache: experiment: caching layer

git stash show -p stash@{0}
# পূর্ণ diff দেখাবে

git stash pop
# working directory-তে প্রয়োগ হলো, stash list থেকে মুছে গেলো

clear নিয়ে সতর্কতা

git stash clear সব stash অপ্রত্যাবর্তনযোগ্যভাবে মুছে দেয় — কোনো নিশ্চিতকরণ প্রম্পট ছাড়াই। ভুলে চালালে সব সাময়িক সংরক্ষিত কাজ হারিয়ে যেতে পারে (যদিও git fsck --unreachable দিয়ে কিছু ক্ষেত্রে reflog/dangling commit থেকে উদ্ধারের চেষ্টা করা যায় — নিশ্চয়তা নেই)।

Stash আসলে কী — একটা বিশেষ commit-এর স্ট্যাক

git stash internally uncommitted পরিবর্তনগুলো দিয়ে (আসলে দুই বা তিনটা) বিশেষ commit object তৈরি করে — একটা working-directory-state commit, আরেকটা index (staged) state commit, এবং সেগুলোর একটা "stash commit" যার parent হলো তৈরি হওয়ার সময়কার HEAD। এই stash commit-টা refs/stash-এ পয়েন্ট করা থাকে।

git cat-file -p refs/stash

tree ...
parent a1b2c3d4...      <- HEAD যখন stash করা হয়েছিল
parent e5f6g7h8...      <- index (staged) state
author Rakib Hasan ...

On feature/cache: experiment: caching layer

reflog-এর মতো একটা স্ট্যাক

একাধিকবার git stash push চালালে প্রতিবার নতুন stash commit তৈরি হয়, আর পুরনো refs/stash-এর মান refs/stash-এর reflog-এ (.git/logs/refs/stash) সরে যায় — ঠিক যেমন সাধারণ branch-এর reflog পুরনো HEAD position ট্র্যাক করে (Phase 3-এ দেখা reflog মেকানিজমের সরাসরি পুনঃব্যবহার)। stash@{0} মানে "সবচেয়ে সাম্প্রতিক stash", stash@{1} তার আগেরটা, ইত্যাদি — এই ইনডেক্সিং সরাসরি reflog entry নম্বর থেকে আসে।

git stash list
# stash@{0}: On feature/cache: latest stash
# stash@{1}: On main: older stash
# stash@{2}: On feature/x: even older stash

কেন এই মডেল গুরুত্বপূর্ণ বোঝা

যেহেতু stash আসলে commit object-ই (শুধু কোনো branch তাদের সরাসরি reference করে না), git show stash@{0} বা git log -p stash@{0} দিয়ে সরাসরি ইন্সপেক্ট করা যায় — এটা কোনো ম্যাজিক আলাদা storage না, Git-এর একই object model-এর একটা প্রয়োগ।

practical ইমপ্লিকেশন

git gc (garbage collection) সাধারণত dangling/unreachable object মুছে ফেলে, কিন্তু refs/stash আর তার reflog যতক্ষণ বিদ্যমান, ততক্ষণ stash commit-গুলো reachable থাকে, তাই সাধারণ gc-তে হারায় না — কিন্তু git stash clear চালালে সেই reference-ই মুছে যায়, তখন commit-গুলো dangling হয়ে যায় এবং পরবর্তী gc-তে মুছে যাওয়ার ঝুঁকিতে পড়ে।

সমস্যাটা কী

মাঝে মাঝে working directory-র সব পরিবর্তন stash করতে চান না — শুধু নির্দিষ্ট কিছু ফাইল বা এমনকি একটা ফাইলের নির্দিষ্ট অংশ। ডিফল্ট git stash push সব uncommitted পরিবর্তন একসাথে সরিয়ে নেয়, যেটা সবসময় কাম্য না।

নির্দিষ্ট path stash করা

git stash push -- src/notifications/retry.py

এটা শুধু retry.py-এর পরিবর্তন stash করবে, বাকি সব ফাইলের পরিবর্তন working directory-তে অক্ষত থেকে যাবে। একাধিক path দেওয়া যায়:

git stash push -- src/notifications/retry.py src/notifications/config.py

-p/--patch দিয়ে হাংক-লেভেল নির্বাচন

git stash push -p

এটা git add -p-এর মতোই ইন্টারেক্টিভ মোডে প্রতিটা diff hunk দেখিয়ে জিজ্ঞেস করে stash করবেন কিনা (y/n/s split ইত্যাদি) — একটা ফাইলের ভেতরেও শুধু নির্দিষ্ট অংশ stash করা যায়, বাকি অংশ working directory-তে থেকে যায়।

রিয়েল-লাইফ উদাহরণ

আপনি একটা ফাইলে দুইটা ভিন্ন, অসম্পর্কিত পরিবর্তন করেছেন (একটা debug logging যোগ, আরেকটা আসল ফিচার লজিক) — debug logging অংশটুকু সাময়িকভাবে সরিয়ে রেখে বাকি অংশ কমিট করতে চান:

git stash push -p -m "temp: remove debug logging before commit"
# শুধু debug logging-সংক্রান্ত hunk-এ 'y' দিন, বাকিতে 'n'
git commit -am "add retry backoff logic"
git stash pop   # debug logging আবার ফিরিয়ে আনুন পরে দরকার হলে

সতর্কতা

-u/--include-untracked আর -a/--all (Module-এর overview-তে উল্লেখিত) partial path selection-এর সাথে কম্বাইন করা যায়, কিন্তু জটিল হয়ে উঠতে পারে — untracked নতুন ফাইল partial stash-এ অন্তর্ভুক্ত করতে চাইলে path স্পষ্টভাবে উল্লেখ করাই নিরাপদ।

সমস্যাটা কখন হয়

git stash pop মাঝে মাঝে conflict দেয় — যদি stash করার পর থেকে বর্তমান branch-এ এমন পরিবর্তন এসেছে যা stash-এর পরিবর্তনের সাথে সাংঘর্ষিক। এই অবস্থায় pop merge conflict marker রেখে যায়, যেটা resolve করতে হয় ঠিক normal merge conflict-এর মতোই — মাঝে মাঝে বিরক্তিকর, বিশেষ করে যদি stash পুরনো হয়ে গিয়ে থাকে branch অনেকদূর এগিয়ে যাওয়ায়।

git stash branch সমাধান

git stash branch new-feature-from-stash

এই একটা কমান্ড তিনটা কাজ করে:

1. stash যে commit-এ তৈরি হয়েছিল, সেই commit থেকে একটা নতুন branch তৈরি করে ও checkout করে।
2. সেই নতুন branch-এ stash apply করে।
3. সফল হলে stash drop করে দেয়।

কেন এটা conflict এড়ায়

যেহেতু নতুন branch তৈরি হচ্ছে ঠিক সেই commit থেকে যেখানে stash তৈরি হয়েছিল (বর্তমান branch-এর এগিয়ে যাওয়া history থেকে না), stash-এর পরিবর্তন প্রয়োগ করার সময় বর্তমান branch-এর পরবর্তী কোনো commit-এর সাথে সাংঘর্ষিক হওয়ার সুযোগই নেই — একদম "ক্লিন স্লেট"-এ প্রয়োগ হচ্ছে।

রিয়েল-লাইফ উদাহরণ

git stash list
# stash@{0}: On main: wip experimental caching (২ সপ্তাহ পুরনো!)

git stash branch experiment/caching stash@{0}
# main branch এখন অনেক এগিয়ে গেছে, সরাসরি pop করলে অনেক conflict হতো
# কিন্তু এই কমান্ড দিয়ে একটা পরিষ্কার নতুন branch-এ (পুরনো commit থেকে) stash প্রয়োগ হলো
# এখন প্রয়োজনে main-এর সাথে rebase/merge করে conflict resolve করা যাবে normal workflow-এ

কখন ব্যবহার করবেন

যখন একটা পুরনো stash pop করতে গিয়ে জটিল conflict আসছে, বা stash-এর কাজটা আসলে একটা পূর্ণাঙ্গ feature হিসেবে গড়ে তোলার যোগ্য মনে হচ্ছে — সরাসরি একটা branch-এ রূপান্তর করে সেখান থেকে normal development চালিয়ে যাওয়া অনেক পরিষ্কার সমাধান।

লক্ষ্য

একটা বাস্তব সিনারিও সিমুলেট করা — ফিচার কাজের মাঝপথে জরুরি hotfix, stash দিয়ে কাজ বাঁচিয়ে branch বদলানো, hotfix করে ফিরে এসে কাজ চালিয়ে যাওয়া।

সেটআপ

mkdir -p ~/git-lab8 && cd ~/git-lab8 && git init --initial-branch=main

echo "def send_notification(): pass" > notifier.py
git add notifier.py && git commit -m "initial notifier"

git checkout -b feature/batching

ধাপ ১ — অসম্পূর্ণ ফিচার কাজ (কমিট করার মতো প্রস্তুত না)

cat >> notifier.py << 'EOF'

def batch_notifications(items):
    # TODO: এখনো অসম্পূর্ণ, ভাঙা কোড
    for item in items
        pass
EOF

ধাপ ২ — জরুরি bug রিপোর্ট আসলো, main-এ যেতে হবে

git checkout main
# error: Your local changes to the following files would be overwritten by checkout

ধাপ ৩ — stash দিয়ে কাজ বাঁচানো

git stash push -m "wip: batching feature, incomplete for loop"
git checkout main

ধাপ ৪ — hotfix করা ও merge

git checkout -b hotfix/notifier-crash
sed -i 's/def send_notification(): pass/def send_notification():\n    print("sending")/' notifier.py
git add notifier.py
git commit -m "hotfix: fix notifier crash"
git checkout main
git merge --no-ff hotfix/notifier-crash -m "Merge hotfix/notifier-crash"
git branch -d hotfix/notifier-crash

ধাপ ৫ — ফিচার branch-এ ফিরে stash পুনরুদ্ধার

git checkout feature/batching
git stash list
git stash pop
cat notifier.py   # আগের অসম্পূর্ণ কাজ ফিরে এসেছে, সাথে hotfix-ও (rebase করলে) merge হতে পারে

চ্যালেঞ্জ

ধাপ ৩-এর আগে git stash push -p ব্যবহার করে দেখুন শুধু batch_notifications ফাংশনের অংশটুকু stash করা যায় কিনা, বাকি ফাইল অক্ষত রেখে।

প্র.১ — git stash internally ঠিক কী করে — কোথায় ডেটা সংরক্ষিত হয়? উত্তর: uncommitted পরিবর্তন (staged ও unstaged) দিয়ে বিশেষ commit object তৈরি হয় (working-tree state ও index state আলাদাভাবে), এবং একটা "stash commit" refs/stash-এ পয়েন্ট করে রাখা হয়। একাধিক stash refs/stash-এর reflog-এ স্ট্যাকের মতো সংরক্ষিত থাকে — stash@{0}, stash@{1} ইত্যাদি ইনডেক্স সেই reflog entry থেকেই আসে।

প্র.২ — git stash apply আর git stash pop-এর পার্থক্য কী, কখন apply prefer করবেন? উত্তর: pop প্রয়োগ করে stash list থেকে মুছে দেয়, apply প্রয়োগ করে কিন্তু stash list-এ রেখে দেয়। একই stash একাধিক branch-এ প্রয়োগ করতে চাইলে apply ব্যবহার করা উচিত, কারণ pop প্রথমবারই stash মুছে ফেলবে।

প্র.৩ — git stash push -- <path> আর git stash push -p-এর মধ্যে পার্থক্য কী? উত্তর: -- <path> নির্দিষ্ট ফাইল/ফাইলসমূহ পুরোপুরি stash করে, বাকি ফাইল অক্ষত থাকে। -p/--patch আরও সূক্ষ্ম — একটা ফাইলের ভেতরেও নির্দিষ্ট hunk/অংশ বেছে stash করতে দেয়, ইন্টারেক্টিভভাবে।

প্র.৪ — git stash branch <name> কেন সরাসরি git stash pop-এর চেয়ে নিরাপদ যখন stash অনেক পুরনো? উত্তর: git stash branch stash তৈরি হওয়ার সময়কার commit থেকে একটা নতুন branch তৈরি করে সেখানে stash প্রয়োগ করে — বর্তমান (এগিয়ে যাওয়া) branch-এর সাথে সরাসরি conflict হওয়ার সুযোগ নেই, কারণ প্রয়োগ হচ্ছে ঠিক সেই পুরনো commit-এর ওপর যেখান থেকে stash এসেছিল।

প্র.৫ — git stash clear চালানোর পর কি stash করা কাজ পুনরুদ্ধার করা সম্ভব? উত্তর: গ্যারান্টিসহ না — refs/stash মুছে যাওয়ার পর stash commit-গুলো dangling হয়ে যায়। git gc চালানোর আগে git fsck --unreachable/--dangling দিয়ে কিছু ক্ষেত্রে খুঁজে পাওয়া সম্ভব হতে পারে, কিন্তু নির্ভরযোগ্য উপায় না — তাই clear চালানোর আগে সতর্ক থাকা জরুরি।

প্র.৬ — stash কি টিমমেটদের সাথে শেয়ার করা যায় (push করা যায় remote-এ)? উত্তর: না, সরাসরি না। stash কোনো branch না, এটা শুধু local refs/stash-এ থাকে — এটা push করার কোনো native কমান্ড নেই। শেয়ার করতে চাইলে git stash show -p > patch.diff দিয়ে একটা patch ফাইল বানিয়ে পাঠানো যায়, বা git stash branch দিয়ে একটা আসল branch-এ রূপান্তর করে push করা যায়।

• git stash ডিফল্টে untracked (নতুন, কখনো add করা হয়নি) ফাইল stash করে না — শুধু tracked ফাইলের পরিবর্তন। নতুন ফাইল-সহ stash করতে -u/--include-untracked লাগবে, আর .gitignore-এ থাকা ফাইলও stash করতে -a/--all লাগবে (আরও agresive, সাধারণত -u যথেষ্ট)।
• git stash pop conflict দিলে এবং resolve করার পরও stash list থেকে entry মুছে যায় না স্বয়ংক্রিয়ভাবে — conflict হলে pop মাঝপথে থেমে যায়, resolve করার পর ম্যানুয়ালি git stash drop চালাতে হয় (Git নিশ্চিত করতে চায় না যে resolve সঠিকভাবে হয়েছে, তাই automatically drop করে না)।
• stash@{n} ইনডেক্স স্থির না — প্রতিটা নতুন stash push/pop/drop-এর পর সব ইনডেক্স শিফট হয় — stash@{2} আজ যা বোঝাচ্ছে, একটা নতুন stash push করার পর তা stash@{3} হয়ে যাবে। স্ক্রিপ্টে hardcoded stash@{n} রেফারেন্স রাখা বিপজ্জনক।
• একই ফাইলে stash করার সময় এবং pop করার সময়ের মাঝে যদি bare git stash (branch-independent) ভিন্ন branch-এ pop করা হয়, ফাইল স্ট্রাকচার সম্পূর্ণ ভিন্ন থাকলে conflict বা এমনকি ভুল জায়গায় ফাইল তৈরি হতে পারে — stash কোনো branch-aware সেফটি চেক করে না, ব্যবহারকারীর দায়িত্ব বুঝে প্রয়োগ করা কোন branch-এ করছেন।

এতদিন আমরা একটা সময়ে একটামাত্র working directory নিয়ে কাজ করেছি, আর একটামাত্র repository নিয়ে। বাস্তবের বড় প্রজেক্টে এই দুইটা ধারণাই ভেঙে যায়: একই সময়ে দুইটা branch-এ কাজ করা লাগে (একটায় feature, আরেকটায় জরুরি hotfix), একটা repository আরেকটা repository-কে dependency হিসেবে টেনে আনে (submodule/subtree), আর repository নিজেই এত বড় হয়ে যায় (মনোরেপো, গিগাবাইট গিগাবাইট asset) যে পুরোটা ক্লোন করাই অবাস্তব হয়ে দাঁড়ায়।

এই Phase-এ তিনটা মডিউল — Worktree (একই repo-র একাধিক working copy), Submodules/Subtrees (repo-র ভেতরে repo), আর বড় Repo/Monorepo টুলিং (shallow/partial clone, sparse-checkout, maintenance, Git LFS)। এগুলো হলো সেই টুলসেট যেটা একজন soloist ডেভেলপারকে একটা large-team, large-scale ইঞ্জিনিয়ারিং সংস্কৃতির জন্য প্রস্তুত করে।

একটা .git directory, কিন্তু একাধিক working directory — এটাই git worktree-র মূল প্রতিশ্রুতি। কভার হবে: worktree কীভাবে object database শেয়ার করে, add/list/remove/lock/unlock/prune কমান্ডগুলো, আর branch switch না করেই সমান্তরালভাবে একাধিক branch-এ কাজ করার বাস্তব সমস্যা সমাধান।

সমস্যাটা কী

স্বাভাবিক Git workflow-এ একটা repository ক্লোন করলে একটামাত্র working directory পাওয়া যায় — যে কোনো মুহূর্তে সেখানে একটামাত্র branch checked out থাকতে পারে। feature/payment branch-এ কাজ করার সময় হঠাৎ একটা production hotfix লিখতে হলে সাধারণত git stash করে main-এ checkout করতে হয় — কাজের মাঝখানে বাধা, আর ভুলে অসম্পূর্ণ stash রয়ে যাওয়ার ঝুঁকি।

git worktree এই সমস্যা সমাধান করে: একই .git object database শেয়ার করে একাধিক working directory তৈরি করা যায়, প্রতিটাতে আলাদা branch checked out থাকতে পারে — সম্পূর্ণ সমান্তরালে, কোনো stash/switch ছাড়াই।

মূল কমান্ড

git worktree add ../myrepo-hotfix hotfix/urgent-bug
git worktree list
git worktree remove ../myrepo-hotfix

রিয়েল-লাইফ উদাহরণ

আপনি feature/payment-gateway branch-এ অর্ধেক কাজ করা অবস্থায় Slack-এ জানানো হলো production-এ একটা critical bug আছে। Stash না করে:

git worktree add ../myrepo-hotfix main
cd ../myrepo-hotfix
git checkout -b hotfix/null-pointer
# ফিক্স করুন, কমিট করুন, push করুন
cd ../myrepo   # আগের feature কাজ ঠিক যেভাবে ছিল সেভাবেই আছে

দুইটা টার্মিনাল ট্যাব, দুইটা ফোল্ডার, একই repository — কোনো context-switch penalty নেই।

এক লাইনে

Worktree = একটা repo, একাধিক "physical" working copy, শেয়ার্ড history।

ভেতরে কী ঘটে

মূল worktree ক্লোন করার সময় .git একটা সাধারণ ডিরেক্টরি থাকে যেখানে objects, refs, HEAD, index — সব একসাথে থাকে। git worktree add চালালে Git একটা নতুন linked worktree তৈরি করে — নতুন ফোল্ডারে একটা .git ফাইল (ডিরেক্টরি না) থাকে যেটা মূল .git/worktrees/<name>/ ডিরেক্টরির দিকে পয়েন্ট করে:

$ cat ../myrepo-hotfix/.git
gitdir: /path/to/myrepo/.git/worktrees/myrepo-hotfix

কী শেয়ার্ড, কী আলাদা

যেহেতু objects শেয়ার্ড, একটা worktree-তে কমিট করা object সাথে সাথে অন্য worktree থেকেও দেখা যায় (git log)। কিন্তু একই branch দুইটা worktree-তে একসাথে checkout করা যায় না — Git এটা ব্লক করে দেয় ("already checked out" error), কারণ দুইটা আলাদা index থাকলেও branch pointer একটাই।

prune, lock, unlock

git worktree lock ../myrepo-hotfix --reason "external drive, may be offline"
git worktree unlock ../myrepo-hotfix
git worktree prune   # ম্যানুয়ালি ডিলিট হওয়া worktree ফোল্ডারের রেফারেন্স পরিষ্কার করে

prune দরকার হয় যখন worktree ফোল্ডার সরাসরি rm -rf দিয়ে মুছে ফেলা হয়েছে (সঠিক উপায় git worktree remove), কারণ Git-এর মেটাডেটায় তখনও সেটার রেকর্ড থেকে যায়।

git checkout/switch বনাম Worktree

Branch পাল্টানোর সাধারণ পদ্ধতি (git switch other-branch) সস্তা মনে হলেও বাস্তবে কয়েকটা ব্যয় আছে:

• Build/dependency cache invalidation — node_modules, .venv, compiled artifact আলাদা branch-এ ভিন্ন হতে পারে; switch করলে আবার rebuild/reinstall লাগতে পারে।
• অসম্পূর্ণ কাজ হারানোর ঝুঁকি — stash করা জিনিস ভুলে যাওয়া একটা সাধারণ ভুল।
• IDE state হারানো — খোলা ফাইল, breakpoint, running dev server — সব রিসেট হয়ে যায়।

Worktree দিয়ে প্রতিটা branch-এর একটা আলাদা ফিজিক্যাল ফোল্ডার থাকে বলে এই সব state স্বাধীনভাবে টিকে থাকে।

বাস্তব ব্যবহারের দৃশ্য

1. Hotfix বনাম feature — production bug ফিক্স করতে করতে feature branch untouched থাকে।
2. Code review — একজন সহকর্মীর PR local-এ চালিয়ে দেখতে চান, কিন্তু নিজের running dev server বন্ধ করতে চান না: git worktree add ../review-pr-42 origin/feature-x।
3. দীর্ঘ CI/build সময়ের বিরুদ্ধে সমান্তরাল কাজ — একটা worktree-তে ভারী build চলছে, আরেকটাতে normal কাজ চলছে।
4. Bisect করার সময় — git bisect চালানো worktree-তে ইতিহাস জুড়ে checkout হতে থাকে; আলাদা worktree-তে bisect চালালে মূল working directory অক্ষত থাকে।

ট্রেড-অফ

• ডিস্কে extra working-tree ফাইল থাকে (objects শেয়ার্ড বলে বড় সমস্যা না, কিন্তু build artifact প্রতিটাতে আলাদা)।
• কিছু টুল (পুরনো IDE, কিছু git GUI) worktree সম্পূর্ণভাবে বুঝে না — সবসময় প্রথম-শ্রেণীর সাপোর্ট থাকে না।

সম্পূর্ণ কমান্ড সেট

# নতুন worktree, নতুন branch সহ
git worktree add -b feature/new-ui ../myrepo-ui origin/main

# বিদ্যমান branch দিয়ে
git worktree add ../myrepo-hotfix hotfix/urgent

# detached HEAD-এ (কোনো branch বাইন্ড না করে, শুধু দেখার জন্য)
git worktree add --detach ../myrepo-inspect v2.3.0

# তালিকা দেখা
git worktree list
# /path/to/myrepo         abcd123 [main]
# /path/to/myrepo-hotfix  ef01234 [hotfix/urgent]

# মুছে ফেলা (working directory ও worktree metadata দুটোই সরায়)
git worktree remove ../myrepo-hotfix

# অসম্পূর্ণ পরিবর্তন থাকলেও জোর করে সরানো
git worktree remove --force ../myrepo-hotfix

# lock/unlock — external/removable media-তে worktree থাকলে prune থেকে সুরক্ষা
git worktree lock ../myrepo-usb --reason "USB drive"
git worktree unlock ../myrepo-usb

# ম্যানুয়ালি মুছে ফেলা ফোল্ডারের স্টেল metadata পরিষ্কার
git worktree prune -v

গুরুত্বপূর্ণ ফ্ল্যাগ

Bare repository-র সাথে worktree

কখনো কখনো মূল রিপোতে কোনো checkout না রেখে (git clone --bare) সব কাজ worktree দিয়ে করা হয় — এটা এমন টিমে জনপ্রিয় যেখানে "প্রতিটা branch একটা আলাদা ফোল্ডার" নীতি মানা হয়, root ফোল্ডারে কোনো active branch থাকে না, শুধু worktree-গুলোই আসল কাজের জায়গা।

লক্ষ্য

একটা repository-তে দুইটা worktree তৈরি করে দেখানো যে objects শেয়ার্ড কিন্তু working state স্বাধীন।

ধাপ

1. একটা টেস্ট repo বানান এবং কিছু কমিট দিন:

mkdir /tmp/wt-lab && cd /tmp/wt-lab && git init
echo "v1" > app.txt && git add . && git commit -m "init"

2. একটা feature branch তৈরি করুন এবং কিছু অসম্পূর্ণ (uncommitted) পরিবর্তন রেখে দিন:

git checkout -b feature/payment
echo "half-written payment code" >> app.txt

(এখানে কমিট করবেন না — এটাই আসল সমস্যা যা worktree সমাধান করে)

3. নতুন টার্মিনালে হটফিক্সের জন্য একটা worktree তৈরি করুন main থেকে:

git worktree add ../wt-lab-hotfix main
cd ../wt-lab-hotfix
cat app.txt   # শুধু "v1" দেখাবে — feature-এর অসম্পূর্ণ কাজ এখানে নেই

4. হটফিক্স করে কমিট করুন:

git checkout -b hotfix/typo
echo "v1-fixed" > app.txt
git commit -am "fix typo"

5. মূল worktree-তে ফিরে যাচাই করুন feature-এর অসম্পূর্ণ কাজ এখনো অক্ষত:

cd /tmp/wt-lab
git status   # app.txt মডিফায়েড দেখাবে, feature-এর কাজ অক্ষত
git log --all --oneline --graph   # hotfix কমিট দেখা যাচ্ছে, একই object DB শেয়ার্ড

6. পরিষ্কার করুন:

git worktree list
git worktree remove ../wt-lab-hotfix

যা লক্ষ্য করবেন

git log --all মূল worktree থেকে চালালেও hotfix-এর কমিট দেখা যায় — কারণ objects/refs শেয়ার্ড। কিন্তু app.txt-এর uncommitted content দুই worktree-তে সম্পূর্ণ আলাদা।

প্র.১ — git worktree কী সমস্যা সমাধান করে যেটা git stash + git checkout দিয়ে করা যেত না? উত্তর: Stash/checkout পদ্ধতিতে একটামাত্র working directory-তে কাজ করতে হয় বলে build artifact, IDE state, running dev server — সব বাধাগ্রস্ত হয়। Worktree প্রতিটা branch-এর জন্য আলাদা ফিজিক্যাল ফোল্ডার দেয়, তাই সমান্তরালভাবে কাজ চালানো যায় কোনো state হারানো ছাড়াই।

প্র.২ — দুইটা worktree কি একটা object কে দুইবার ডিস্কে সংরক্ষণ করে? উত্তর: না। সব worktree একই .git/objects শেয়ার করে — শুধু HEAD, index, আর working directory-র ফাইলগুলো প্রতিটা worktree-র নিজস্ব।

প্র.৩ — একই branch কি দুইটা worktree-তে একসাথে checkout করা যায়? উত্তর: না, Git এটা ব্লক করে ("already checked out")। কারণ branch pointer একটাই, দুই জায়গায় একসাথে থাকলে কোন worktree-র commit "সত্যি" তা নিয়ে দ্বন্দ্ব হতো।

প্র.৪ — git worktree remove আর ম্যানুয়ালি rm -rf দিয়ে worktree ফোল্ডার মোছার মধ্যে পার্থক্য কী? উত্তর: git worktree remove worktree ফোল্ডার এবং .git/worktrees/<name> metadata দুটোই পরিষ্কার করে। rm -rf দিয়ে সরাসরি ফোল্ডার মুছলে metadata স্টেল থেকে যায় — git worktree prune চালিয়ে সেটা পরিষ্কার করতে হয়।

প্র.৫ — git worktree lock কেন দরকার হতে পারে? উত্তর: যদি worktree কোনো removable/external ড্রাইভে থাকে যেটা মাঝে মাঝে unmount থাকতে পারে, lock করলে git worktree prune ভুল করে সেটাকে "স্টেল" ভেবে মুছে ফেলে না।

প্র.৬ — Worktree ব্যবহারের একটা ট্রেড-অফ বলুন। উত্তর: প্রতিটা worktree-র নিজস্ব build artifact/dependency (node_modules, venv) থাকতে পারে, ফলে ডিস্ক ব্যবহার বাড়ে; কিছু পুরনো IDE/GUI টুল worktree পুরোপুরি সাপোর্ট করে না।

• git worktree add করার পর একই branch অন্য জায়গায় checkout করার চেষ্টা করলে এরর আসবে — সমাধান: হয় --detach ব্যবহার করুন, নয়তো নতুন branch তৈরি করুন।

• Worktree ফোল্ডার সরাসরি সরিয়ে ফেললে (mv) Git বিভ্রান্ত হয় — .git ফাইলের ভেতরের পাথ পুরনো লোকেশনে পয়েন্ট করে থাকে। সমাধান: git worktree move <worktree> <new-path> ব্যবহার করুন, ম্যানুয়ালি mv নয়।

• মূল repository (.git ডিরেক্টরিসহ) মুছে ফেললে সব linked worktree ভেঙে পড়ে — যেহেতু objects/refs মূল .git-এই থাকে, linked worktree কোনোভাবেই স্বাধীন নয়।

• Prune স্বয়ংক্রিয়ভাবে চলে না — বেশ কিছু কমান্ড (git worktree list) মাঝেমধ্যে স্টেল entry auto-prune করলেও নির্ভরযোগ্যভাবে সবসময় হয় না; CI বা script-এ ম্যানুয়ালি git worktree prune চালানো নিরাপদ অভ্যাস।

• Detached HEAD worktree-তে কমিট করলে সেই কমিট কোনো branch-এ থাকে না — worktree সরিয়ে ফেললে বা git gc চললে সেই কমিট harvest (গার্বেজ কালেক্ট) হয়ে যেতে পারে যদি কোনো ref (branch/tag) দিয়ে reachable না থাকে।

• .git/worktrees/-এর ভেতরে জমে থাকা স্টেল entry রিপোজিটরির সাইজ বা git worktree list-এর আউটপুট নোংরা করে দিতে পারে — নিয়মিত git worktree prune -v চালানো একটা ভালো hygiene অভ্যাস, বিশেষ করে CI/স্ক্রিপ্টেড workflow-এ যেখানে worktree বারবার তৈরি-মুছা হয়।

একটা repository-র ভেতরে আরেকটা সম্পূর্ণ স্বাধীন repository রেফারেন্স করার দুইটা পদ্ধতি — git submodule (pointer-ভিত্তিক) আর git subtree (merge-ভিত্তিক)। কভার হবে: .gitmodules-এর গঠন, submodule-এর ইন্টারনাল mechanism (gitlink), সাধারণ ব্যথার পয়েন্ট, subtree workflow, আর দুটোর মধ্যে কখন কোনটা বেছে নেবেন।

সমস্যাটা কী

ধরুন আপনার মূল প্রজেক্ট একটা শেয়ার্ড internal library (common-utils) ব্যবহার করে, যেটা নিজেই আলাদাভাবে ভার্শন হয়। কোড কপি-পেস্ট করলে আপডেট trace করা কঠিন হয়ে যায়। Submodule সমাধান দেয়: মূল repository-তে পুরো library কোড না রেখে, শুধু একটা নির্দিষ্ট কমিটের রেফারেন্স রাখা হয়।

যোগ করা

git submodule add https://github.com/org/common-utils.git libs/common-utils
git commit -m "Add common-utils submodule"

এটা তৈরি করে একটা .gitmodules ফাইল:

[submodule "libs/common-utils"]
	path = libs/common-utils
	url = https://github.com/org/common-utils.git

ক্লোন করার সময়

git clone --recurse-submodules https://github.com/org/main-app.git
# অথবা আগে থেকে ক্লোন করা থাকলে:
git submodule update --init --recursive

রিয়েল-লাইফ উদাহরণ

একটা মাইক্রোসার্ভিস আর্কিটেকচারে shared protobuf schema definitions একটা আলাদা repository-তে রাখা হয়, আর প্রতিটা service সেটাকে submodule হিসেবে টেনে আনে নির্দিষ্ট commit-এ পিন করে — যাতে schema-র breaking change হঠাৎ সব service-এ ছড়িয়ে না পড়ে, প্রতিটা service ইচ্ছাকৃতভাবে আপডেট করলেই কেবল নতুন schema পায়।

Gitlink (mode 160000)

মূল repository-র tree object-এ submodule একটা বিশেষ entry হিসেবে সংরক্ষিত থাকে — সাধারণ blob (mode 100644) বা tree (mode 040000) না, বরং একটা gitlink (mode 160000), যেটা submodule repository-র একটা নির্দিষ্ট commit SHA পয়েন্ট করে:

$ git ls-tree HEAD libs/
160000 commit e3f1a2b... libs/common-utils

অর্থাৎ মূল repository আসলে submodule-এর কোড রাখে না, শুধু "এই ঠিকানায় এই commit checkout করো" — এই তথ্যটুকু রাখে। এই কারণেই .gitmodules-এ URL, আর tree-তে exact commit SHA — দুটো মিলিয়ে submodule সম্পূর্ণভাবে resolve হয়।

Detached HEAD কেন

git submodule update submodule ফোল্ডারের ভেতরে ঠিক সেই pinned commit-এ checkout করে — কোনো branch attach না করেই, কারণ submodule-এর দৃষ্টিকোণ থেকে এটা একটা নির্দিষ্ট বিন্দু, "branch-এর সর্বশেষ" না। তাই ভেতরে ঢুকলে দেখবেন:

$ cd libs/common-utils && git status
HEAD detached at e3f1a2b

নতুনরা এখানে ভুল করে সরাসরি কমিট করে ফেলেন — সেই কমিট কোনো branch-এ না থাকায় সহজেই হারিয়ে যেতে পারে।

Submodule-এর ভেতরের .git

আধুনিক Git-এ submodule ফোল্ডারের ভেতরে সরাসরি .git ডিরেক্টরি না রেখে, মূল repo-র .git/modules/<name>/-এ প্রকৃত ডেটা রাখা হয় এবং submodule ফোল্ডারে শুধু একটা .git ফাইল (gitdir পয়েন্টার) থাকে — অনেকটা worktree-র মতোই কৌশল।

সম্পূর্ণ জীবনচক্র

# যোগ করা
git submodule add <url> <path>

# প্রথমবার ক্লোন করার পর init + fetch + checkout
git submodule init
git submodule update
# অথবা একসাথে:
git submodule update --init --recursive

# বর্তমান অবস্থা দেখা (pinned SHA বনাম চেকড-আউট SHA)
git submodule status
#  e3f1a2b libs/common-utils (heads/main)
# -e3f1a2b মানে init হয়নি, +e3f1a2b মানে pinned SHA থেকে এগিয়ে গেছে

# submodule-এর ভেতরে গিয়ে সর্বশেষ commit-এ আপডেট করে মূল repo-তে সেই নতুন SHA পিন করা
cd libs/common-utils && git checkout main && git pull
cd ../.. && git add libs/common-utils && git commit -m "Bump common-utils"

# .gitmodules-এ URL পাল্টালে local config-এও সিঙ্ক করা
git submodule sync --recursive

# সম্পূর্ণ সরিয়ে ফেলা
git submodule deinit -f libs/common-utils
git rm libs/common-utils
rm -rf .git/modules/libs/common-utils

প্রতিটা submodule-এ একসাথে কমান্ড চালানো

git submodule foreach 'git checkout main && git pull'

--recurse-submodules ফ্ল্যাগ কোথায় কোথায়

clone, pull, checkout, fetch — এসব কমান্ডেও --recurse-submodules যোগ করা যায় যাতে submodule-ও একইসাথে সিঙ্ক থাকে। git config --global submodule.recurse true সেট করলে ডিফল্ট আচরণ হিসেবে সবসময় সক্রিয় থাকে।

কেন submodule-কে "ব্যথাদায়ক" বলা হয়

১. Detached HEAD-এ ভুল করে কমিট করা। submodule ফোল্ডারে ঢুকে সরাসরি কোড পরিবর্তন করে commit করলে সেটা কোনো branch-এ না থাকায় পরে git submodule update চালালে (যেটা pinned SHA-তে ফিরিয়ে আনে) সেই কাজ হারিয়ে যেতে পারে যদি push করা না থাকে।

২. ভুলে পুরনো commit reference রয়ে যাওয়া। submodule-এর ভেতরে নতুন কমিট করে push করার পর, মূল repo-তে git add libs/common-utils && git commit না করলে মূল repo এখনো পুরনো SHA পয়েন্ট করতে থাকে — টিমমেট pull করলেও পুরনো ভার্শনই পাবে।

৩. টিমমেট submodule update ভুলে যাওয়া। কেউ মূল repo pull করলে submodule pointer বদলে যেতে পারে, কিন্তু git pull ডিফল্টভাবে submodule কোড আপডেট করে না — শুধু pointer আপডেট করে। ফলে submodule ফোল্ডারে পুরনো কোড থেকে যায়, "কাজ করছে না" বলে বাগ রিপোর্ট আসে যেটা আসলে stale submodule।

প্রশমনের উপায়

git config --global submodule.recurse true   # pull/checkout-এ অটো-রিকার্স

CI pipeline-এও --recurse-submodules clone flag বাধ্যতামূলক করা, আর README-তে স্পষ্ট নির্দেশনা রাখা — এই দুটো টিম-লেভেল ব্যথা অনেকটা কমায়।

Subtree কী

git subtree submodule-এর বিপরীত দর্শন নেয়: বহিরাগত repository-র কোড আসলেই মূল repository-র history-তে merge করে দেওয়া হয় — কোনো আলাদা pointer/gitlink না, পুরো কোড সরাসরি tree-তে বসে যায়।

# যোগ করা (squash করে, পুরো বহিরাগত history না টেনে)
git subtree add --prefix=libs/common-utils \
  https://github.com/org/common-utils.git main --squash

# আপডেট আনা
git subtree pull --prefix=libs/common-utils \
  https://github.com/org/common-utils.git main --squash

# পরিবর্তন ফেরত পাঠানো (contribute back)
git subtree push --prefix=libs/common-utils \
  https://github.com/org/common-utils.git main

# আলাদা করে নতুন repo হিসেবে বের করে আনা
git subtree split --prefix=libs/common-utils -b extracted-branch

তুলনা টেবিল: Submodule বনাম Subtree

কখন কোনটা

• বহিরাগত কোড কম পরিবর্তনশীল, ভার্শন-পিন করা দরকার, একাধিক প্রজেক্ট শেয়ার করে → Submodule
• বহিরাগত কোড প্রায়ই edit করতে হবে সরাসরি মূল repo-র ভেতর থেকেই, বা টিমকে .gitmodules শেখানোর ঝক্কি এড়াতে চান → Subtree

লক্ষ্য

একটা submodule যোগ করে, ইচ্ছাকৃতভাবে "stale submodule" সমস্যা তৈরি করে, তারপর ঠিক করা।

ধাপ

1. দুইটা টেস্ট repo বানান:

mkdir /tmp/lib-repo && cd /tmp/lib-repo && git init
echo "v1" > lib.txt && git add . && git commit -m "lib v1"

mkdir /tmp/main-repo && cd /tmp/main-repo && git init
echo "app" > app.txt && git add . && git commit -m "init app"

2. submodule যোগ করুন:

git submodule add /tmp/lib-repo libs/mylib
git commit -m "Add mylib submodule"
git ls-tree HEAD libs/    # মোড 160000 লক্ষ্য করুন

3. Submodule-এর উৎসে (lib-repo) নতুন কমিট দিন — কিন্তু মূল repo-তে আপডেট করবেন না:

cd /tmp/lib-repo
echo "v2" > lib.txt && git commit -am "lib v2"

4. "stale submodule" সমস্যা পুনরায় তৈরি করুন — main-repo-তে ফিরে দেখুন এখনো v1 pinned:

cd /tmp/main-repo
cat libs/mylib/lib.txt    # এখনো "v1" দেখাবে, যদিও উৎসে v2 আছে
git submodule status      # pinned SHA বনাম upstream SHA-র পার্থক্য বোঝা

5. সঠিকভাবে আপডেট করুন এবং মূল repo-তে নতুন pointer commit করুন:

cd libs/mylib && git checkout main && git pull
cd ../.. && git add libs/mylib && git commit -m "Bump mylib to v2"

6. যাচাই করুন gitlink SHA বদলেছে:

git ls-tree HEAD libs/

চ্যালেঞ্জ

git submodule deinit -f libs/mylib চালিয়ে submodule সম্পূর্ণ সরিয়ে দেখুন .gitmodules ও .git/config-এ কী পরিবর্তন হয়।

প্র.১ — Submodule মূল repository-তে ঠিক কী সংরক্ষণ করে — পুরো কোড, নাকি অন্য কিছু? উত্তর: পুরো কোড না, শুধু একটা gitlink entry (mode 160000) যেটা submodule repository-র একটা নির্দিষ্ট commit SHA পয়েন্ট করে। .gitmodules ফাইলে URL সংরক্ষিত থাকে, আর tree-তে SHA — দুটো মিলিয়ে resolve হয়।

প্র.২ — git clone করার পর submodule ফোল্ডার খালি দেখাচ্ছে কেন? উত্তর: কারণ git clone ডিফল্টভাবে submodule init/checkout করে না। --recurse-submodules দিয়ে ক্লোন করতে হবে, অথবা পরে git submodule update --init --recursive চালাতে হবে।

প্র.৩ — submodule ফোল্ডারের ভেতরে গিয়ে git status চালালে "HEAD detached at ..." কেন দেখায়? উত্তর: submodule কোনো branch-এর "সর্বশেষ" অবস্থা না, একটা নির্দিষ্ট pinned commit — তাই checkout হয় detached HEAD-এ। ভেতরে সরাসরি কমিট করলে সেটা কোনো branch-এ না থাকায় হারিয়ে যাওয়ার ঝুঁকি থাকে।

প্র.৪ — "stale submodule" সমস্যাটা কীভাবে ঘটে এবং কীভাবে এড়াবেন? উত্তর: টিমমেট git pull করলে শুধু submodule-এর pointer আপডেট হয়, কোড না — git submodule update আলাদা করে চালাতে হয়। git config --global submodule.recurse true সেট করে এটা স্বয়ংক্রিয় করা যায়।

প্র.৫ — Submodule আর Subtree-এর মধ্যে মূল স্থাপত্যগত পার্থক্য কী? উত্তর: Submodule পয়েন্টার-ভিত্তিক — কোড আলাদা থাকে, শুধু commit reference রাখা হয়। Subtree merge-ভিত্তিক — বহিরাগত কোড সরাসরি মূল repo-র history-তে মিশে যায়, আলাদা init/update ধাপ লাগে না ক্লোনের সময়।

প্র.৬ — কোন পরিস্থিতিতে subtree submodule-এর চেয়ে ভালো পছন্দ? উত্তর: যখন বহিরাগত কোড ঘন ঘন এডিট করতে হবে সরাসরি মূল repo-র ভেতর থেকেই, অথবা টিমকে .gitmodules/detached-HEAD workflow শেখানোর জটিলতা এড়াতে চান — এবং repository সাইজ বাড়া গ্রহণযোগ্য।

• .gitmodules-এ URL পাল্টালে শুধু ফাইল এডিট করাই যথেষ্ট না — git submodule sync না চালালে local .git/config-এ পুরনো URL রয়ে যায়, পরের fetch পুরনো ঠিকানাতেই যাবে।

• Submodule-এর ভেতরে git branch -d চালালে মূল repo-র pinned commit নষ্ট হয় না, কিন্তু সেই commit যদি কোনো ref থেকে unreachable হয়ে যায় এবং submodule-এর নিজস্ব git gc চলে, সেই কমিট হারিয়ে যেতে পারে।

• Relative URL ব্যবহার করলে submodule fork করা সহজ হয় কিন্তু বিভ্রান্তিকর হতে পারে — .gitmodules-এ ../common-utils.git-এর মতো relative path GitHub/GitLab-এ fork workflow-এ কাজে লাগে, কিন্তু ভিন্ন hosting-এ মাইগ্রেট করলে ভেঙে যেতে পারে।

• Subtree-তে --squash না দিলে বহিরাগত repo-র পুরো commit history মূল repo-তে ঢুকে যায় — git log হঠাৎ শত শত অপরিচিত কমিটে ভরে যায়, blame/bisect জটিল হয়ে ওঠে। --squash দিয়ে একটামাত্র merge commit রাখা সাধারণত নিরাপদ পছন্দ।

• git submodule update ডিফল্টভাবে merge/rebase strategy ছাড়াই checkout করে — যদি submodule-এর ভেতরে লোকাল uncommitted পরিবর্তন থাকে, update ব্যর্থ হয়ে যায় বা সেগুলো silently overwrite করার ঝুঁকি তৈরি করে; --merge/--rebase ফ্ল্যাগ যোগ করলে আচরণ স্পষ্ট হয়।

হাজার হাজার কমিট, গিগাবাইট গিগাবাইট বাইনারি অ্যাসেট, শত শত ফোল্ডারের একটা মনোরেপো — পুরো জিনিস প্রতিটা ডেভেলপারের মেশিনে সম্পূর্ণ ক্লোন করা অবাস্তব হয়ে যায়। কভার হবে: shallow ও partial clone (lazy fetch), sparse-checkout (দরকারি অংশটুকু চেকআউট), git maintenance (background housekeeping), আর Git LFS (বড় বাইনারি ফাইল ম্যানেজমেন্ট)। এই মডিউল শেষে একটা Phase 8-এর checkpoint gate আছে।

সমস্যাটা কী

একটা repository-র ১০ বছরের ইতিহাস, লাখো কমিট — কিন্তু CI pipeline-এর দরকার শুধু সর্বশেষ কোড, পুরো ইতিহাস না। পুরো ক্লোন করলে সময় ও ব্যান্ডউইথ অপচয় হয়।

Shallow Clone

git clone --depth 1 https://github.com/org/huge-repo.git

এটা শুধু সর্বশেষ ১টা কমিট (আর তার সাথে যুক্ত tree/blob object) fetch করে। ফলাফল একটা truncated history — পুরনো কমিটে git log/git blame গেলে "shallow" boundary-তে থেমে যাবে।

$ git log --oneline
a1b2c3d Latest commit
# তার আগে আর কিছু নেই — history truncated

পরে পুরো ইতিহাস দরকার হলে

git fetch --unshallow

এটা shallow repository-কে সম্পূর্ণ, normal repository-তে রূপান্তর করে — বাকি সব commit history fetch করে আনে।

রিয়েল-লাইফ উদাহরণ

CI pipeline-এ যেখানে শুধু build/test করতে হবে, --depth 1 clone সেকেন্ডের পার্থক্য তৈরি করে বড় monorepo-তে। কিন্তু যদি সেই pipeline-এ git blame বা tag-ভিত্তিক changelog তৈরি করতে হয়, shallow clone কাজ করবে না — সেক্ষেত্রে --depth বাড়াতে হয় বা fetch --unshallow করতে হয়।

সতর্কতা

Shallow repository থেকে push করা বা নতুন clone বানানো (clone from shallow) কিছু সীমাবদ্ধতা আনে — সব Git server শুরুর দিকে shallow fetch/push পুরোপুরি সমর্থন করত না, আধুনিক Git/GitHub-এ এটা মূলত ঠিকঠাক কাজ করে।

Shallow বনাম Partial — পার্থক্য

Shallow clone সময়ের গভীরতা (কতগুলো পুরনো commit) কমায়। Partial clone ভিন্ন মাত্রায় কাজ করে — পুরো commit history রাখে, কিন্তু blob (ফাইল content) বা tree object lazily, প্রয়োজন হলেই fetch করে।

--filter=blob:none

git clone --filter=blob:none https://github.com/org/huge-repo.git

সব commit ও tree object আসে (তাই পুরো history নেভিগেট করা যায়, git log স্বাভাবিক কাজ করে), কিন্তু blob (actual ফাইল content) আসে না — যখন git checkout কোনো ফাইলের content দরকার হয়, তখন সার্ভার থেকে on-demand fetch হয়।

--filter=tree:0

আরও আক্রমণাত্মক — tree object-ও শুরুতে আসে না, শুধু commit object। git log-এর মতো কমান্ডও কিছু ক্ষেত্রে lazy fetch ট্রিগার করবে।

রিয়েল-লাইফ উদাহরণ

একটা মনোরেপোতে ১০০+ সার্ভিস আছে, কিন্তু একজন ডেভেলপার শুধু একটা সার্ভিসে কাজ করেন। --filter=blob:none দিয়ে ক্লোন করলে পুরো commit graph/history ঠিকঠাক দেখা যায় (navigation স্বাভাবিক), কিন্তু ডিস্কে সব ফাইলের content নামানো হয় না — sparse-checkout-এর সাথে মিলিয়ে ব্যবহার করলে এটা সবচেয়ে কার্যকর।

$ git clone --filter=blob:none --sparse https://github.com/org/monorepo.git
$ cd monorepo
$ git sparse-checkout set services/payment

ট্রেড-অফ

• Lazy fetch-এর জন্য প্রতিটা নতুন blob দরকার হলে নেটওয়ার্ক কল লাগে — অফলাইনে কাজ করলে সমস্যা হতে পারে যদি blob আগে থেকে cache না থাকে।
• সব Git hosting provider (self-hosted পুরনো সার্ভার) partial clone protocol সমর্থন নাও করতে পারে।