دو commit از دید log ناپدید شدندTwo commits vanished from log

دیروز سه commit روی main داشتی. امروز با عجله زدی git reset --hard HEAD~2. حالا git log --oneline فقط commit پایه را نشان می‌دهد. همکارت می‌گوید: «تاریخچه پاک شد.» آیا واقعاً commitها حذف شده‌اند، یا فقط نامی که به آن‌ها می‌رسید جابه‌جا شده؟

Yesterday, main had three commits. In a hurry today, you ran git reset --hard HEAD~2. Now git log --oneline shows only the base commit. A teammate says, “The history was deleted.” Were the commits actually erased, or did only the name that reached them move?

فصل ۰۹ یاد داد reset شاخه را حرکت می‌دهد و --hard فایل‌های ردیابی‌شده را هم با مقصد جور می‌کند. اما شیءهای commit ممکن است هنوز در مخزن باشند. حالا باید سرنخ درست را بخوانیم: git reflog.

Chapter 09 showed that reset moves a branch and --hard also makes tracked files match the target. The commit objects may still be in the repository. Now we need the right clue: git reflog.

reflog دفترچهٔ حرکت نام‌هاستA reflog is a journal of ref movements

Git یک شاخه را به‌صورت نامی می‌بیند که به commit اشاره می‌کند. هر بار آن اشاره‌گر در مخزن محلی حرکت کند، reflog معمولاً ردّ حرکت قبلی و تازه را ثبت می‌کند. HEAD هم reflog خودش را دارد؛ برای همین رفت‌وآمد میان شاخه‌ها و commitهای جداشده اغلب سرنخ می‌گذارد.

Git treats a branch as a name pointing to a commit. When that pointer moves in a local repository, a reflog usually records the old and new positions. HEAD has its own reflog too, which is why branch switches and detached-HEAD commits often leave clues.

HEAD@{0} یعنی آخرین جایگاه ثبت‌شدهٔ HEAD؛ HEAD@{1} جایگاه قبلی در دفترچه. این عدد، شمارهٔ والد commit نیست. برای حرکت در زنجیرهٔ والدها از HEAD~1 استفاده می‌کنی. این دو نحو شبیه هم‌اند ولی یک سؤال را جواب نمی‌دهند.

HEAD@{0} means the latest recorded position of HEAD; HEAD@{1} is the previous reflog position. That number is not a commit-parent number. Use HEAD~1 to walk to a parent. The syntax looks similar, but the questions differ.

آزمایش امن: commitها را به مسیر برگردانSafe experiment: bring commits back into reach

این فرمان مخرب را فقط در مخزن تمرینی تازه اجرا کن. سه commit می‌سازیم، عمداً main را دو قدم عقب می‌بریم و بعد با خواندن reflog یک شاخه نجات می‌سازیم. قبل از شروع، پوشهٔ جداگانه انتخاب کن.

Run this destructive command only in a fresh practice repository. We will make three commits, deliberately move main back two steps, then use the reflog to create a rescue branch. Start in a separate disposable folder.

mkdir reflog-lab
cd reflog-lab
git init -b main
git config user.name "Reflog Learner"
git config user.email reflog@example.test
printf 'A\n' > notes.txt
git add notes.txt
git commit -m "A: baseline"
printf 'B\n' >> notes.txt
git commit -am "B: add second line"
printf 'C\n' >> notes.txt
git commit -am "C: add third line"
git log --oneline --decorate -3

خروجی log را نگه دار؛ شناسهٔ کامل commit C را هم با git rev-parse HEAD ثبت کن. حالا پیش‌بینی کن بعد از reset چه چیزی در log می‌ماند و فایل روی دیسک چه محتوایی خواهد داشت.

Keep the log output and record C's full ID with git rev-parse HEAD. Predict what will remain in log and what the disk file will contain after the reset.

git reset --hard HEAD~2
git log --oneline --decorate
git status --short
cat notes.txt
git reflog

a1a1a1a HEAD@{0}: reset: moving to HEAD~2
c3c3c3c HEAD@{1}: commit: C: add third line
b2b2b2b HEAD@{2}: commit: B: add second line
a1a1a1a HEAD@{3}: commit (initial): A: baseline

حالا باید main روی A باشد و فایل هم فقط خط A را داشته باشد؛ این را reset واقعاً انجام داده. در reflog دنبال رویداد reset: moving to HEAD~2 بگرد. ثبت قبلی معمولاً C را نشان می‌دهد. به شمارهٔ ثابت تکیه نکن؛ پیام، زمان، شناسه و نتیجهٔ git show را با هم بسنج.

Now main should point to A and the file should contain only line A; reset really did that. In the reflog, find reset: moving to HEAD~2. The preceding entry commonly identifies C. Do not trust a memorised index: compare the message, time, ID, and git show.

git show --stat --oneline <C_ID_FROM_REFLOG>
git branch rescue/after-reset <C_ID_FROM_REFLOG>
git show-ref --verify refs/heads/rescue/after-reset
git log --oneline --decorate --all

شاخهٔ نجات را با شناسه‌ای بساز که واقعاً بررسی کرده‌ای. آخرین فرمان باید دوباره B و C را در گراف نشان دهد، اما main هنوز روی A است. حالا commitها از اشاره‌گر قابل‌دسترسی‌اند و می‌توانی با آرامش تصمیم بگیری ادامهٔ کار چه باشد؛ هنوز فایل‌های C را روی main نیاورده‌ای.

Create the rescue branch from the ID you actually inspected. The final command should show B and C in the graph again while main stays at A. The commits are now reachable through a ref, so you can decide what to do next; you have not yet brought C's files onto main.

شمارهٔ دفترچه را با شمارهٔ والد اشتباه نگیرDo not confuse journal positions with parent numbers

عبارت‌های زمانی را می‌توان مستقیم به دستور بدهی. برای نمونه git show 'HEAD@{1}' شیئی را نشان می‌دهد که HEAD در رویداد قبلی به آن اشاره می‌کرد؛ git show HEAD~1 والد commit فعلی را می‌خواند. برای تاریخ هم HEAD@{yesterday} ممکن است مفید باشد، اما نتیجه به ثبت‌های موجود و قالب زمان وابسته است.

You can pass time-based selectors directly to commands. For example, git show 'HEAD@{1}' displays the object HEAD pointed to at the previous event; git show HEAD~1 reads the current commit's parent. A date selector such as HEAD@{yesterday} can help too, but depends on available entries and date parsing.

اگر selector داخل PowerShell یا shell دیگری بد تفسیر شد، آن را داخل نقل‌قول بگذار؛ شکل نقل‌قول بسته به shell فرق دارد. قبل از ساختن rescue، شناسه را با git show --no-patch --format=fuller بررسی کن. reflogها می‌توانند با هر فرمان بعدی شماره‌گذاری تازه‌ای پیدا کنند.

If a selector is misread by PowerShell or another shell, quote it; quoting syntax varies by shell. Before creating a rescue ref, inspect the ID with git show --no-patch --format=fuller. Later commands can change reflog numbering.

اول اشاره‌گر نجات بساز، بعد دربارهٔ ادغام تصمیم بگیرCreate a rescue ref first; decide how to integrate later

اگر commit موردنظر را پیدا کردی، آن را فقط در ذهن نگه ندار. یک نام تازه به آن وصل کن تا دیگر صرفاً به ثبت موقت reflog وابسته نباشد. اول شناسه را ببین، بعد شاخه بساز، و در پایان مقصد شاخه را ثابت کن.

Once you find the commit, do not leave it only in your notes. Attach a new name so it is no longer dependent on a temporary reflog entry. Inspect the ID, create a branch, then verify its target.

git show --no-patch --format=fuller <OID>
git branch rescue/found-commit <OID>
git show-ref --verify refs/heads/rescue/found-commit
git log --oneline --decorate --all -5

این فرمان‌ها هیچ چیزی را از شاخهٔ فعلی پاک نمی‌کنند. اما «نجات» با «بازگرداندن فایل‌ها به main» یکی نیست؛ کار بعدی ممکن است مقایسه، cherry-pick یا ادغام باشد. تا وقتی هنوز مطمئن نیستی، اشاره‌گر نجات را نگه دار و مقصد را دست‌کاری نکن.

These commands do not remove anything from the current branch. But “rescue” is not the same as “put the files back on main”; the next step might be comparison, cherry-pick, or a merge. If uncertain, keep the rescue ref and leave the destination untouched.

شاخه پاک شده؛ اول دفترچهٔ HEAD را بخوانA branch was deleted; start with HEAD's journal

حذف شاخه معمولاً نامی را که به commit اشاره می‌کرد برمی‌دارد. reflog همان شاخه ممکن است همراهش پاک شود؛ پس فرض نکن git reflog show feature هنوز کار می‌کند. اگر قبل از حذف از شاخه بیرون آمده‌ای، reflog مربوط به HEAD می‌تواند رویداد آخرِ checkout و commitهای ساخته‌شده را نشان بدهد.

Deleting a branch removes the name that pointed to its commit. The branch's own reflog may be removed with it, so do not assume git reflog show feature still works. If you switched away before deleting it, HEAD's reflog can show the checkout and earlier commits.

git reflog --date=local
git reflog show --all --date=local
git show --stat --oneline <candidate-OID>
git branch rescue/deleted-feature <candidate-OID>
git show-ref --verify refs/heads/rescue/deleted-feature

اگر شاخه را در clone دیگری حذف کرده‌اند، reflog clone تو آن حرکت را ندارد؛ هر دفترچه محلی است. اگر هیچ رد مناسبی پیدا نشد، سراغ بخش شیءهای یتیم و git fsck برو. خروجی را با git show بررسی کن؛ صرف دیدن یک SHA دلیل نمی‌شود commit موردنظرت باشد.

If the branch was deleted in another clone, your reflog does not contain that event; each journal is local. If no useful entry appears, move to unreachable objects and git fsck. Inspect candidates with git show; seeing a SHA alone does not prove it is the commit you need.

rebase محلی نتیجهٔ بد داد؟ نوک شاخه قبلی را پیدا کنA local rebase went wrong? Find the previous tip

فصل ۰۷ نشان داد rebase commitهای تازه می‌سازد و شاخه را به آن‌ها می‌رساند. اگر نتیجه خراب شد، git reflog show topic را بخوان و رویدادهای rebase را پیدا کن. ممکن است قبل و بعد از بازپخش چند ثبت ببینی؛ شماره را از حفظ انتخاب نکن.

Chapter 07 showed that rebase creates replacement commits and moves the branch to them. If the result is wrong, inspect git reflog show topic and locate the rebase events. You may see several entries from before and after replay; do not choose an index from memory.

git reflog show topic --date=local
git show --stat --oneline <candidate-OID>
git log --oneline --graph --decorate --all --boundary -12
git branch rescue/topic-before-rebase <candidate-OID>
git show-ref --verify refs/heads/rescue/topic-before-rebase

شاخهٔ rescue فقط یک مقصد امن برای بررسی می‌سازد. حالا می‌توانی تغییرهای دو طرف را مقایسه کنی و با دانسته‌های فصل ۰۷ تصمیم بگیری. اگر کار را روی مخزن راه دور push کرده‌ای یا همکاران بر پایه‌اش commit ساخته‌اند، توقف کن و با تیم هماهنگ شو؛ بازیابی محلی مجوز push اجباری نیست.

The rescue branch creates a safe point for inspection. Now compare both lines and choose a next step using Chapter 07's model. If the work was pushed or teammates built on it, stop and coordinate; local recovery is not permission to force-push.

commit در جداشده HEAD گم به‌نظر می‌رسدA detached-HEAD commit appears lost

در فصل ۰۵ دیدی HEAD گاهی مستقیم به commit اشاره می‌کند، نه به نام branch. اگر آنجا commit بسازی و بعد به main برگردی، main آن commit را دنبال نمی‌کند. اما رویداد commit معمولاً در reflog مربوط به HEAD سرنخ می‌گذارد.

Chapter 05 showed that HEAD can point directly to a commit instead of naming a branch. A commit made there is not automatically followed by main when you switch back. But the commit event usually leaves a clue in HEAD's reflog.

git reflog --date=local
git show --stat --oneline <detached-commit-OID>
git branch rescue/detached-work <detached-commit-OID>
git log --oneline --decorate --all -8

بعد از ساخت شاخه، commit دیگر بی‌نام نیست. قبل از آنکه بگویی «فایل‌ها را برگرداندم»، با git show محتوای عکس فوری و با log والدش را بررسی کن. reflog کمک می‌کند نامزد را پیدا کنی؛ تصمیم اینکه این کار باید وارد کدام شاخه شود هنوز با توست.

After creating the branch, the commit is no longer unnamed. Before saying “the files are back,” inspect the snapshot with git show and its ancestry with log. The reflog helps locate a candidate; choosing which branch should receive it is still your decision.

محتوای ناحیه‌ آماده‌سازیشده ممکن است بماند، حتی وقتی reflog کمکی نمی‌کندStaged content may remain even when the reflog cannot help

فصل ۰۱ ثابت کرد git add محتوا را در پایگاه اشیا می‌نویسد. اگر بعداً آن محتوا از ناحیه‌ آماده‌سازی هم کنار برود، ممکن است blob بی‌نام و بی‌اشاره‌گر شود. reflog فقط حرکت اشاره‌گرها را می‌بیند، نه فهرست blobهای ساخته‌شده؛ برای جست‌وجوی شیء یتیم ابزار دیگری لازم است.

Chapter 01 demonstrated that git add writes content into the object database. If that content later leaves the index too, its blob may become unnamed and unreferenced. The reflog records ref movement, not a catalog of created blobs; a different tool is needed to search for unreachable objects.

بیا در همان reflog-lab یک فایل تازه بساز، نسخهٔ اول را ناحیه‌ آماده‌سازی کن و بعد محتوای دیگری را دوباره ناحیه‌ آماده‌سازی کن. فایل روی دیسک و ناحیه‌ آماده‌سازی حالا نسخهٔ دوم را دارند؛ نسخهٔ اول commit یا اشاره‌گر ندارد، اما ممکن است blob آن هنوز در پایگاه اشیا باشد:

In the disposable reflog-lab, create a new file, stage version one, then stage different content. The disk and index now hold version two; version one has no commit or ref, but its blob may still be in the object database:

printf 'draft version one\n' > scratch.txt
git add scratch.txt
printf 'draft version two\n' > scratch.txt
git add scratch.txt
git fsck --no-reflogs --unreachable

unreachable blob 8c9b2f1…

فقط گزینهٔ آزمایشیای را باز کن که نوعش blob است و محتوایش با نسخهٔ گمشده جور درمی‌آید. شناسه‌ها و شیءهای دیگر فرق می‌کنند. این راه ثابت نمی‌کند نام فایل یا نسخهٔ قبلیِ درست را یافته‌ای؛ آن را با یادداشت‌ها، diffها یا کپی دیگری تطبیق بده.

Inspect only a candidate whose type is blob and whose content matches the missing version. IDs and other objects vary. This does not prove you found the right filename or version; compare against notes, diffs, or another copy.

git fsck --no-reflogs --unreachable
git cat-file -t <candidate-OID>
git cat-file -p <candidate-OID>

این بررسی ممکن است commit، tree یا blobهای زیادی را نام ببرد؛ شناسهٔ هرکدام را اول با -t طبقه‌بندی کن. اگر blob متن است، cat-file -p محتوا را چاپ می‌کند، اما لزوماً نام فایل، مسیر یا رابطه‌اش با نسخهٔ قبلی را نمی‌داند. پیش از استخراج، خروجی را به فایل تازه و جدا هدایت کن؛ روی فایل فعلی ننویس.

This inspection may list many commits, trees, or blobs; classify each candidate with -t first. For a text blob, cat-file -p prints the content, but may not know its filename, path, or relationship to an earlier version. Before extracting anything, write it to a new separate file; do not overwrite current work.

stash هم اشاره‌گر محلی و reflog خودش را دارد و ممکن است با git reflog show refs/stash بررسی شود؛ جزئیات ساخت و اعمال stash را فصل ۱۱ یاد می‌گیریم. هیچ‌کدام از این راه‌ها تضمین ابدی نیستند: آنچه Git هرگز به شیء تبدیل نکرده، از reflog یا fsck ظاهر نمی‌شود.

A stash also has a local ref and reflog that you can inspect with git reflog show refs/stash; Chapter 11 will teach creating and applying stashes. None of these paths is an eternal guarantee: content Git never turned into an object will not appear in a reflog or fsck.

ORIG_HEAD سرنخ کمکی است، نه دفترچهٔ کاملORIG_HEAD is a clue, not a complete journal

برخی فرمان‌های بزرگ مثل reset، rebase یا merge ممکن است قبل از حرکت، جای قبلی HEAD را در ORIG_HEAD بگذارند. اما این نام همیشه وجود ندارد و عملیات بعدی می‌تواند آن را عوض کند. اگر هست، فقط بخوانش و با reflog و گراف تطبیق بده:

Some large operations such as reset, rebase, or merge may save the earlier HEAD in ORIG_HEAD. But it is not always present, and a later operation may replace it. If it exists, inspect it and compare it with the reflog and graph:

git show --no-patch --format=fuller ORIG_HEAD
git rev-parse --verify ORIG_HEAD
git reflog --date=local

اگر rev-parse خطا داد، این اشاره‌گر حاضر نیست؛ چیزی را خراب نکرده‌ای. اگر شناسه چاپ شد، هنوز باید commit و تغییرهایش را با git show بشناسی. آن را کورکورانه به reset --hard نده؛ ممکن است به‌روزرسانی تازه‌تری را کنار بزند.

If rev-parse fails, the ref is absent; you have not broken anything. If it prints an ID, still identify the commit and its changes with git show. Do not feed it blindly to reset --hard; that could discard newer work.

این دفترچه دائمی نیستThe journal is not permanent

reflog محلی است و زمان نگهداری‌اش تنظیم‌پذیر. در تنظیم پیش‌فرض نسخه‌های رایج Git، ردهای قابل‌دسترسی معمولاً تا ۹۰ روز و ردهای unreachable معمولاً تا ۳۰ روز نگه داشته می‌شوند؛ تنظیمات مخزن/کاربر و نسخه می‌توانند فرق کنند. این مهلت وعدهٔ بازیابی نیست و شیءها هم ممکن است با پاک‌سازی از بین بروند.

A reflog is local and its retention is configurable. In common Git defaults, reachable entries are generally kept for 90 days and unreachable entries for 30 days; repository/user configuration and versions can differ. These windows are not a recovery promise, and cleanup can eventually remove objects too.

برای خود شیءهای unreachable هم یک ساعت قطعی وجود ندارد. در مستندات فعلی، git gc معمولاً prune شیءهای جدا را با مهلت پیش‌فرض حدود دو هفته انجام می‌دهد؛ تنظیم gc.pruneExpire، cruft packها و این‌که هنوز اشاره‌گر یا reflogی شیء را نگه داشته باشد، نتیجه را عوض می‌کنند. این عدد هم مهلت تضمینی نیست.

Unreachable objects have no guaranteed countdown either. Current documentation says git gc normally prunes loose objects with a default grace period of about two weeks; gc.pruneExpire, cruft packs, and whether any ref or reflog still retains an object all affect the result. This is not a guaranteed recovery window.

در حادثه، کار درست «تمیزکاری» نیست. git gc، git prune، git reflog expire یا فرمان‌های دارای --prune=now را اجرا نکن. اول شناسه را پیدا و با اشاره‌گر نجات حفظ کن؛ بعد که وضعیت روشن شد دربارهٔ نگهداری مخزن تصمیم بگیر.

During an incident, cleanup is not the next move. Do not run git gc, git prune, git reflog expire, or commands using --prune=now. First identify and preserve the object with a rescue ref; decide on repository maintenance only after the situation is clear.

اگر سرنخ درست را پیدا نکردیWhen the expected clue is missing

تمرین‌ها: سرنخ را پیدا کن، نه شمارهٔ حفظی راExercises: find evidence, not a memorised index

شماره‌های HEAD@{n} را حفظ نکن. در هر مخزن و هر زمان فرق می‌کنند. متن رخداد، زمان و شناسه را بخوان و وقتی فکر کردی commit درست را پیدا کرده‌ای، اول با show نگاهش کن؛ بعد یک شاخهٔ نجات بساز.

Each exercise is a small incident. Before opening the solution, say which ref or object you are tracing and what remains unproven.

پروژهٔ کوچک: میز نجات GitMini-project: the Git rescue desk

در این پروژه چند چیز عمداً «گم» شده‌اند، اما عجله نمی‌کنیم چیزی را سر جایش هل بدهیم. اول فقط ردها را پیدا می‌کنی و برای هر مورد یک نام نجات می‌سازی. وقتی مطمئن شدی چیزی قابل دسترسی است، تازه دربارهٔ ادغام یا جابه‌جایی شاخه تصمیم می‌گیری.

Three realistic incidents arrive at your desk: a deleted branch, a mistaken reset, and a commit made in detached HEAD. Reproduce all three in a disposable repository and write a short report for each: symptom, ref/object found, rescue decision, and final proof.

برای شروع هر پرونده یک مخزن دورریختنی در پوشهٔ جدا بساز تا رویدادهای پروندهٔ قبلی شمارهٔ سرنخ‌های بعدی را جابه‌جا نکند. فرمان‌های حذف و reset فقط در همین پوشه‌های آزمایشی اجرا شوند.

Give each incident its own disposable repository in a separate folder so earlier events do not shift later clues. Run deletion and reset commands only in these practice folders.

1. پروندهٔ شاخهٔ حذف‌شدهDeleted branch

   شاخه بساز، دو commit مرتبط روی آن ثبت کن، از آن بیرون برو و شاخه را حذف کن. با reflog محلی شناسه‌ شیء نوک شاخه را پیدا کن، با show محتوایش را ثابت کن، rescue شاخه بساز و گراف نهایی را ثبت کن.

   Create a branch, make two related commits, switch away, and delete it. Find the tip OID in the local reflog, verify it with show, create a rescue branch, and record the final graph.

2. پروندهٔ resetMistaken reset

   سه commit روی main بساز و به عمد دو commit آخر را با hard reset از مسیر عادی خارج کن. reflog را بخوان، گزینهٔ آزمایشیها را مقایسه کن، rescue شاخه بساز و ثابت کن main هنوز همان‌جاست.

   Make three commits on main and deliberately move it back two commits with hard reset. Inspect the reflog, compare candidates, create a rescue branch, and prove main has not moved again.

3. پروندهٔ جداشده HEADDetached-HEAD commit

   به commit مشخص checkout کن، commit تازه بساز و به main برگرد. از reflog HEAD شناسه را پیدا کن، محتوا و والد را بررسی و شاخه نجات بساز.

   Check out a specific commit, create a new commit, and return to main. Find its ID in HEAD's reflog, inspect content and parent, and create a rescue branch.

mkdir rescue-case-branch
cd rescue-case-branch
git init -b main
git config user.name "Rescue Learner"
git config user.email rescue@example.test
printf 'base\n' > notes.txt
git add notes.txt
git commit -m "baseline"
git switch -c topic
printf 'topic one\n' >> notes.txt
git commit -am "topic: first change"
printf 'topic two\n' >> notes.txt
git commit -am "topic: second change"
git switch main
git branch -D topic

mkdir ../rescue-case-reset
cd ../rescue-case-reset
git init -b main
git config user.name "Rescue Learner"
git config user.email rescue@example.test
printf 'A\n' > notes.txt
git add notes.txt
git commit -m "A: baseline"
printf 'B\n' >> notes.txt
git commit -am "B: second commit"
printf 'C\n' >> notes.txt
git commit -am "C: third commit"
git reset --hard HEAD~2

mkdir ../rescue-case-detached
cd ../rescue-case-detached
git init -b main
git config user.name "Rescue Learner"
git config user.email rescue@example.test
printf 'base\n' > notes.txt
git add notes.txt
git commit -m "baseline"
git switch --detach HEAD
printf 'detached work\n' >> notes.txt
git commit -am "commit made while detached"
git switch main

همه‌چیز را به آخرین وضعیتِ ذخیره‌شده برنمی‌گردانیمNot every interruption needs a rescue

reflog برای وقتی عالی است که نام‌ها جابه‌جا شده‌اند، اما هر وقفه‌ای بحران نیست. گاهی فقط می‌خواهی کار نیمه‌تمام را چند دقیقه کنار بگذاری، یک تغییر مشخص را به خط دیگری ببری یا یک نسخه را اسم‌گذاری کنی؛ فصل بعد همین سه نیاز روزمره را کنار هم می‌گذارد.

You now know that a reflog records ref movements in this clone and how a rescue branch preserves a discovered commit beyond journal expiry. But sometimes nothing is wrong—you simply need to pause. Chapter 11 introduces three small tools for interruption and selective movement: stash, cherry-pick, and tag.

مرور کوتاهQuick reference

برای جزئیات جاری، راهنمای رسمی reflog، branch، نسخهٔ تاریخچهها و selectorهای زمانی، fsck و gc را ببین. بازه‌های نگهداری تنظیم‌پذیرند؛ git config --show-origin --get-regexp 'gc\.(reflogExpire|reflogExpireUnreachable|pruneExpire)' کمک می‌کند تنظیم مؤثر را پیدا کنی.

For current details, see the official manuals for git reflog, git branch, revision and date selectors, git fsck, and git gc. Retention is configurable; git config --show-origin --get-regexp 'gc\.(reflogExpire|reflogExpireUnreachable|pruneExpire)' helps locate effective settings.