اول چه چیزی را نباید بزنیم؟What should we not run first?

قبل از هر کاری دستت را از روی reset --hard و clean -f بردار. اول بپرس کار کجا بوده: commit شده؟ ناحیه‌ آماده‌سازی شده؟ stash شده؟ فقط ردیابی‌نشده بوده؟ clone دیگری آن را دارد؟ همین جواب تعیین می‌کند Git چه شانسی برای نجات دارد.

Before trying a fix, ask: was it committed, only staged, stashed, left in the working tree or untracked, pushed, kept in another clone, or recorded as a reflog clue? Each answer leads to a different path.

Git یک دکمهٔ «برگرداندن روز گذشته» ندارد. فصل ۰۲ نشان داد commit، tree و blob چه هستند؛ فصل ۰۳ سه ناحیه را جدا کرد؛ فصل ۰۹ تفاوت reset، revert و restore را ساخت؛ و فصل ۱۰ reflog و شیءهای بی‌نام را بررسی کرد. حالا همین‌ها را در یک اتاق نجات به کار می‌گیریم، بی‌آنکه فرض کنیم هر چیزی حتماً قابل‌بازیابی است.

Git has no “restore yesterday” button. Chapter 02 established commits, trees, and blobs; Chapter 03 separated the three areas; Chapter 09 distinguished reset, revert, and restore; Chapter 10 examined reflogs and unnamed objects. Now we apply those ideas in one rescue room without assuming every bit is recoverable.

پروتکل نجات: یک قدم در هر نوبتRescue protocol: one change at a time

اول وضعیت را ثبت کن، نه اینکه «تمیزش» کنی. این فرمان‌ها فقط نمایی از مخزن فعلی می‌دهند؛ خروجی را در پروندهٔ حادثه نگه دار. اگر فرمانی خطا داد، همان خطا هم مدرک است.

Record the state before trying to “clean it up.” These commands inspect the current repository; keep their output with the incident notes. A failed command is evidence too.

git status --short --branch
git branch --show-current
git rev-parse --verify HEAD
git log --all --graph --decorate --oneline -30
git reflog --all --date=iso
git stash list
git remote -v
git ls-files --others --exclude-standard

در status دنبال فایل‌های آماده‌شده، تغییرهای ردیابی‌شده و ??های ردیابی‌نشده بگرد. rev-parse شناسهٔ commit فعلی را ثبت می‌کند؛ در مخزن تازه و بدون commit ممکن است شکست بخورد، و این خودش بخشی از وضعیت است. log --all تاریخچهٔ متصل به اشاره‌گرهای فعلی را می‌بیند؛ commit بی‌نام ممکن است آن‌جا نباشد. reflog فقط دفترچهٔ محلی همین clone است.

In status, look for staged paths, tracked edits, and untracked ?? entries. rev-parse records the current commit ID; it may fail in a repository with no commits, which is itself part of the state. log --all shows history reachable from current refs; an unnamed commit may be absent. A reflog belongs only to this local clone.

# نمونه است؛ branch، شناسه و فایل‌ها در مخزن تو فرق می‌کنند.
## HEAD (no branch)
 M src/app.js
?? notes.txt
7ac31f2 (HEAD) HEAD@{0}: reset: moving to HEAD~2
9bd8a61 HEAD@{1}: commit: finish parser
stash@{0}: On main: wip layout
origin  https://example.invalid/team/app.git

این نمونه می‌گوید پوشه‌ کاری هم تغییر دارد، یک فایل ردیابی‌نشده هست، و reflog از reset قبلی سرنخ داده. اما ثابت نمی‌کند کدام نسخهٔ فایل روی دیسک بهتر است یا هیچ نسخهٔ دیگری وجود ندارد. قبل از حرکت دادن اشاره‌گر، اگر HEAD commit دارد، می‌توانی فقط همان commit را با یک اشاره‌گر تازه حفظ کنی؛ تغییرهای index/پوشه‌ کاری را جدا ذخیره کن.

This sample shows working-tree changes, an untracked file, and a previous reset in the reflog. It does not prove which on-disk file is best or that no other copy exists. Before moving a ref, if HEAD names a commit, you can preserve that commit with a new ref; save index and working-tree changes separately.

git branch rescue/pre-recovery HEAD
git diff --binary > ../working-tree.patch
git diff --cached --binary > ../index.patch
git ls-files --others --exclude-standard

شاخهٔ rescue/pre-recovery فقط commitی را نگه می‌دارد که HEAD همین حالا به آن اشاره می‌کند؛ ناحیه‌ آماده‌سازی، تغییرهای آماده‌نشده و ردیابی‌نشده را ذخیره نمی‌کند. دو patch بالا تغییرهای ردیابی‌شده را جدا ثبت می‌کنند. فایل‌های ردیابی‌نشده را در پوشه‌ای امن کپی کن. اگر اصل مخزن مشکوک به خرابی است، اول از کل پوشهٔ مخزن یک کپی جدا برای بررسی بساز. این کپی‌ها هم فقط همان چیزی را حفظ می‌کنند که واقعاً در آن‌ها بوده؛ چیزی را که قبلاً پاک شده‌اند جادو نمی‌کنند.

The rescue/pre-recovery branch preserves only the commit HEAD currently names; it does not save the index, unstaged edits, or untracked files. The two patches capture tracked changes separately. Copy untracked files to a safe directory. If repository corruption is suspected, first make a separate filesystem copy of the repository for inspection. These copies preserve only what they actually contain; they cannot recreate something already deleted.

نام گم شد یا خودِ شیء؟ این دو یکی نیستندWas the name lost—or the object?

فصل ۰۵ گفت شاخه یک اشاره‌گر سبک است؛ فصل ۰۲ گفت commit به tree و blob می‌رسد. حذف شاخه می‌تواند نام را بردارد، در حالی که شیءهای commit هنوز مدتی در مخزن مانده باشند. از طرف دیگر اگر شیء خراب یا واقعاً حذف شده باشد، ساختن شاخه تازه چیزی برای پرکردن ندارد.

Chapter 05 showed that a branch is a lightweight ref; Chapter 02 showed how a commit reaches trees and blobs. Deleting a branch can remove the name while commit objects remain in the repository for a time. But if an object is corrupt or actually gone, creating another branch gives it nothing to point to.

git reflog --all را برای حرکت نام‌ها بخوان؛ اگر شناسه‌ای پیدا شد، قبل از تغییر، خود commit را با git show --stat --oneline OID بشناس و با git cat-file -e 'OID^{commit}' وجود commit را بررسی کن. اگر قرار است نگهش داری، یک rescue شاخه بساز و با git show-ref بررسی کن که نام تازه واقعاً به همان شناسه اشاره می‌کند.

Read ref movements with git reflog --all. If you find an ID, inspect the commit with git show --stat --oneline OID before changing anything, and test its existence with git cat-file -e 'OID^{commit}'. If you need to keep it, create a rescue branch and confirm with git show-ref that the new name points to that ID.

اگر اشاره‌گر پیدا نشد، git log --all کافی نیست؛ این دستور همهٔ شیءهای بی‌نام را نمی‌گردد. روی مخزن سالم یا کپیِ جداشده می‌توانی git fsck --full --no-reflogs --unreachable را بررسی کنی. خروجی ممکن است commitهای unreachable بدهد؛ هر کدام را با git show بخوان. fsck ابزار جست‌وجو/بررسی است، نه تعمیرکار جادویی.

If no ref appears, git log --all is not enough; it does not enumerate every unnamed object. On a healthy repository or a separate copy, inspect git fsck --full --no-reflogs --unreachable. It may list unreachable commits; examine candidates with git show. Fsck is an inspection tool, not a magic repair service.

unreachable commit 71ab23c...
unreachable tree 22cd901...
dangling blob 4fe1a02...

این خروجی می‌گوید چند شیء در مخزن هستند ولی از ریشه‌هایی که این اجرا بررسی کرده reachable نیستند. شناسهٔ commit را می‌توانی وارسی و در صورت نیاز اشاره‌گر کنی؛ blob به‌تنهایی ممکن است اسم فایل یا زمان ویرایش را نداشته باشد. حتی یک شیء سالم هم ثابت نمی‌کند تمام تغییرهای روز گمشده ذخیره شده‌اند.

This output says some objects exist but are not reachable from the roots checked by this run. You can inspect a commit ID and, if useful, create a ref for it. A blob alone may have no filename or edit timestamp. Even a healthy object does not prove that every change from the lost day was stored.

دفترچهٔ reflog محلی است و ردهایش نگهداری ابدی ندارند؛ زمان نگهداری می‌تواند با تنظیم Git فرق کند. وقتی سرنخ معتبر پیدا شد، با ساختن اشاره‌گر آن را زود از حالت بی‌نام بیرون بیاور. در دوران نجات git gc، git prune یا expire کردن reflog را اجرا نکن. مرجع‌ها: reflog و fsck.

Reflogs are local, and their entries are not retained forever; the period can vary with Git configuration. Once you have a credible clue, promptly protect it with a ref. During recovery, do not run git gc, git prune, or reflog expiration. See the official git-reflog and git-fsck manuals.

rebase بد: اگر هنوز وسطش هستی، زور نزنA bad rebase: if it is still in progress, do not force through

rebase وسط تعارض متوقف شده و حالا نمی‌دانی کدام فایل باید بماند. هنوز operation فعال است؟ اول git status را بخوان و تغییرهای قبل از rebase را تا جایی که می‌توانی جدا نگه دار. اگر تصمیم گرفتی همین تلاش را کنار بگذاری، git rebase --abort مسیر استاندارد پایان‌دادن به rebase نیمه‌کاره است؛ بعد دوباره همان وضعیت و گراف را بررسی کن.

A rebase stopped at a conflict, and you no longer know which version should remain. Is the operation still active? Read git status first and preserve pre-rebase changes separately where possible. If you decide to abandon this attempt, git rebase --abort is the standard way to end an in-progress rebase; then inspect the same status and graph again.

interactive rebase in progress; onto 42bc113
Last command done (1 command done):
   pick 8af0312 add parser
No commands remaining.
You are currently editing a commit while rebasing branch 'feature' on 'main'.

پیام بالا می‌گوید Git هنوز در وضعیت rebase است؛ هنوز ثابت نمی‌کند کار شروع‌شده قبل از rebase یا ناحیه‌ آماده‌سازی بی‌خطر است. اگر rebase قبلاً کامل شده و نتیجه بد است، --abort دیگر کار نمی‌کند. reflog و پیام‌های rebase را پیدا کن، شناسه‌ شیء قبلی را با show بررسی کن و قبل از حرکت دادن شاخه، آن را با اشاره‌گر نجات حفظ کن. ORIG_HEAD ممکن است سرنخ باشد، اما بعد از عملیات دیگر هم می‌تواند عوض شده باشد؛ بدون بررسی کورکورانه reset نکن.

The output says Git is still in a rebase; it does not prove that pre-rebase work or the index is safe. If the rebase already completed, --abort no longer applies. Find the reflog entries and rebase messages, inspect the old OID with show, and preserve it with a rescue ref before moving the branch. ORIG_HEAD may help, but later operations can change it; never reset to it blindly.

اگر تعارض فقط از merge می‌آید، git merge --abort را بعد از ثبت وضعیت و حفظ تغییرهای مهم به کار ببر. اگر توالی cherry-pick هنوز ادامه دارد، git cherry-pick --abort را انتخاب کن. abort برای operation درحال‌اجراست؛ بعد از commit نهایی باید با توجه به خصوصی یا مشترک بودن نتیجه، ادامه بدهی. مستند pull نیز پایان‌دادن به merge/rebase نیمه‌کاره را شرح می‌دهد.

If the conflict is from a merge, use git merge --abort only after recording state and preserving important changes. If a cherry-pick sequence is still active, choose git cherry-pick --abort. Abort applies to an operation in progress; after a final commit, the next step depends on whether the result is private or shared. The git-pull documentation also describes ending an in-progress merge or rebase.

commit روی شاخهٔ اشتباه: commit را پیدا کن، بعد جابه‌جایش کنCommitted on the wrong branch: locate the commit before moving it

یک commit درست ساخته‌ای، اما روی main بوده نه روی feature. اول با git status --short --branch و git log --all --graph --decorate --oneline مطمئن شو کدام اشاره‌گر جلو رفته و آیا commit از قبل در مقصد هست. یک نام نجات برای شناسه‌ شیء بساز، بعد روی شاخهٔ مقصد برو و فقط وقتی patch را لازم داری cherry-pick کن.

You made a valid commit, but on main instead of feature. First use git status --short --branch and git log --all --graph --decorate --oneline to see which ref moved and whether the target already contains the commit. Name the OID with a rescue ref, switch to the intended branch, and cherry-pick only if that patch is needed there.

* 94ac210 (HEAD -> main) add export option
* 122bc40 (feature/export) start exporter

قبل از جابه‌جایی، commit را با git show --stat 94ac210 بررسی کن. اگر commit خصوصی و فقط روی شاخهٔ غلط است، نگه‌داشتن یک کپی روی شاخهٔ مقصد معمولاً امن‌تر از پاک‌کردن عجولانهٔ شاخهٔ اول است. اگر قبلاً push یا با دیگران share شده، تاریخچهٔ آن‌ها را با reset بازنویسی نکن؛ راه جبران را با تیم انتخاب کن، معمولاً با commit تازه یا revert.

Inspect the commit with git show --stat 94ac210 before moving anything. If it is private and only on the wrong branch, preserving a copy on the intended branch is usually safer than hurriedly deleting the first branch. If it was pushed or shared, do not rewrite teammates’ history with reset; agree on a forward correction, often a new commit or revert.

push اجباری اشتباه: سراغ clone دوم برو، نه reflog سرورAccidental force-push: inspect a second clone, not a server reflog

مخزن راه دور حالا روی commit قدیمی‌تر ایستاده و commit همکار از شاخه ناپدید شده. فرض نکن می‌توانی به دفترچهٔ داخلی GitHub یا GitLab دسترسی بگیری؛ کاربر عادی معمولاً reflog سمت سرور را نمی‌بیند. اول از همکار بخواه هیچ پاک‌سازی یا fetch/force تازه‌ای نکند و در clone خودش git status و git log --all --graph را نگه دارد. یک clone دوم یا شناسه‌ شیء شناخته‌شده می‌تواند مدرک واقعی باشد.

The remote now points to an older commit, and a teammate’s commit vanished from the branch. Do not assume you can access GitHub or GitLab’s internal server reflog; ordinary users generally cannot. Ask the teammate not to clean or force-push again, and preserve git status and git log --all --graph from their clone. A second clone or known OID is actual evidence.

اگر شناسه‌ شیء را شناختی، اول git show --stat OID و git cat-file -e 'OID^{commit}' را در clone دوم اجرا کن. بعد git branch rescue/old-tip OID و git push origin rescue/old-tip را بزن تا یک اشاره‌گر تازهٔ معمولی روی مخزن راه دور ساخته شود. این کار main را برنمی‌گرداند؛ فقط commit را از خطر بی‌نام‌ماندن دور می‌کند. بازگرداندن main به شناسه‌ شیء درست، تصمیم هماهنگی تیم است؛ شناسهٔ قدیمی را از گفت‌وگوی همکار یا ثبت ساخت تأیید کن، نه از حدس.

Once identified, run git show --stat OID and git cat-file -e 'OID^{commit}' in the second clone. Then create git branch rescue/old-tip OID and git push origin rescue/old-tip to publish an ordinary new ref. This does not restore main; it protects the commit from remaining unnamed. Restoring main to the right OID is a team coordination decision. Confirm the old ID from a teammate or build record, not a guess.

secret در commit: اول اعتبارنامه را باطل کنA secret in a commit: revoke the credential first

یک token واقعی وارد commit شده و شاید push هم شده. اولین کار پاک‌کردن commit نیست؛ اعتبارنامه را فوراً revoke یا rotate کن. تا وقتی secret معتبر است، حتی مخفی‌کردن شاخه هم کسی را که قبلاً آن را دیده متوقف نمی‌کند.

A real token entered a commit and may have been pushed. The first action is not deleting the commit; revoke or rotate the credential immediately. While it remains valid, hiding a branch cannot stop someone who already saw it.

بعد از باطل‌کردن، تیم می‌تواند با هماهنگی تاریخچه را بازنویسی و نسخهٔ میزبان را اصلاح کند؛ اما push اجباری رمز را از cloneها، forkها، cacheها یا فایل‌های دانلودشده پس نمی‌گیرد. برای حذف کامل‌تر ممکن است پشتیبانی میزبان هم لازم باشد. راهنمای GitHub صریحاً چرخاندن اعتبارنامه را قدم اول می‌داند: Removing sensitive data from a مخزن. برای GitLab یا میزبان دیگر، فرایند و پشتیبانی همان سرویس را بررسی کن.

After revocation, the team may coordinate a history rewrite and hosted-repository cleanup, but force-pushing cannot recall the secret from clones, forks, caches, or downloaded files. The host may need to assist with complete removal. GitHub explicitly makes credential rotation the first step in its sensitive-data removal guide. For GitLab or another host, check that service’s process and support.

شیء خراب شده یا فایل اصلاً ذخیره نشده؟Is an object corrupt—or was the file never stored?

دو جمله ممکن است هر دو با «فایلم نیست» شروع شوند، ولی پاسخشان یکی نیست. در حالت اول Git شیء را قبلاً داشته و حالا خطای اتصال، شیء گمشده یا hash mismatch می‌دهد. در حالت دوم فایل ردیابی‌نشده بوده، هرگز ناحیه‌ آماده‌سازی نشده و کسی پاکش کرده. git fsck --full برای بررسی صحت و اتصال شیءهاست؛ خودش شیء خراب را تعمیر یا نسخهٔ سالم را از هیچ‌جا تولید نمی‌کند.

Two reports can both begin with “my file is gone” but need different answers. In the first, Git once had an object and now reports a connectivity error, a missing object, or a hash mismatch. In the second, an untracked file was never staged and somebody deleted it. git fsck --full checks object validity and connectivity; it does not repair a corrupt object or manufacture a healthy copy.

git fsck --full
# نمونه‌های ممکن، بسته به مخزن:
missing blob 4fe1a02...
error: hash mismatch 7bd83d...

این نمونه فقط نشان می‌دهد شیء مورد انتظار در مخزن فعلی مشکل دارد. عملیات housekeeping را متوقف کن، از مخزن کپی بگیر، شناسهٔ شیء را ثبت کن و یک clone یا نسخه‌ پشتیبان سالم را بیاب. اگر آن شیء در نسخهٔ سالم موجود و قابل‌دسترسی باشد، می‌شود از آن منبع دوباره fetch/نسخه‌برداری کرد؛ بدون آن، fsck چیزی برای جایگزینی ندارد. به سراغ gc، prune یا fsck --lost-found روی تنها نسخهٔ اصلی نرو.

This sample only says an expected object has a problem in the current repository. Stop housekeeping, copy the repository, record the object ID, and locate a healthy clone or backup. If that object exists in an accessible healthy copy, it may be fetched or copied from there; without such a source, fsck has nothing to replace it with. Avoid gc, prune, or fsck --lost-found on the only original copy.

اگر فایلی ردیابی‌نشده و هیچ‌وقت ناحیه‌ آماده‌سازی نشده بود، Git هیچ blobی از آن نگرفته است. بررسی status یا fsck نمی‌تواند محتوایی را که هرگز وارد پایگاه اشیا نشده برگرداند. سطل زباله، محلی تاریخچه ویرایشگر، عکس فوری سیستم، نسخه‌ پشتیبان یا نسخهٔ همکار را جدا بررسی کن؛ اگر هیچ‌کدام نیست، صادقانه بگو بازیابی از Git ممکن نیست. همین مرز، فرق «اشاره‌گر گم‌شده» با «داده‌ای که هرگز ذخیره نشد» است.

If a file was untracked and never staged, Git never received a blob for it. Neither status nor fsck can restore content that never entered the object database. Check the recycle bin, editor local history, system snapshots, backups, or a teammate’s copy; if none exists, say honestly that Git cannot recover it. That is the boundary between a lost ref and data that was never stored.

git clean ابزار نجات نیستgit clean is not a rescue command

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

This command removes untracked files—the very place where the only remaining copy might live. If you only want to see what would be targeted, use its preview mode:

git clean -nd

نمونهٔ خروجی می‌تواند مسیرهای ردیابی‌نشده را فهرست کند؛ -n یعنی حذف واقعی انجام نمی‌شود و -d پوشه‌ها را هم در پیش‌نمایش می‌آورد. حتی با خروجی ظاهراً بی‌خطر، فرمان واقعی را در اتاق نجات اجرا نمی‌کنیم. -x دامنه را به فایل‌های ignored هم گسترش می‌دهد. این فرمان برای پاک‌سازی آگاهانه است، نه پیدا کردن فایل گمشده. مستند رسمی clean تفاوت preview و حذف را توضیح می‌دهد.

Representative output may list untracked paths; -n means no deletion happens, and -d includes directories in the preview. Even if the list looks harmless, we do not run the real deletion command in a rescue room. -x expands the target to ignored files too. This is for deliberate cleanup, not finding a missing file. See the official git-clean manual.

مینی‌پروژه: اتاق نجاتMini-project: the rescue room

mkdir rescue-room
cd rescue-room
git init --bare --initial-branch=main remote.git
git clone remote.git writer
git -C writer config user.name "Rescue Learner"
git -C writer config user.email "rescue@example.test"
printf 'base\n' > writer/app.txt
git -C writer add app.txt
git -C writer commit -m "base"
git -C writer push -u origin main
git clone remote.git witness
git -C witness config user.name "Witness"
git -C witness config user.email "witness@example.test"

git -C writer switch -c lost-feature
printf 'feature one\n' > writer/feature.txt
git -C writer add feature.txt
git -C writer commit -m "feature one"
printf 'feature two\n' >> writer/feature.txt
git -C writer commit -am "feature two"
git -C writer switch main
git -C writer branch -D lost-feature

git -C writer switch -c reset-case
printf 'reset one\n' > writer/reset.txt
git -C writer add reset.txt
git -C writer commit -m "reset checkpoint one"
printf 'reset two\n' >> writer/reset.txt
git -C writer commit -am "reset checkpoint two"
git -C writer rev-parse HEAD
git -C writer reset --hard HEAD~2

git -C writer switch --detach main
printf 'detached work\n' > writer/detached.txt
git -C writer add detached.txt
git -C writer commit -m "detached work"
git -C writer rev-parse HEAD
git -C writer switch main

git -C writer switch main
printf 'shared commit\n' >> writer/app.txt
git -C writer commit -am "shared work"
git -C writer push
git -C witness fetch origin
git -C writer reset --hard HEAD~1
git -C writer push --force-with-lease origin main

printf 'never staged or committed\n' > writer/never-tracked.txt
git -C writer status --short
rm writer/never-tracked.txt

۱۸ پروندهٔ رخداد18 incident tickets

هر پرونده را با دستور شروع نکن؛ با مشاهده شروع کن. گاهی حرفه‌ای‌ترین جواب این است که «فعلاً هیچ دستور مخربی نزن» و گاهی هم باید صریح بگویی «Git این فایل را هرگز ذخیره نکرده و بازیابی‌اش را تضمین نمی‌کند».

Start every answer with evidence. If the right answer is “do nothing destructive yet” or “Git cannot guarantee recovery,” say so and name the next check.

معیار موفقیت هر پرونده: وضعیت را از روی شاهد درست تشخیص بده، اقدام امن بعدی یا مرز بازیابی را روشن بگو و ادعایی فراتر از مدرک نکن.

Success criterion for every ticket: diagnose from the right evidence, state the safe next action or recovery limit, and claim no more than the evidence supports.

از این‌جا به بعد فرمان تازه‌ای پشتش پنهان نیستFrom here, there is no new command to hide behind

اینجا آموزش ابزار تازه تمام می‌شود. سه پروژهٔ پایانی دیگر نردهٔ آموزشی ندارند: اول باید تاریخچه را خودت طراحی کنی، بعد با یک تیم واقعی‌تر جلو بروی و در آخر یک مخزن خراب را با شاهد و بدون حدس نجات بدهی.

Chapter 16 ends the teaching arc for new tools, not the practice of Git. The final projects ask you to design history, collaborate with a team, and recover when something slips using the model built since Chapter 01. A good question does not always begin with “Which command should I run?” Sometimes it starts with “What does Git still have right now?”

نقشهٔ سریع اتاق نجاتRescue-room quick reference

قاعدهٔ آخر دوره همان قاعدهٔ اول اتاق نجات است: قبل از پاک‌کردن چیزی، بفهم Git هنوز چه چیزی دارد. بعد یک تغییر کوچک بده و همان چیزی را که اول اندازه گرفتی دوباره بررسی کن.

The final rule is the one we began with: do not delete first; find out what Git still has. Then make one change, verify it, and report honestly.

اگر خواستی جزئیات فرمان را دنبال کنیFor the exact command behavior

برای گزینه‌ها و رفتار نسخهٔ نصب‌شده، راهنماهای رسمی reflog، fsck، reset، clean و push را ببین. دستور نجات را در مخزن دورریختنی تمرین کن؛ نام نسخهٔ تاریخچه، تنظیمات و مدت نگهداری reflog می‌تواند فرق کند.

For options and behavior in your installed Git version, consult the official manuals for reflog, fsck, reset, clean, and push. Practice recovery commands in a disposable repository; revision names, configuration, and reflog retention can differ.