Ref, reflog আর উদ্ধার — হারানো commit ফিরিয়ে আনা আর garbage collection

১ · Ref — commit-এর গায়ে লাগানো নামের লেবেল

রেলস্টেশনের কথা ভাবুন। ট্রেনের বগিগুলো লাইনের ওপর দাঁড়িয়ে আছে, আর প্ল্যাটফর্মের বোর্ডে লেখা “সুবর্ণ এক্সপ্রেস — ৩ নম্বর লাইন”। বোর্ডের লেখা বদলালে বগি নড়ে না; শুধু যাত্রীরা অন্য বগির দিকে যান। আর কোনো বগির নাম যদি কোনো বোর্ডেই না থাকে, তবু সেটি ইয়ার্ডে পড়ে থাকে — যতদিন না রেলের কর্মীরা পরিষ্কারের দিনে সেটি সরিয়ে নেন। Git-এ commit হলো বগি, আর ref হলো বোর্ডের লেখা। এই পর্বের পুরো গল্প এই ছবিতেই: নাম সরানো সস্তা আর নিরাপদ, বগি সরানো (garbage collection) ধীর আর সাবধানী।

পর্ব ১২-এ দেখেছেন, একটি branch আসলে .git/refs/heads/-এর নিচে একটি ছোট ফাইল, যার ভেতরে একটি commit hash. আর পর্ব ৫২-এ দেখছেন, commit, tree আর blob — এই object-গুলো hash দিয়ে চেনা যায়, একবার লেখার পর আর বদলায় না। এই দুইয়ের মাঝখানের সেতু হলো ref: অপরিবর্তনীয় object-এর জগতে একমাত্র বদলানো যায় এমন জিনিস। Git-এর প্রায় সব “ধ্বংসাত্মক” command — reset, rebase, commit --amend, branch -D, stash drop — আসলে শুধু ref সরায় বা মোছে। সেজন্যই উদ্ধার সম্ভব।

পাঁচ পরিবারের ref

এই পর্বের সব “উদাহরণ” আউটপুট এই যন্ত্রে Git ২.৫৩ দিয়ে scratchpad-এর একটি আলাদা ফোল্ডারে চালিয়ে হুবহু কপি করা। প্রজেক্টটি আগের পর্বগুলোর মতো একটি কাল্পনিক অনলাইন বাজার অ্যাপ। লেখক Rahim, ইমেল rahim@example.com, আর প্রতিটি commit-এর সময় নির্দিষ্ট (2026-01-15, সকাল ১০টা থেকে প্রতি ধাপে এক মিনিট করে), তাই একই ফাইল লিখলে আপনার যন্ত্রেও একই hash আসবে। Repository-তে তিনটি commit-এর main, একটি feature/coupon branch, দুই রকম tag, একটি local bare repository-কে remote ধরে origin/main, একটি stash আর একটি note আছে:

$ git -c init.defaultBranch=main init -q bazar && cd bazar
$ git config user.name "Rahim"; git config user.email "rahim@example.com"
$ git config core.autocrlf false
# প্রতিটি ধাপের আগে: export GIT_AUTHOR_DATE=… GIT_COMMITTER_DATE=… (10:00, 10:01, …)
$ git commit …  "Add README"          # 10:00
$ git commit …  "Add cart total"      # 10:01
$ git tag -a v1.0 -m "First release"; git tag light     # 10:02
$ git commit …  "Add discount rule"   # 10:03
$ git switch -c feature/coupon; git commit … "Add coupon codes"   # 10:04
$ git switch main
$ git notes add -m "Reviewed by Karim" HEAD             # 10:06
$ git init -q --bare ../origin.git; git remote add origin ../origin.git
$ git push -q origin main; git fetch -q origin          # 10:07, 10:08
$ git stash push -q -m "wip readme"                     # 10:09

এবার দেখা যাক এই নামগুলো ডিস্কে কোথায় আছে। .git/HEAD একটি সাধারণ text ফাইল, আর প্রতিটি ref .git/refs/-এর নিচে একটি করে ফাইল:

$ cat .git/HEAD
ref: refs/heads/main
$ find .git/refs -type f | sort
.git/refs/heads/feature/coupon
.git/refs/heads/main
.git/refs/notes/commits
.git/refs/remotes/origin/main
.git/refs/stash
.git/refs/tags/light
.git/refs/tags/v1.0
$ cat .git/refs/heads/main
5f738def208645b7aa88b553e0ea5d2514a65900

এই আলাদা আলাদা ফাইলগুলোকে বলে loose ref. খেয়াল করুন, feature/coupon নামের “/” আসলে একটি ফোল্ডার — refs/heads/feature/-এর ভেতরে coupon ফাইল। এজন্যই একসাথে feature আর feature/coupon নামে দুটি branch রাখা যায় না: একই নামে ফাইল আর ফোল্ডার দুটিই হতে পারে না।

git for-each-ref — ref-এর তালিকা, নিজের ছাঁচে

ফাইল ধরে ধরে cat করা কষ্টের, আর পরের অংশে দেখবেন সব ref ফাইল হিসেবে থাকেও না। সব ref-এর নির্ভরযোগ্য তালিকা দেয় git for-each-ref. এর --format-এ %(…) ঘর বসিয়ে যা খুশি দেখানো যায় — অনেকটা দর্জির মাপের খাতার মতো, কোন কলামে কী লিখবেন আপনি ঠিক করেন:

$ git for-each-ref --format='%(objectname:short) %(objecttype) %(refname)'
3193cd0 commit refs/heads/feature/coupon
5f738de commit refs/heads/main
37e32b9 commit refs/notes/commits
5f738de commit refs/remotes/origin/main
7212405 commit refs/stash
3457a7b commit refs/tags/light
62b7cb0 tag refs/tags/v1.0
$ git for-each-ref --format='%(refname:short) -> %(objectname:short) %(*objectname:short) %(subject)' refs/tags
light -> 3457a7b  Add cart total
v1.0 -> 62b7cb0 3457a7b First release
$ git for-each-ref --sort=-committerdate --format='%(committerdate:short) %(refname:short) %(authorname)' refs/heads
2026-01-15 feature/coupon Rahim
2026-01-15 main Rahim

প্রথম তালিকায় একটি সূক্ষ্ম জিনিস: v1.0-এর objecttype হলো tag, commit নয়। Annotated tag একটি আলাদা tag object (62b7cb0) দেখায়, যার ভেতরে tagger, তারিখ, বার্তা আর আসল commit-এর hash থাকে। Lightweight tag light সরাসরি commit 3457a7b দেখায়। দ্বিতীয় command-এ %(*objectname)-এর তারকা চিহ্ন বলে “tag object-এর খোসা ছাড়িয়ে ভেতরের জিনিসটি দেখাও” — তাই v1.0-এর পাশে 3457a7b, আর light-এর ঘর খালি (খোসা নেই)। তৃতীয়টিতে --sort=-committerdate নতুন থেকে পুরোনো সাজায়; বড় repository-তে “কোন branch মাসের পর মাস কেউ ছোঁয়নি” খুঁজতে এটিই দলের প্রিয় command. --merged, --contains আর --count দিয়ে তালিকা ছাঁকা যায়; git branch আর git tag-এর --format ভেতরে এই একই যন্ত্র ব্যবহার করে। Git ২.৫৩-এর documentation-এ একই কাজের নতুন নাম git refs list-ও আছে।

refs/notes/commits-ও একটি commit দেখায় — notes আসলে নিজস্ব একটি ছোট history, যার tree-তে ফাইলের নাম হলো যে commit-এর টীকা তার hash. তাই commit 5f738de-এর hash না বদলে তার সাথে “Reviewed by Karim” জুড়ে দেওয়া গেছে; git log --format='%h %s%n%N' লিখলে টীকাটি দেখা যায়। Notes ডিফল্টভাবে push বা fetch হয় না, আলাদা refspec লাগে (পর্ব ১৪)।

২ · Loose ref আর packed-refs — নাম কোথায় লেখা থাকে

প্রতি ref-এ একটি ফাইল — ছোট project-এ চমৎকার। কিন্তু হাজারো tag আর branch থাকলে হাজারো ছোট ফাইল; প্রতিটি খোলা, পড়া আর ডিস্কে জায়গা নেওয়া ধীর। তাই Git মাঝে মাঝে সব ref-কে একটি ফাইলে গুছিয়ে রাখে: packed-refs. মুদি দোকানের খাতার কথা ভাবুন — দিনের প্রতিটি বিক্রি আলাদা চিরকুটে লেখা হলো, রাতে সব চিরকুট একটি খাতায় তুলে চিরকুটগুলো ফেলে দেওয়া হলো। হাতে করে এটি করে git pack-refs --all; সাধারণত git gc-ও এটি করে।

$ git pack-refs --all
$ cat .git/packed-refs
# pack-refs with: peeled fully-peeled sorted
3193cd0e7957a21cbb0f1bb8c0172d0239c4f80d refs/heads/feature/coupon
5f738def208645b7aa88b553e0ea5d2514a65900 refs/heads/main
37e32b9578349b90b61d5c076493f642d2825cb6 refs/notes/commits
5f738def208645b7aa88b553e0ea5d2514a65900 refs/remotes/origin/main
7212405518b426de49689c31e3d2558d6855a0c4 refs/stash
3457a7bc9716d067de7a2db4fd0308b5bc2b35db refs/tags/light
62b7cb075cc4df415f92ca813d07e0dcfa42e6bc refs/tags/v1.0
^3457a7bc9716d067de7a2db4fd0308b5bc2b35db
$ find .git/refs -type f | sort

শেষ find কিছুই দেখায়নি — সব loose ফাইল মুছে খাতায় উঠে গেছে (ফোল্ডারগুলো খালি পড়ে থাকে)। ফাইলের গঠন সহজ: প্রথম লাইন একটি শিরোনাম, যা বলে এই খাতা কোন কোন সুবিধা মেনে লেখা (sorted মানে নাম অনুযায়ী সাজানো, তাই দ্রুত খোঁজা যায়)। তারপর প্রতি লাইনে পুরো hash, একটি space, আর ref-এর নাম। সবচেয়ে মজার লাইনটি শেষেরটি: ^3457a7b…. এটি একটি peeled মান — ঠিক ওপরের লাইনের annotated tag v1.0-এর খোসা ছাড়ালে যে commit পাওয়া যায়। Git আগেভাগে লিখে রাখে, যাতে “v1.0 কোন commit” জানতে প্রতিবার tag object খুলতে না হয়। Command line-এ একই জিনিস লেখা হয় v1.0^{}:

$ git rev-parse v1.0 v1.0^{}
62b7cb075cc4df415f92ca813d07e0dcfa42e6bc
3457a7bc9716d067de7a2db4fd0308b5bc2b35db

দুই জায়গায় দুই মান — কোনটি সত্যি?

Pack করার পর main-এ একটি নতুন commit দিলে কী হয়? Git পুরো packed-refs নতুন করে লেখে না; শুধু main-এর জন্য আবার একটি loose ফাইল বানায়। খাতায় পুরোনো মান থেকেই যায়:

$ git commit -q -m "Update README"
$ find .git/refs/heads -type f
.git/refs/heads/main
$ grep refs/heads/main .git/packed-refs
5f738def208645b7aa88b553e0ea5d2514a65900 refs/heads/main
$ cat .git/refs/heads/main
3db278b74adee3db23f15155a0b2c38ae45cc495
$ git rev-parse main
3db278b74adee3db23f15155a0b2c38ae45cc495

নিয়ম: একই নামের loose ফাইল থাকলে সেটিই জেতে; খাতার লাইন তখন বাসি (stale) আর উপেক্ষিত। খাতা কেবল সেই ref-গুলোর জন্য পড়া হয়, যাদের loose ফাইল নেই। তাই কখনো হাতে packed-refs সম্পাদনা করবেন না, বা .git/refs/-এ ফাইল মুছে “branch মোছা” ভাববেন না — খাতায় থাকা পুরোনো মান আবার জেগে উঠতে পারে। Ref বদলানো বা মোছার সঠিক পথ git branch -d, git tag -d বা git update-ref, যারা দুই জায়গাই সামলায়। নিচের Python প্রোগ্রাম ঠিক এই নিয়মে ওপরের আসল খাতা আর loose ফাইল পড়ে:

# Read packed-refs + loose refs the way the "files" backend does: loose wins, "^" = peeled tag.
PACKED = """# pack-refs with: peeled fully-peeled sorted
5f738def208645b7aa88b553e0ea5d2514a65900 refs/heads/main
5f738def208645b7aa88b553e0ea5d2514a65900 refs/remotes/origin/main
3457a7bc9716d067de7a2db4fd0308b5bc2b35db refs/tags/light
62b7cb075cc4df415f92ca813d07e0dcfa42e6bc refs/tags/v1.0
^3457a7bc9716d067de7a2db4fd0308b5bc2b35db
"""
LOOSE = {"refs/heads/main": "3db278b74adee3db23f15155a0b2c38ae45cc495\n",  # .git/refs/heads/main
         "HEAD": "ref: refs/heads/main\n"}                                  # .git/HEAD

def parse_packed(text):
    refs, peeled, last = {}, {}, None
    for line in text.splitlines():
        if not line or line.startswith("#"): continue
        if line.startswith("^"):           # peeled value of the tag on the line above
            peeled[last] = line[1:]; continue
        oid, name = line.split(" ", 1)
        refs[name], last = oid, name
    return refs, peeled
def resolve(name, packed, depth=0):
    if depth > 5: raise ValueError("symbolic ref loop")
    if name in LOOSE:                      # a loose file always beats packed-refs
        value = LOOSE[name].strip()
        if value.startswith("ref: "):      # symbolic ref: follow the name written inside
            return resolve(value[5:], packed, depth + 1)
        return value, "loose"
    return packed[name], "packed"

packed, peeled = parse_packed(PACKED)
for name in ["HEAD", "refs/heads/main", "refs/remotes/origin/main", "refs/tags/v1.0"]:
    oid, src = resolve(name, packed)
    tag = f"  peeled ^{{}} -> {peeled[name][:7]}" if name in peeled else ""
    print(f"{name:26} {oid[:7]} ({src}){tag}")
print("stale packed value of main:", packed["refs/heads/main"][:7])

HEAD                       3db278b (loose)
refs/heads/main            3db278b (loose)
refs/remotes/origin/main   5f738de (packed)
refs/tags/v1.0             62b7cb0 (packed)  peeled ^{} -> 3457a7b
stale packed value of main: 5f738de

তৃতীয় পথ — reftable backend

Loose ফাইল আর packed-refs মিলিয়ে যে ব্যবস্থা, Git তাকে বলে files backend. এর কিছু পুরোনো ঝামেলা আছে: Windows আর macOS-এর ফাইল সিস্টেম সাধারণত বড়-ছোট হাতের অক্ষর আলাদা করে না, তাই Feature আর feature branch গোলমাল বাধায়; একসাথে অনেক ref বদলানো পুরোপুরি atomic নয়; আর লাখো ref-ওয়ালা hosting server-এ খাতা নতুন করে লেখা ব্যয়বহুল। এর সমাধান হিসেবে এসেছে reftable — ref আর reflog রাখার একটি binary, সাজানো table-এর ফরম্যাট। যতদূর জানা যায়, ফরম্যাটটির নকশা শুরু হয়েছিল JGit প্রজেক্টে (প্রায় ২০১৭ সালে), আর Git ২.৪৫ (২০২৪) থেকে নতুন repository বানানোর সময় এটি বেছে নেওয়া যায়:

$ git -c init.defaultBranch=main init -q --ref-format=reftable rt
$ git -C rt rev-parse --show-ref-format
reftable
$ ls rt/.git/reftable
0x000000000001-0x000000000001-88986262.ref
tables.list
$ cat rt/.git/HEAD
ref: refs/heads/.invalid
$ cat rt/.git/refs/heads
this repository uses the reftable format
$ git -C bazar rev-parse --show-ref-format
files

reftable repository-তে .git/HEAD আর .git/refs শুধু পুরোনো Git-কে বিভ্রান্ত না করার জন্য রাখা “পাহারাদার” ফাইল; আসল ref থাকে reftable/-এর table-এ (ফাইলের নামের শেষ অংশ প্রতিবার আলাদা হয়)। এর মানে “cat .git/refs/heads/main” ধরনের কৌশল সব repository-তে চলবে না — script লিখলে সবসময় git rev-parse, git for-each-ref বা git update-ref ব্যবহার করুন। পুরোনো repository রূপান্তরের জন্য git refs migrate --ref-format=reftable আছে (documentation-এ লেখা, ফরম্যাটটি এখনো experimental আর ভেতরের খুঁটিনাটি বদলাতে পারে)। ভবিষ্যতের কোনো বড় Git version-এ এটিকে ডিফল্ট করার আলোচনা আছে, তবে লেখার সময়ে ডিফল্ট files.

৩ · Symbolic ref আর বিশেষ ref — HEAD, ORIG_HEAD, FETCH_HEAD, MERGE_HEAD

বেশিরভাগ ref-এর ভেতরে একটি hash. কিন্তু .git/HEAD-এ লেখা ছিল ref: refs/heads/main — একটি hash নয়, আরেকটি ref-এর নাম। এমন ref-কে বলে symbolic ref. বিয়েবাড়ির আয়োজনের তালিকায় “রান্নার দায়িত্ব: যিনি বাবুর্চি” লেখা থাকলে বাবুর্চি বদলালেও তালিকা বদলাতে হয় না — HEAD ঠিক তেমন: main নতুন commit-এ সরলে HEAD নিজে বদলায় না, তবু সবসময় main-এর মাথা দেখায়। git symbolic-ref দিয়ে এটি সরাসরি পড়া যায়:

$ git symbolic-ref HEAD
refs/heads/main
$ git symbolic-ref --short HEAD
main
$ git rev-parse HEAD
5f738def208645b7aa88b553e0ea5d2514a65900
# আলাদা একটি throwaway repository-তে, detached অবস্থায়:
$ git switch -q --detach
$ git symbolic-ref HEAD
fatal: ref HEAD is not a symbolic ref
$ git symbolic-ref -q HEAD; echo "exit code: $?"
exit code: 1

symbolic-ref নাম দেয়, rev-parse শেষ পর্যন্ত গিয়ে hash দেয়। Detached HEAD অবস্থায় HEAD-এ সরাসরি hash থাকে, তাই symbolic-ref ব্যর্থ হয় (পর্ব ১২)। Script-এ “এখন কোন branch-এ আছি, নাকি detached?” জানতে git symbolic-ref -q HEAD সবচেয়ে পরিষ্কার পথ: -q ভুলের বার্তা চেপে রাখে, শুধু exit code ১ দেয়। আরেকটি পরিচিত symbolic ref হলো refs/remotes/origin/HEAD, যা remote-এর ডিফল্ট branch দেখায়। এটি clone-এর সময় তৈরি হয়; Git ২.৪৮ থেকে fetch-ও না থাকলে এটি বানায়, যদি remote-এর HEAD একটি আসল branch দেখায়। আমাদের bare repository-র HEAD তখনো জন্ম না নেওয়া master দেখাচ্ছিল, তাই ওপরের তালিকায় এটি নেই; আপনার config-এ init.defaultBranch=main থাকলে তালিকায় refs/remotes/origin/HEAD-ও দেখবেন।

কাজের মাঝপথের বিশেষ ref

.git ফোল্ডারের একদম ওপরে কিছু বড়-হাতের নামের ফাইল থাকে। এগুলো branch নয়; Git কোনো কাজের মাঝখানে বা পরে “কোথা থেকে এসেছিলাম” মনে রাখতে এগুলো লেখে। পরীক্ষার জন্য আমরা main~1 থেকে একটি hotfix branch বানিয়ে README-এর সেই লাইনটিই অন্যভাবে বদলেছি, যা main-এও বদলেছে — তাই merge আর cherry-pick দুটিই conflict-এ থামে:

$ git merge hotfix
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.
$ ls .git | grep HEAD
FETCH_HEAD
HEAD
MERGE_HEAD
ORIG_HEAD
$ cat .git/MERGE_HEAD
bf6efa2eb2f273be614c4fd32e2d961403b0b533
$ git merge --abort
$ git cherry-pick hotfix
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
error: could not apply bf6efa2... Hotfix README
…
$ cat .git/CHERRY_PICK_HEAD
bf6efa2eb2f273be614c4fd32e2d961403b0b533
$ git cherry-pick --abort
# অনেক আগে, git fetch-এর ঠিক পরে নেওয়া:
$ cat .git/FETCH_HEAD
5f738def208645b7aa88b553e0ea5d2514a65900	not-for-merge	branch 'main' of ../origin

আমাদের FETCH_HEAD-এ not-for-merge লেখা, কারণ main-এর কোনো upstream ঠিক করা ছিল না — তাই fetch জানত না কোন branch merge-যোগ্য। Upstream থাকলে সেই লাইনে এই চিহ্ন থাকে না, আর git pull আসলে “fetch, তারপর FETCH_HEAD-এর সেই লাইনটি merge”. MERGE_HEAD থাকলে git status জানায় যে merge চলছে (conflict মেটানো না হলে “You have unmerged paths”), আর আপনি commit দিলে Git দুই parent-ওয়ালা merge commit বানায় — দ্বিতীয় parent আসে এখান থেকেই। Conflict-এর পুরো যুক্তি পর্ব ৫৪-এ।

উদ্ধারের দিক থেকে সবচেয়ে কাজের ORIG_HEAD: ভুল merge বা rebase-এর ঠিক পরে git reset --hard ORIG_HEAD আগের অবস্থায় ফেরায় — পর্ব ১৫-এ এটি দেখেছেন। সমস্যা হলো এটি একটিই ঘর: পরের reset বা merge সেটি ওপরে লিখে দেয়। দীর্ঘ স্মৃতির জন্য দরকার reflog, পরের অংশে।

git update-ref — ref-এ সরাসরি লেখা

git update-ref হলো ref বদলানোর নিচু-স্তরের, script-বান্ধব command. git branch ভেতরে প্রায় এটাই করে, কিন্তু update-ref নিজে কোনো নিয়ম চাপায় না — তাই ক্ষমতাও বেশি, দায়ও বেশি। এর সবচেয়ে মূল্যবান রূপটি তিন-argument-এর: “নতুন মান বসাও, কিন্তু শুধু যদি এখনকার মান এটি হয়”:

$ git update-ref -m "safety copy" refs/heads/backup HEAD
$ git branch --list
  backup
  feature/coupon
* main
$ git update-ref refs/heads/backup 3457a7b 3193cd0e7957a21cbb0f1bb8c0172d0239c4f80d
fatal: update_ref failed for ref 'refs/heads/backup': cannot lock ref 'refs/heads/backup': is at 5f738def208645b7aa88b553e0ea5d2514a65900 but expected 3193cd0e7957a21cbb0f1bb8c0172d0239c4f80d
$ git log -g --format="%h %gd %gs" backup
5f738de backup@{0} safety copy
$ git update-ref -d refs/heads/backup
$ git show-ref --heads
3193cd0e7957a21cbb0f1bb8c0172d0239c4f80d refs/heads/feature/coupon
5f738def208645b7aa88b553e0ea5d2514a65900 refs/heads/main

প্রথম লাইন একটি backup branch বানাল, আর -m-এর বার্তা reflog-এ উঠল (backup@{0} safety copy). দ্বিতীয় চেষ্টায় আমরা বলেছিলাম “backup যদি 3193cd0-এ থাকে, তবে 3457a7b-এ সরাও” — কিন্তু সেটি ছিল 5f738de-এ, তাই Git কিছুই না বদলে থেমে গেল। এই “compare-and-swap” কৌশলেই একাধিক script বা মানুষ একই ref নিয়ে কাজ করলেও একজন আরেকজনের কাজ চুপচাপ মুছে দেয় না — --force-with-lease-এর পেছনের চিন্তাও এটাই (পর্ব ১৪)। -d ref মোছে — loose ফাইল আর খাতার লাইন দুটোই। git update-ref --stdin দিয়ে অনেকগুলো বদল একটি transaction-এ করা যায়।

৪ · Reflog গভীরে — প্রতিটি ref-এর নিজের খাতা

পর্ব ১১-এ reflog-কে চিনেছেন “HEAD-এর চলাচলের খাতা” হিসেবে। পুরো সত্যটা একটু বড়: প্রতিটি branch-এর নিজস্ব reflog আছে, আর HEAD-এর আলাদা একটি. Files backend-এ এগুলো .git/logs/HEAD আর .git/logs/refs/heads/… নামের সাধারণ text ফাইল; প্রতিটি লাইনে আগের hash, নতুন hash, কে, কখন আর কেন। Branch-এর খাতায় শুধু সেই branch-এর মাথা কখন কোথায় সরল তা থাকে; HEAD-এর খাতায় থাকে আপনার প্রতিটি পদক্ষেপ, branch বদলানোসহ। একই repository-র দুই খাতা পাশাপাশি:

$ git reflog -6
3db278b HEAD@{0}: commit: Update README
5f738de HEAD@{1}: reset: moving to HEAD
5f738de HEAD@{2}: checkout: moving from feature/coupon to main
3193cd0 HEAD@{3}: commit: Add coupon codes
5f738de HEAD@{4}: checkout: moving from main to feature/coupon
5f738de HEAD@{5}: commit: Add discount rule
$ git reflog show main
3db278b main@{0}: commit: Update README
5f738de main@{1}: commit: Add discount rule
3457a7b main@{2}: commit: Add cart total
df9c5fe main@{3}: commit (initial): Add README
$ git reflog show feature/coupon
3193cd0 feature/coupon@{0}: commit: Add coupon codes
5f738de feature/coupon@{1}: branch: Created from HEAD
$ git reflog show --date=iso -3 main
3db278b main@{2026-01-15 10:11:00 +0600}: commit: Update README
5f738de main@{2026-01-15 10:03:00 +0600}: commit: Add discount rule
3457a7b main@{2026-01-15 10:01:00 +0600}: commit: Add cart total

HEAD-এর খাতায় HEAD@{1}: reset: moving to HEAD লাইনটি কোথা থেকে এলো? ওটি git stash push-এর কাজ: stash পরিবর্তন সরিয়ে রেখে ভেতরে ভেতরে working tree-কে HEAD-এর মতো করে দেয়, আর সেটিও একটি চলাচল হিসেবে লেখা হয়। main-এর খাতায় এসব নেই — main কখনো সরেনি। --date=iso দিলে নম্বরের বদলে সময় দেখায়। git reflog show আসলে git log -g --abbrev-commit --pretty=oneline-এর ছোট নাম (documentation-এ এভাবেই লেখা), তাই git log -g --format="%h %gd %gs" main-এর মতো নিজের ছাঁচও বানানো যায়: %gd হলো main@{n} আর %gs হলো কারণের লেখা।

Reflog-এর ঠিকানা লেখার নিয়ম

Reflog পড়ে commit বোঝানোর লেখাগুলোকে reflog selector বলা যায় — এগুলোও একধরনের revision, যেকোনো command-এ hash-এর জায়গায় বসে:

শেষ তিন সারির মান মিলিয়ে নিতে আমরা দুবার branch বদলে (feature/coupon-এ গিয়ে আবার main-এ ফিরে) আসল Git-কে জিজ্ঞেস করেছি:

$ git reflog -8
3db278b HEAD@{0}: checkout: moving from feature/coupon to main
3193cd0 HEAD@{1}: checkout: moving from main to feature/coupon
3db278b HEAD@{2}: commit: Update README
5f738de HEAD@{3}: reset: moving to HEAD
5f738de HEAD@{4}: checkout: moving from feature/coupon to main
3193cd0 HEAD@{5}: commit: Add coupon codes
5f738de HEAD@{6}: checkout: moving from main to feature/coupon
5f738de HEAD@{7}: commit: Add discount rule
$ for r in HEAD@{2} @{1} HEAD@{1} @{-1} @{-2}; do echo "$r = $(git rev-parse --short $r)"; done
HEAD@{2} = 3db278b
@{1} = 5f738de
HEAD@{1} = 3193cd0
@{-1} = 3193cd0
@{-2} = 3db278b
$ git rev-parse --abbrev-ref @{-1}
feature/coupon
$ git rev-parse --short 'main@{2026-01-15 10:02:00 +0600}'
3457a7b
$ git rev-parse --short 'main@{2026-01-15 09:00:00 +0600}'
warning: log for 'main' only goes back to Thu, 15 Jan 2026 10:00:00 +0600
df9c5fe

সবচেয়ে বেশি ভুল হয় দ্বিতীয় আর তৃতীয় লাইনে: @{1} = 5f738de কিন্তু HEAD@{1} = 3193cd0. HEAD-এর খাতায় এক ধাপ আগে আপনি feature/coupon-এ দাঁড়িয়ে ছিলেন; main-এর খাতায় এক ধাপ আগে main ছিল 5f738de-এ। ভুল reset --hard-এর পর main@{1} প্রায়ই HEAD@{1}-এর চেয়ে নির্ভরযোগ্য, কারণ মাঝখানে branch বদলালেও main-এর খাতায় সেই লাইন আসে না। আর খাতার শুরুর আগের সময় চাইলে Git একটি সতর্কবার্তা দিয়ে সবচেয়ে পুরোনো entry-টিই দেয়। main@{yesterday} ধরনের লেখা আপনার যন্ত্রের এখনকার ঘড়ি থেকে হিসাব হয়, তাই একই command আজ আর কাল ভিন্ন ফল দিতে পারে।

@{-1} কীভাবে খোঁজা হয় — ধাপে ধাপে

git switch - আর git checkout - আসলে @{-1}-এর সংক্ষেপ। Git এটি বের করে HEAD-এর খাতার “checkout: moving from X to Y” লাইনগুলো পড়ে। ওপরের আসল git reflog -8 ধরে দেখা যাক:

একই নিয়ম একটি ছোট resolver-এ লেখা হলো। ডেটা ওপরের আসল reflog থেকে কপি করা; সময়গুলো শুধু ঘণ্টা:মিনিট, তুলনা সহজ রাখতে:

// Resolve @{n}, @{-n}, ref@{n} and ref@{date} over a recorded reflog (copied from a real repo).
const HEAD_LOG = [                       // newest first, like `git reflog`
  "3db278b checkout: moving from feature/coupon to main", "3193cd0 checkout: moving from main to feature/coupon",
  "3db278b commit: Update README", "5f738de reset: moving to HEAD",
  "5f738de checkout: moving from feature/coupon to main", "3193cd0 commit: Add coupon codes",
  "5f738de checkout: moving from main to feature/coupon", "5f738de commit: Add discount rule"];
const LOGS = { HEAD: HEAD_LOG.map(l => ({ id: l.slice(0, 7), msg: l.slice(8) })),
  main: [["3db278b", "10:11"], ["5f738de", "10:03"], ["3457a7b", "10:01"], ["df9c5fe", "10:00"]]
          .map(([id, at]) => ({ id, at })),
  "feature/coupon": [{ id: "3193cd0", at: "10:04" }, { id: "5f738de", at: "10:04" }] };
const current = "main";                  // HEAD -> refs/heads/main
function resolve(expr) {
  let m = expr.match(/^(.*)@\{(-?)(.+)\}$/);
  if (!m) return LOGS[expr] ? LOGS[expr][0].id : expr;
  let [, ref, minus, arg] = m;
  if (minus) {                           // @{-n}: n-th branch checked out before this one
    const from = LOGS.HEAD.map(e => e.msg.match(/^checkout: moving from (\S+) to/)).filter(Boolean);
    const name = from[Number(arg) - 1][1];
    return `${name} -> ${resolve(name)}`;
  }
  if (ref === "") ref = current;         // bare @{n} means the CURRENT BRANCH's reflog, not HEAD's
  const log = LOGS[ref];
  if (/^\d+$/.test(arg)) return log[Number(arg)].id;
  const e = log.find(x => x.at <= arg);  // time: newest entry at or before that moment
  return e ? e.id : log[log.length - 1].id + "  (log only goes back to " + log[log.length - 1].at + ")";
}
for (const x of ["HEAD@{0}", "HEAD@{1}", "HEAD@{2}", "@{1}", "main@{2}", "@{-1}", "@{-2}",
                 "main@{10:05}", "main@{10:02}", "main@{09:00}", "feature/coupon@{1}"])
  console.log(x.padEnd(19), "=", resolve(x));

HEAD@{0}            = 3db278b
HEAD@{1}            = 3193cd0
HEAD@{2}            = 3db278b
@{1}                = 5f738de
main@{2}            = 3457a7b
@{-1}               = feature/coupon -> 3193cd0
@{-2}               = main -> 3db278b
main@{10:05}        = 5f738de
main@{10:02}        = 3457a7b
main@{09:00}        = df9c5fe  (log only goes back to 10:00)
feature/coupon@{1}  = 5f738de

৫ · Reachability আর garbage collection — Git আসলে কী মোছে

একটি commit-এর তিন রকম অবস্থা হতে পারে, আর পুরো উদ্ধারবিদ্যা এই তিনটি চেনার ওপর দাঁড়িয়ে:

“পৌঁছানো যায়” মানে একটি graph traversal: সব ref-কে শুরুর বিন্দু ধরে commit-এর parent, commit-এর tree, tree-এর ভেতরের blob — এভাবে তীর ধরে যতদূর যাওয়া যায় (DSA কোর্সের DFS-এর সরাসরি প্রয়োগ)। যা ছোঁয়া হলো না, তা “অনাথ”। এটি প্রোগ্রামিং ভাষার garbage collector-এর mark-and-sweep-এর মতো (JavaScript কোর্সে memory), শুধু একটি বড় পার্থক্য: Git অনাথ পেলেই মোছে না, আগে একটি অনুগ্রহকাল (grace period) দেয়।

তিন সময়সীমা

ডিফল্টগুলো Git ২.৫৩-এর documentation থেকে নেওয়া; version বা আপনার config-ভেদে আলাদা হতে পারে, তাই নিশ্চিত হতে git help gc আর git config --get gc.reflogExpire দেখুন (কিছু না এলে ডিফল্ট চলছে)। gc.<pattern>.reflogExpire দিয়ে নির্দিষ্ট ref-এর জন্য আলাদা মেয়াদও দেওয়া যায়, যেমন refs/stash-এর জন্য। git gc চালালে মোটামুটি এই ক্রমে কাজ হয়: ref গুছিয়ে packed-refs-এ তোলা, git reflog expire দিয়ে মেয়াদোত্তীর্ণ entry ছাঁটা, পৌঁছানো যায় এমন object-গুলো pack-এ তোলা, আর শেষে git prune-এর মতো ধাপে বয়স্ক অনাথ object মোছা। সাম্প্রতিক Git অনাথ object-গুলো আলাদা একটি “cruft pack”-এ রাখতে পারে, যেখানে প্রতিটির বয়স আলাদা লেখা থাকে — মেয়াদের নিয়ম একই থাকে।

আপনি কখনো garbage collection না চালালেও Git নিজে চালায়: commit, merge, fetch-এর মতো কিছু command শেষে Git git gc --auto চালিয়ে দেখে কাজ জমেছে কি না। ডিফল্টে ৬৭০০-র বেশি loose object (gc.auto) বা ৫০-এর বেশি pack (gc.autoPackLimit) হলে তবেই আসল gc চলে। নতুন Git-এ git maintenance এই দায়িত্বের কিছু অংশ নিয়েছে। মোদ্দা কথা: উদ্ধারের সময় আপনার হাতে কয়েক সপ্তাহ থাকে, কিন্তু তা নিশ্চিত নয় — কাজেই হারানো commit পেলে প্রথমেই একটি branch বসিয়ে তাকে reachable করুন।

একটি commit-এর জীবন: reachable থেকে মুছে যাওয়া

আসল প্রমাণ দেখতে একটি throwaway repository বানানো হলো। আমাদের উদাহরণের তারিখ পুরোনো (জানুয়ারি ২০২৬) আর এই যন্ত্রের ঘড়ি অক্টোবর ২০২৬, তাই তারিখের প্রভাব সরাতে প্রথমে দুই মেয়াদ never করা হলো — এতে ফল পাঠকের যন্ত্রের তারিখের ওপর নির্ভর করবে না:

$ git config gc.reflogExpire never
$ git config gc.reflogExpireUnreachable never
$ git log --oneline
e61471e Throw me away
947c1bf Keep me
$ git reset -q --hard HEAD~1
$ git reflog
947c1bf HEAD@{0}: reset: moving to HEAD~1
e61471e HEAD@{1}: commit: Throw me away
947c1bf HEAD@{2}: commit (initial): Keep me
$ git cat-file -t e61471e
commit
$ git fsck --unreachable
$ git fsck --unreachable --no-reflogs
unreachable commit e61471eda279d29ebafbb7ebdec7ef3fd0d38d28
unreachable blob f3d43775e65ac68c0589a8961c9e665ee8436944
unreachable tree d3913310880cad05f75019555a3dfbd5c61b0149
$ git gc --prune=now -q
$ git cat-file -t e61471e
commit
$ git reflog expire --expire-unreachable=now --all
$ git reflog
947c1bf HEAD@{0}: commit (initial): Keep me
$ git gc --prune=now -q
$ git cat-file -t e61471e
fatal: Not a valid object name e61471e
$ git count-objects -v
count: 0
size: 0
in-pack: 3
packs: 1
…

$ git reflog
947c1bf HEAD@{0}: reset: moving to HEAD~1
e61471e HEAD@{1}: commit: Throw me away
947c1bf HEAD@{2}: commit (initial): Keep me
$ git gc --prune=now -q
$ git reflog
$ git cat-file -t e61471e
fatal: Not a valid object name e61471e

নিচের মডেলে ছয়টি commit-এর একটি ছোট history; প্রতিটি object কবে লেখা হয়েছিল আর reflog entry কবের, তা বলে দেওয়া আছে। তারপর তিনটি নির্দিষ্ট দিনে gc চালানো হয় — ডিফল্ট তিন সময়সীমা মেনে। (সরলতার জন্য মডেলে “পৌঁছানো যায়” মানে যেকোনো ref থেকে; আসল Git প্রতিটি খাতার নিজের ref-এর মাথা ধরে দেখে।)

// Reachability + gc expiry. Dates are stated, so the run is the same every time.
const DAY = 86400000, t = s => Date.parse(s + "T10:00:00+06:00");
const parentOf = { A: null, B: "A", C: "B", D: "C", X: "D", S: "C" };     // commit DAG
const born = { A: "2026-01-01", B: "2026-01-02", C: "2026-01-03",
               D: "2026-01-04", S: "2026-01-05", X: "2026-01-06" };     // object write date
const refs = { "refs/heads/main": "D" };                                // X: reset away; S: dropped stash
let reflog = [ { ref: "main", id: "A", at: "2026-01-01" }, { ref: "main", id: "B", at: "2026-01-02" },
  { ref: "main", id: "C", at: "2026-01-03" }, { ref: "main", id: "D", at: "2026-01-04" },
  { ref: "HEAD", id: "X", at: "2026-01-06" } ];                         // stash entry already dropped
let objects = Object.keys(parentOf);
function walk(tips) {                                                   // follow parent arrows
  const seen = new Set();
  for (let c of tips) while (c && !seen.has(c)) { seen.add(c); c = parentOf[c]; }
  return seen;
}
function classify() {
  const live = walk(Object.values(refs)), logged = walk(reflog.map(e => e.id));
  const pick = f => objects.filter(f).join(" ") || "-";
  console.log("  reachable from refs :", pick(c => live.has(c)));
  console.log("  reflog-only         :", pick(c => !live.has(c) && logged.has(c)));
  console.log("  unreachable         :", pick(c => !live.has(c) && !logged.has(c)));
}
function gc(now) {                         // like git gc: expire reflog, then prune old garbage
  const live = walk(Object.values(refs)), age = s => (t(now) - t(s)) / DAY;
  reflog = reflog.filter(e => age(e.at) < (live.has(e.id) ? 90 : 30)); // reflogExpire / ...Unreachable
  const keep = walk([...Object.values(refs), ...reflog.map(e => e.id)]);
  const gone = objects.filter(c => !keep.has(c) && age(born[c]) > 14);  // gc.pruneExpire: 2 weeks
  objects = objects.filter(c => !gone.includes(c));
  console.log(`gc on ${now}: reflog entries left ${reflog.length}, pruned: ${gone.join(" ") || "none"}`);
}
console.log("before any gc:"); classify();
for (const day of ["2026-01-10", "2026-02-10", "2026-04-10"]) { gc(day); classify(); }

before any gc:
  reachable from refs : A B C D
  reflog-only         : X
  unreachable         : S
gc on 2026-01-10: reflog entries left 5, pruned: none
  reachable from refs : A B C D
  reflog-only         : X
  unreachable         : S
gc on 2026-02-10: reflog entries left 4, pruned: X S
  reachable from refs : A B C D
  reflog-only         : -
  unreachable         : -
gc on 2026-04-10: reflog entries left 0, pruned: none
  reachable from refs : A B C D
  reflog-only         : -
  unreachable         : -

৬ · git fsck — হারানো object খোঁজার যন্ত্র

“fsck” নামটি এসেছে Unix-এর file system check থেকে — ডিস্ক বিপর্যয়ের পর ফাইল সিস্টেম যাচাইয়ের টুল (Operating Systems কোর্সে দেখেছেন)। git fsck-এর প্রধান কাজও যাচাই: প্রতিটি object ঠিকঠাক আছে কি না, প্রতিটি তীর কোনো আসল object-এ পৌঁছায় কি না। কিন্তু সেই কাজ করতে গিয়ে সে জেনে যায় কোন object কারও সাথে যুক্ত নয় — আর সেটিই উদ্ধারের সোনার খনি। তিনটি শব্দ আলাদা করে চিনুন:

• Unreachable: কোনো ref (আর ডিফল্টভাবে কোনো reflog entry) থেকে পৌঁছানো যায় না এমন যেকোনো object. git fsck --unreachable সবগুলো দেখায়।
• Dangling: unreachable-দের মধ্যে যাদের অন্য কোনো unreachable object-ও দেখায় না — হারানো স্তূপের “মাথা”। শুধু git fsck ডিফল্টভাবে এগুলোই দেখায়।
• Lost-found: git fsck --lost-found dangling object-গুলো .git/lost-found/-এ লিখে দেয় — commit-এর নাম commit/-এ, আর blob-এর পুরো লেখা other/-এ ফাইল হিসেবে।

একটি drop করা stash দিয়ে পার্থক্যটি পরিষ্কার হয়। একটি stash আসলে দুটি commit: একটি “index commit” (stage করা অবস্থা) আর একটি “working tree commit”, যার দুই parent — HEAD আর সেই index commit (বিস্তারিত পর্ব ৫৬-এ)। Drop করার পর:

$ git stash drop
Dropped refs/stash@{0} (7212405518b426de49689c31e3d2558d6855a0c4)
$ git fsck --unreachable
unreachable commit 1330d813af1504f305f95c343ac9423abc2c3960
unreachable blob 69cb0c298a2e0b52ee1e024cdd1b3bb542bec848
unreachable tree acbc0278ae83133fa3754529b6b242c1edf3d9fa
unreachable commit 7212405518b426de49689c31e3d2558d6855a0c4
$ git fsck
dangling commit 7212405518b426de49689c31e3d2558d6855a0c4

--unreachable চারটি object দেখাল: দুই commit, stash-এর tree আর তার ভেতরের README-র নতুন রূপের blob. সাধারণ git fsck দেখাল শুধু একটি — 7212405, কারণ বাকি তিনটিকে সে নিজেই দেখায় (index commit তার parent, tree তার snapshot, blob সেই tree-র ভেতরে)। একটি সূত্র ধরলেই পুরো স্তূপ উঠে আসে — তাই dangling তালিকাই সাধারণত যথেষ্ট।

Stage করা কিন্তু হারানো ফাইল — dangling blob

এবার সবচেয়ে কৌতূহলজাগানো উদ্ধার। আপনি নতুন pay.js লিখে git add করেছেন, commit করেননি, তারপর ভুল করে git reset --hard. ফাইলটি ফোল্ডার থেকে উধাও — নতুন ফাইল ছিল, HEAD-এ নেই, তাই reset সেটি সরিয়ে দিয়েছে। কোনো commit নেই, তাই reflog-এ কিছু নেই। কিন্তু git add-এর মুহূর্তে Git ফাইলের লেখাটি একটি blob হিসেবে object store-এ লিখেছিল (পর্ব ৫২):

$ git add pay.js
$ git reset --hard
HEAD is now at 3db278b Update README
$ ls
README.md
cart.js
discount.js
$ git fsck --lost-found
dangling blob 83cb0fbc58b8e514b3f2e118dcfbfe4234a11bc7
$ ls .git/lost-found/*
83cb0fbc58b8e514b3f2e118dcfbfe4234a11bc7
$ cat .git/lost-found/other/83cb0fbc58b8e514b3f2e118dcfbfe4234a11bc7
function pay(method) {
  return method === "bkash" ? "ok" : "unsupported";
}

ফাইলের লেখা পুরোটাই ফিরল। কিন্তু খেয়াল করুন কী ফেরেনি: ফাইলের নাম। Blob শুধু লেখা রাখে; নাম থাকে tree-তে, আর কোনো tree তৈরিই হয়নি। তাই অনেকগুলো dangling blob থাকলে grep -l "মনে থাকা কোনো শব্দ" .git/lost-found/other/* দিয়ে খুঁজে নিতে হয়, তারপর cp করে সঠিক নামে রাখতে হয়। আর যদি add-এর পর ফাইলটি আরও বদলে থাকেন, শেষ বদলগুলো ফেরে না — ফেরে শুধু শেষবার add করা রূপ।

৭ · উদ্ধারের রেসিপি — ছয়টি পরিচিত বিপদ

সব রেসিপির প্রথম ধাপ একই, রান্নাঘরের রেসিপি খাতার “চুলা বন্ধ করুন”-এর মতো: থামুন. নতুন commit, reset, checkout বা gc নয় — প্রতিটি নতুন চলাচল reflog-এর নম্বর বদলায়, আর gc প্রমাণ মুছতে পারে। git status দেখে লিখে রাখুন কী অসংরক্ষিত আছে। তারপর:

রেসিপি ১ — মোছা branch

$ git branch -D feature/coupon
Deleted branch feature/coupon (was 3193cd0).
$ git reflog show feature/coupon
fatal: ambiguous argument 'feature/coupon': unknown revision or path not in the working tree.
…
$ git reflog | grep coupon
3db278b HEAD@{0}: checkout: moving from feature/coupon to main
3193cd0 HEAD@{1}: checkout: moving from main to feature/coupon
5f738de HEAD@{4}: checkout: moving from feature/coupon to main
3193cd0 HEAD@{5}: commit: Add coupon codes
5f738de HEAD@{6}: checkout: moving from main to feature/coupon
$ git branch feature/coupon 3193cd0
$ git log --oneline -1 feature/coupon
3193cd0 Add coupon codes

প্রথম সূত্র মোছার বার্তাতেই: (was 3193cd0). Terminal-এ সেটি না থাকলে মনে রাখুন — branch মুছলে তার নিজের reflog-ও মুছে যায় (files backend-এ; তাই git reflog show feature/coupon ব্যর্থ)। কিন্তু HEAD-এর খাতা থাকে, আর সেখানে branch-এ ঢোকা-বেরোনোর লাইনে নাম লেখা আছে। “moving from feature/coupon to main” লাইনের hash হলো main-এর, তাই সঠিক hash নিতে হয় “commit: Add coupon codes” বা “moving from main to feature/coupon” লাইন থেকে। Branch-এ কখনো checkout না করে থাকলে (যেমন অন্যের branch fetch করে মুছেছেন) HEAD-এর খাতায় কিছু থাকবে না; তখন git fsck-এর dangling commit বা remote-ই ভরসা।

রেসিপি ২ — ভুল reset --hard

$ git reset --hard HEAD~2
HEAD is now at 3457a7b Add cart total
$ git reflog show main -2
3457a7b main@{0}: reset: moving to HEAD~2
3db278b main@{1}: commit: Update README
$ git reset --hard main@{1}
HEAD is now at 3db278b Update README
$ git log --oneline -3
3db278b Update README
5f738de Add discount rule
3457a7b Add cart total

এখানে branch-এর নিজের খাতা (main@{1}) ব্যবহার করেছি, অংশ ৪-এর যুক্তিতে। Working tree-তে অসংরক্ষিত কাজ থাকলে --hard-এর আগে git branch rescue main@{1} দিয়ে commit-টিকে বাঁধুন, তারপর ভেবেচিন্তে এগোন (পর্ব ১১-এর পুরো ধাপ)।

রেসিপি ৩ — ভাঙা rebase

Rebase শেষ হওয়ার পরপরই যদি বোঝেন ভুল হয়েছে, ORIG_HEAD rebase-এর আগের মাথা দেখায় — পর্ব ১৫-এ দেখেছেন। কিন্তু মাঝখানে আরেকটি reset বা merge চললে সেটি ওপরে লেখা হয়ে যায়। তখন branch-এর খাতা দেখুন: rebase শেষে branch-এর খাতায় একটিই লাইন যোগ হয়, “rebase (finish): refs/heads/<branch> onto …”, আর তার ঠিক নিচের লাইন (<branch>@{1}) rebase-এর আগের মাথা। HEAD-এর খাতায় বরং “rebase (start)”, “rebase (pick)” ধরনের অনেক লাইন থাকে — সেখানে গুনে নম্বর বের করা ভুলপ্রবণ।

রেসিপি ৪ — drop করা stash

Stash-এর reflog-ই তার তালিকা, তাই drop বা clear করা stash-এর কোনো ref-ও নেই, reflog-ও নেই। ভরসা fsck:

$ git stash list
stash@{0}: On main: wip readme
$ git stash drop
Dropped refs/stash@{0} (7212405518b426de49689c31e3d2558d6855a0c4)
$ git fsck --unreachable | grep commit
unreachable commit 1330d813af1504f305f95c343ac9423abc2c3960
unreachable commit 7212405518b426de49689c31e3d2558d6855a0c4
$ git log -1 --format="%h %p %s" 7212405
7212405 5f738de 1330d81 On main: wip readme
$ git stash show -p 7212405518b426de49689c31e3d2558d6855a0c4
diff --git a/README.md b/README.md
index f1fcb3e..69cb0c2 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,2 @@
 # Bazar app
+- cart total
$ git stash store -m "wip readme (recovered)" 7212405
$ git stash list
stash@{0}: wip readme (recovered)

রেসিপি ৫ — add করে হারানো ফাইল

অংশ ৬-এর git fsck --lost-found: .git/lost-found/other/-এ blob-এর লেখা, নাম নিজে দিতে হবে। কাজ শেষে .git/lost-found ফোল্ডারটি মুছে দিতে পারেন; এটি শুধু একটি সুবিধার কপি।

রেসিপি ৬ — amend-এ হারানো commit

$ git commit -q --amend -m "Update README (cart, discount)"
$ git log -g -2 --format="%h %gd %gs"
a462d18 HEAD@{0} commit (amend): Update README (cart, discount)
3db278b HEAD@{1} reset: moving to HEAD
$ git branch before-amend HEAD@{1}
$ git log --oneline -1 before-amend
3db278b Update README

লক্ষ করুন, HEAD@{1}-এর কারণের লেখা “reset: moving to HEAD” (আগের রেসিপির reset --hard), “commit” নয় — কিন্তু hash-টি ঠিকই amend-এর আগের commit. কারণের লেখা বলে কীভাবে সেখানে পৌঁছেছিলেন; উদ্ধারে দরকার কোথায় ছিলেন। সেজন্য বার্তা নয়, hash আর git log দেখে নিশ্চিত হোন।

ছয়টি রেসিপি একটি খেলনা “পরিকল্পনাকারী”-তে সাজানো হলো — কোনো পরিস্থিতির নাম দিলে command-এর ক্রম ছাপে, আর অচেনা পরিস্থিতিতে অনুমান না করে মানুষকে জিজ্ঞেস করতে বলে:

// Toy recovery planner: scenario keyword -> the safe command recipe (read before you run!).
const FIRST = "git status   # stop; note what is unsaved before anything else";
const RECIPES = {
  "deleted-branch": ["git reflog | grep <branch-name>     # its own reflog died with it",
                     "git branch <branch-name> <hash>    # hash also in 'Deleted branch ... (was ...)'"],
  "reset-hard":     ["git reflog show <branch> -5        # entry 1 = tip before the reset",
                     "git branch rescue <branch>@{1}", "git reset --hard rescue   # only if tree is clean"],
  "bad-rebase":     ["git branch rescue ORIG_HEAD        # if no reset/merge ran since",
                     "git reflog show <branch> -3        # else: entry 1 = tip before 'rebase (finish)'"],
  "dropped-stash":  ["git fsck --unreachable | grep commit",
                     "git log -1 --format='%h %p %s' <hash>   # stash = 2 parents, 'On <branch>: ...'",
                     "git stash store -m 'recovered' <hash>"],
  "staged-file":    ["git fsck --lost-found              # blobs land in .git/lost-found/other/",
                     "grep -l '<text you remember>' .git/lost-found/other/*"],
  "amended":        ["git reflog -3                      # 'commit (amend)' then the old commit",
                     "git branch before-amend HEAD@{1}"],
  "never-added":    null,                                 // Git never saw it
};
function plan(scenario) {
  console.log(`# ${scenario}`);
  const steps = RECIPES[scenario];
  if (steps === undefined) return console.log("  unknown scenario - describe it to a human first\n");
  if (steps === null) return console.log("  not recoverable with Git: never added or committed.\n" +
                                         "  Try your editor's local history; commit early next time.\n");
  [FIRST, ...steps].forEach((s, i) => console.log(`  ${i + 1}. ${s}`));
  console.log("  last: git log --oneline -3 <result>   # verify, then delete rescue branches\n");
}
["dropped-stash", "reset-hard", "never-added", "force-pushed-by-colleague"].forEach(plan);

# dropped-stash
  1. git status   # stop; note what is unsaved before anything else
  2. git fsck --unreachable | grep commit
  3. git log -1 --format='%h %p %s' <hash>   # stash = 2 parents, 'On <branch>: ...'
  4. git stash store -m 'recovered' <hash>
  last: git log --oneline -3 <result>   # verify, then delete rescue branches

# reset-hard
  1. git status   # stop; note what is unsaved before anything else
  2. git reflog show <branch> -5        # entry 1 = tip before the reset
  3. git branch rescue <branch>@{1}
  4. git reset --hard rescue   # only if tree is clean
  last: git log --oneline -3 <result>   # verify, then delete rescue branches

# never-added
  not recoverable with Git: never added or committed.
  Try your editor's local history; commit early next time.

# force-pushed-by-colleague
  unknown scenario - describe it to a human first

৮ · যা ফেরে না, আর আগেভাগে নিজেকে রক্ষা

সব উদ্ধারের একটি শর্ত: জিনিসটি কোনো সময় Git-এর object store-এ ঢুকেছিল। এই সীমারেখা পরিষ্কার জানা থাকলে আতঙ্ক কমে, আর অভ্যাসও বদলায়।

Server-এ reflog — আছে কি নেই?

Reflog local; push বা clone হয় না, নতুন clone-এ খাতা খালি শুরু হয়। Bare repository-তে (যেমন একটি server-এর repository) ডিফল্টভাবে reflog লেখাই হয় না — core.logAllRefUpdates-এর ডিফল্ট সাধারণ repository-তে চালু, bare-এ বন্ধ। নিজের server হলে এটি চালু করা যায়। বড় hosting platform-গুলো force push বা মোছা branch নিয়ে নিজস্ব হিসাব, activity log বা সহায়তা রাখতে পারে, কিন্তু কী থাকে, কতদিন থাকে আর কীভাবে ফেরানো যায় — তা platform-ভেদে আলাদা আর লেখার সময়ের পরে বদলাতে পারে; প্রয়োজনের আগেই নিজের platform-এর documentation পড়ে রাখুন।

আগেভাগে রক্ষার অভ্যাস

1. ঝুঁকির কাজের আগে backup branch: git branch backup/before-rebase — দুই সেকেন্ডের কাজ, কোনো মেয়াদ নেই, gc-ও ছোঁয় না। কাজ শেষে মুছে দিন।
2. ঘনঘন ছোট commit: নিজের branch-এ “WIP” commit লজ্জার নয়; পরে interactive rebase-এ গুছিয়ে নিন (পর্ব ১৫)। Commit করা কাজই Git বাঁচাতে পারে।
3. Force push শুধু --force-with-lease: server-এ এমন কিছু থাকলে যা আপনি দেখেননি, push থেমে যায় (পর্ব ১৪)। দলের main-এ force push platform-এর সেটিং দিয়ে বন্ধ রাখুন (পর্ব ১৭)।
4. Stash দীর্ঘমেয়াদি গুদাম নয়: কয়েক দিনের বেশি রাখতে হলে একটি branch-এ commit করুন। git stash clear এক আঘাতে সব মোছে।
5. উদ্ধারের সময় gc নয়: git gc --prune=now বা git reflog expire --expire=now প্রমাণ মুছে দেয়। এগুলো ইচ্ছাকৃত পরিষ্কারের হাতিয়ার — যেমন ফাঁস হওয়া secret history থেকে সরানোর শেষ ধাপে (পর্ব ৫৭)।
6. Script-এ ref ফাইল নয়, command: git rev-parse, git for-each-ref, git update-ref — files বা reftable, দুই backend-এই ঠিক চলে। CI pipeline-এ (পর্ব ৫৮) প্রায়ই shallow clone থাকে, যেখানে পুরো history বা reflog নেই — সেখানে এই পর্বের উদ্ধার কৌশল খাটবে না।

৯ · AI-এর যুগে — উদ্ধারের পরামর্শ যাচাই

কিছু হারালে মানুষ ভয় পায়, আর ভয়ের মুহূর্তে AI-এর আত্মবিশ্বাসী উত্তর খুব আকর্ষণীয়। কিন্তু উদ্ধারের ক্ষেত্রে একটি ভুল command পুরো সুযোগটাই শেষ করে দিতে পারে — বিশেষ করে “repository পরিষ্কার করুন” ধাঁচের পরামর্শ। এই বিষয়ে AI-এর পরিচিত ভুলগুলো:

AI-এর উদ্ধার-পরামর্শ চালানোর আগে — চেকলিস্ট

• পরামর্শে gc, prune, reflog expire বা clean নেই — থাকলে থেমেছি
• প্রথম ধাপেই হারানো commit-এ একটি branch বসানো হয়েছে
• প্রতিটি selector (HEAD@{n}, main@{n}) git log -1 দিয়ে মিলিয়েছি
• প্রতিটি command আর flag git help-এ আছে — বানানো নয়
• --hard চালানোর আগে git status পরিষ্কার, বা পুরো ফোল্ডারের কপি নিয়েছি
• শেষে git log আর git diff দেখে নিশ্চিত হয়েছি যে ঠিক যা চেয়েছি তাই ফিরেছে