سه دردسر، سه جای متفاوتThree mistakes, three different places

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

Last week you sent a change to Bob, and the whole team now has it. Today you dislike a local edit. Yesterday you staged the wrong file. “Undo” means something different in each case. If you choose a command before locating the change, you may discard the very version you wanted to keep.

فصل ۰۳ سه ناحیه را معرفی کرد: HEAD آخرین commit شاخه، index نسخه‌ای که commit بعدی می‌سازد، و پوشه‌ کاری فایل‌های روی دیسک. فصل ۰۸ هم نشان داد شاخهٔ محلی و تاریخچهٔ مخزن راه دور دو جا هستند. پس سؤال تکراری این فصل همین است: دقیقاً چه چیزی را می‌خواهی عوض کنی؟

Chapter 03 introduced the three areas: HEAD, the tip commit of the current branch; the index, the snapshot the next commit will use; and the working tree, the files on disk. Chapter 08 showed that your local branch and the remote’s history are separate too. So keep asking: what exactly do you want to change?

restore: کپی مقصد را انتخاب کنrestore: choose which copy to change

در فصل ۰۳ دیدی git restore FILE نسخهٔ ناحیه‌ آماده‌سازی را روی فایل پوشه‌ کاری می‌گذارد و git restore --staged FILE مدخل ناحیه‌ آماده‌سازی را از HEAD برمی‌گرداند. حالا یک قدم جلوتر می‌رویم: می‌توانی commit دیگری را منبع بگیری، یا عمداً هر دو مقصد را تغییر بدهی.

Chapter 03 showed that git restore FILE copies the index version into the working-tree file, while git restore --staged FILE resets the index entry from HEAD. Now we go one step further: you can choose another commit as the source, or intentionally change both destinations.

فرض کن روی profile.txt دو اصلاح داری: نسخهٔ درست را ناحیه‌ آماده‌سازی کرده‌ای، بعد یک ویرایش بدتر روی دیسک مانده. قبل از restore، با git diff -- و git diff --staged ببین هر نسخه کجاست. حالا فقط ویرایش آماده‌نشده را کنار می‌گذاری:

Suppose profile.txt has two edits: you staged the good version, then left a worse edit on disk. Before restoring, inspect git diff -- and git diff --staged to locate each copy. Now discard only the unstaged edit:

git status --short
git diff -- profile.txt
git diff --staged -- profile.txt
git restore -- profile.txt
git diff -- profile.txt
git diff --staged -- profile.txt

بعد از فرمان، diff عادی خالی است ولی diff مربوط به ناحیه‌ آماده‌سازی هنوز همان اصلاح ناحیه‌ آماده‌سازیشده را نشان می‌دهد. یعنی فقط پوشهٔ کاری از ناحیه‌ آماده‌سازی نسخه گرفت؛ هیچ commit یا شاخه‌ای حرکت نکرد. این همان رفتاری است که فصل ۰۳ دیدی، با تأکید بیشتر بر اینکه نسخهٔ کنارگذاشته‌شده را باید آگاهانه انتخاب کنی.

Afterward, the ordinary diff is empty, while the staged diff still shows the intended edit. Only the working tree copied from the index; no commit or branch moved. This is the behavior from Chapter 03, with extra emphasis on deliberately choosing which version to discard.

اگر تغییر اشتباهی ناحیه‌ آماده‌سازی شده، اما خود فایل روی دیسک را می‌خواهی نگه داری، مقصد را برعکس کن: git restore --staged -- profile.txt. ناحیه‌ آماده‌سازی از HEAD نسخه می‌گیرد و فایل روی دیسک دست‌نخورده می‌ماند. بعد می‌توانی تغییر را بررسی و درست ناحیه‌ آماده‌سازی کنی. اگر هر دو نسخه را دور می‌خواهی، این تصمیم دوم و جداست: اول ناحیه‌ آماده‌سازی را برگردان، بعد پوشه‌ کاری را هم restore کن.

If the wrong change is staged but you want to keep the disk file, reverse the destination: git restore --staged -- profile.txt. The index takes its version from HEAD, while the file stays untouched. Then inspect and stage the intended content. If you want to discard both copies, that is a separate decision: restore the index first, then restore the working tree too.

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

To take a file from an older commit, specify the source. This command copies only the disk file from the older commit; the index keeps its existing version, so a new diff may appear:

git log --oneline -- profile.txt
git restore --source=HEAD~1 --worktree -- profile.txt
git diff -- profile.txt
git diff --staged -- profile.txt

نام HEAD~1 باید واقعاً نسخهٔ آن مسیر را داشته باشد؛ اگر مسیر در منبع وجود نداشته باشد، restore می‌تواند فایل ردیابی‌شده را حذف کند تا با منبع جور شود. قبل از اجرا، git show HEAD~1:profile.txt را امتحان کن. اگر می‌خواهی ناحیه‌ آماده‌سازی و پوشه‌ کاری هر دو دقیقاً نسخهٔ commit را بگیرند، --staged --worktree را با منبع روشن بنویس. این کار محتوای هر دو ناحیه را جایگزین می‌کند؛ تغییرهای لازم را اول بیرون از آن فایل ذخیره کن.

The revision HEAD~1 must actually contain that path; if the path is absent from the source, restore can remove the tracked file to match it. Check with git show HEAD~1:profile.txt first. If both the index and working tree should match the commit, specify --staged --worktree and the source explicitly. That replaces both copies; save any needed edits elsewhere first.

reset: جابه‌جایی شاخه، نه پاک‌کن تاریخreset: move a branch, not an eraser

یک commit اشتباه ساخته‌ای، هنوز push نشده و می‌خواهی آن را دوباره مرتب کنی. در این شکل از reset خودِ اشاره‌گر شاخه به commit دیگری می‌رود. تفاوت --soft، --mixed و --hard این است که با ناحیه‌ آماده‌سازی و فایل‌های روی دیسک چه می‌کنند. سه آزمایش را با یک شروع یکسان ببین؛ هر بار از مخزن دورریختنی جدا استفاده کن.

You made a bad commit that has not been pushed and want to reshape it. In this form of reset, the branch pointer moves to another commit. The difference between --soft, --mixed, and --hard is what happens to the index and files on disk. We will compare all three from the same starting point; use a separate disposable repository for each run.

در هر سه آزمایش این وضعیت را بساز: commit A روی main، بعد فایل را عوض کن و commit B بساز. اکنون HEAD، ناحیه‌ آماده‌سازی و پوشه‌ کاری هر سه نسخهٔ B را دارند. فرمان هدف HEAD~1 است؛ یعنی والد B، همان A. قبل از هر reset، شاخهٔ safety/before-reset را بساز و با git show-ref --verify refs/heads/safety/before-reset وجودش را ثابت کن. آن شاخه مدرک نگهداری commit است، نه نسخهٔ جداگانه از ویرایش‌های unstaged.

For each run, start with commit A on main, edit a file, then create commit B. Now HEAD, the index, and working tree all contain B. The target HEAD~1 is B’s parent, A. Before resetting, create safety/before-reset and verify it with git show-ref --verify refs/heads/safety/before-reset. That branch preserves the commit, not a separate copy of unstaged edits.

--soft: شاخه عقب، محتوا سر جایش--soft: move the branch, keep both copies

فرض کن فقط پیام commit بد است یا دو commit را می‌خواهی یکی کنی؛ محتوای آماده‌شده درست است. قبل از reset حدس بزن: بعد از رفتن main از B به A، ناحیه‌ آماده‌سازی و فایل روی دیسک کجا می‌مانند؟

Suppose only the commit message is wrong, or you want to combine two commits; the prepared content is correct. Predict first: after main moves from B to A, where will the index and disk file remain?

git log --oneline --decorate -2
git status --short
git show-ref --verify refs/heads/safety/before-reset
git reset --soft HEAD~1
git log --oneline --decorate -2
git status --short
git diff --staged --stat

در خروجی بعدی، main روی A است، ایمنی روی B؛ status نشان می‌دهد تغییرها ناحیه‌ آماده‌سازی هستند و diff --staged محتوای B را نسبت به A نشان می‌دهد. بعد از بررسی، می‌توانی commit تازه‌ای بسازی؛ اگر فقط پیام را می‌خواستی اصلاح کنی، git commit -m "..." می‌سازد commit تازه با شناسه تازه. reset نکردن محتوا به معنی «هیچ چیز عوض نشد» نیست: شاخه اشاره‌گر و تاریخچهٔ قابل‌دسترسی از main عوض شده‌اند.

Afterward, main points to A while safety points to B. Status shows staged changes, and diff --staged shows B’s content relative to A. After reviewing, create a new commit; if you only meant to fix the message, git commit -m "..." creates a replacement commit with a new ID. Keeping the content does not mean nothing changed: the branch pointer and the history reachable from main moved.

--mixed: شاخه و ناحیه‌ آماده‌سازی عقب، فایل‌ها نه--mixed: reset the index, keep disk files

این حالت پیش‌فرض git reset TARGET است، حتی اگر گزینه‌ای ننویسی. شاخه به A می‌رود؛ ناحیه‌ آماده‌سازی هم با A جور می‌شود؛ پوشه‌ کاری B را نگه می‌دارد. نتیجه این است که ویرایش‌های B دوباره آماده‌نشده می‌شوند تا بتوانی بخش مناسب را ناحیه‌ آماده‌سازی کنی.

This is the default for git reset TARGET when you omit a mode. The branch moves to A, the index is reset to A, and the working tree keeps B. The edits from B become unstaged again so you can stage the parts you want.

git reset --mixed HEAD~1
git status --short
git diff --stat
git diff --staged

پیام Unstaged changes after reset یا حرف M در ستون پوشه‌ کاری نشانهٔ شکست نیست؛ دقیقاً می‌گوید نسخهٔ ناحیه‌ آماده‌سازی با فایل روی دیسک فرق دارد. این نسخه را قبل از ناحیه‌ آماده‌سازی دوباره مرور کن. اگر با گزینهٔ بی‌نام reset می‌کنی، همان رفتار mixed را انتظار داشته باش.

A message such as Unstaged changes after reset or an M in the working-tree column is not a failure; it tells you the index differs from the disk file. Review that version before staging it again. A reset with no mode uses this mixed behavior.

--hard: هر سه را به A برسان--hard: make all three match A

این‌بار commit B، ناحیه‌ آماده‌سازی و فایل روی دیسک هر سه غلط‌اند و مطمئنی هیچ‌کدام را لازم نداری. این اطمینان را با حدس جایگزین نکن: اول وضعیت و diffها را بخوان، شاخهٔ ایمنی را بساز و وجودش را تأیید کن. بعد، فقط در مخزن دورریختنی درس، فرمان hard را اجرا کن.

This time commit B, the index, and the disk file are all wrong, and you are certain you need none of them. Do not substitute a guess for that certainty: inspect status and diffs, create a safety branch, and verify it exists. Then run the hard reset only in the lesson’s disposable repository.

git status --short
git diff
git diff --staged
git show-ref --verify refs/heads/safety/before-reset
git reset --hard HEAD~1
git status --short
git log --oneline --decorate -2

اگر ایمنی اشاره‌گر را نساخته‌ای یا خروجی نشان نمی‌دهد به B اشاره می‌کند، فرمان hard را اجرا نکن. بعد از reset باید پوشه‌ کاری تمیز و main روی A باشد؛ ایمنی شاخه هنوز B را نگه می‌دارد. این آزمایش ثابت نمی‌کند ویرایش تازه‌ای که هرگز ناحیه‌ آماده‌سازی یا commit نشده، recoverable است. به reflog هم وعدهٔ نجات قطعی نده؛ فصل ۱۰ ابزارهای بررسی اشاره‌گرهای قبلی را توضیح می‌دهد، نه جادوی بازگرداندن محتوای هرگز ذخیره‌نشده.

If you have not created the safety ref, or the output does not show it pointing to B, do not run the hard reset. Afterward, the working tree should be clean and main should point to A; the safety branch still retains B. This does not prove that an edit never staged or committed is recoverable. Do not promise that the reflog will save everything either. Chapter 10 explains how to inspect earlier ref positions, not how to conjure content Git never stored.

سه reset را کنار هم ببینCompare the three reset modes

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

Read this as a map of destinations, not a list to memorise. In all three cases, main moves from B to A in the commit graph; the last columns show where the file versions end up.

یک مرز مهم: git reset -- FILE شکل path-based است؛ معمولاً ناحیه‌ آماده‌سازی را از HEAD برمی‌گرداند و شاخه اشاره‌گر را جابه‌جا نمی‌کند. برای تازه‌کارها git restore --staged -- FILE همان نیت را واضح‌تر می‌گوید. وقتی reset مقصد commit دارد، داری دربارهٔ موقعیت شاخه حرف می‌زنی؛ وقتی مسیر می‌دهی، دربارهٔ مدخل‌های index.

One important boundary: git reset -- FILE is the path form. It updates the index from HEAD and does not move the branch pointer. For beginners, git restore --staged -- FILE states that intention more clearly. A commit target means you are moving a branch position; a path target means you are changing index entries.

commit بد منتشر شده؟ اثرش را با commit تازه خنثی کنWas the bad commit shared? Reverse its effect with a new commit

فصل ۰۸ commitها را از یک clone به clone دیگر رساند. اگر commit بد را همکاران گرفته‌اند، reset کردن main فقط شاخهٔ تو را عقب می‌برد؛ تاریخچهٔ همکارها را پاک نمی‌کند و ممکن است push را به بازنویسی اجباری بکشاند. git revert راه دیگری دارد: patch معکوس را روی وضعیت فعلی اعمال می‌کند و نتیجه را در commit تازه ثبت می‌کند.

Chapter 08 moved commits between clones. If teammates already have the bad commit, resetting your main only moves your branch back; it does not erase their history and may tempt you into a force push. git revert takes another route: it applies an inverse patch to the current state and records the result in a new commit.

در مخزن اشتراکی این کار را در شاخهٔ درست و با پوشه‌ کاری تمیز انجام بده. اول commit هدف را با log و show پیدا کن؛ بعد revert را بساز و diff و تست را بررسی کن:

In a shared repository, work on the correct branch with a clean working tree. Find the target commit with log and show, then create the revert and inspect its diff and tests:

git status --short
git log --oneline --decorate -5
git show --stat --oneline BAD_COMMIT
git revert BAD_COMMIT
git show --stat --oneline HEAD
git log --oneline --decorate -3

شناسهٔ BAD_COMMIT را با کلید واقعی عوض کن؛ این یک جای‌نگهدار است، نه فرمان آماده. بعد از موفقیت، log باید هم commit بد را نشان دهد و هم commit جدیدی با پیام شبیه Revert "...". محتوای فایل در عکس فوری تازه اصلاح شده؛ تاریخچهٔ قدیمی دست‌نخورده مانده. این روش اثر patch را معکوس می‌کند، نه اینکه حتماً برنامه را درست کند: اگر commitهای بعدی بر همان تغییر تکیه دارند، اثر جانبی و تست را هم بررسی کن.

Replace BAD_COMMIT with the real object ID; it is a placeholder, not a runnable command. On success, the log shows both the bad commit and a new commit with a message like Revert "...". The new snapshot contains the reversed content; old history remains. Revert reverses a patch, not necessarily the application’s behavior: if later commits depend on it, inspect side effects and tests too.

گاهی patch معکوس روی کد تازه با تغییرهای بعدی تداخل دارد. Git متوقف می‌شود و تعارض می‌سازد؛ اول git status را بخوان، فایل را طوری ویرایش کن که قصد نهایی روشن باشد، بعد git add و git revert --continue. اگر هنوز نمی‌دانی نتیجه باید چه باشد، حدس نزن: git revert --abort عملیات نیمه‌تمام را لغو می‌کند. هیچ‌کدام را با reset hard روی کار حل‌نشده قاطی نکن.

Sometimes the inverse patch conflicts with later edits. Git stops with a conflict; inspect status, edit the file to express the intended result, then stage it and run git revert --continue. If you do not yet know the right result, do not guess: git revert --abort cancels the in-progress operation. Do not mix either path with a hard reset over unresolved work.

یک commit محلی را اصلاح کن؛ فقط اگر هنوز مشترک نشدهAmend a local commit—only before it is shared

commit آخر را ساخته‌ای و می‌بینی یک فایل کوچک جا مانده، یا پیامش غلط است. اگر هنوز commit منتشر نشده، git commit --amend می‌تواند نسخهٔ تازه‌ای از commit آخر بسازد. این اصلاح درجا و بی‌اثر نیست: commit جایگزین شناسه جدید می‌گیرد، چون محتوا یا پیامش عوض شده.

You made the latest commit and notice a small file is missing, or the message is wrong. Before publication, git commit --amend can create a replacement version of the tip commit. This is not an invisible edit: the replacement gets a new ID because its content or message changed.

git log -1 --oneline
git status --short
git add forgotten.txt
git commit --amend --no-edit
git log -1 --oneline
git show --stat --oneline HEAD

در این نمونه فایل ناحیه‌ آماده‌سازیشده وارد tree commit جایگزین می‌شود؛ --no-edit پیام قبلی را نگه می‌دارد. شناسه پیش و بعد از amend را مقایسه کن. اگر commit قبلاً push یا به همکار داده شده، amend تاریخچهٔ مشترک را بازنویسی می‌کند؛ پیش‌فرض امن این نیست که force بزنی. هماهنگ کن یا برای اصلاحی که باید در تاریخچهٔ مشترک بماند یک commit تازه بساز.

Here, the staged file enters the replacement commit’s tree; --no-edit keeps the existing message. Compare the IDs before and after. If the commit was pushed or handed to a teammate, amend rewrites shared history; blindly forcing it is not the safe default. Coordinate, or add a new commit when the correction should remain visible in shared history.

درخت تصمیم: قبل از فرمان، مقصد را پیدا کنA decision tree: locate the destination before choosing a command

وقتی همه می‌گویند «برگردانش»، این ترتیب را دنبال کن. اول ببین تغییر commit شده یا نه؛ بعد مشخص کن فقط ناحیه‌ آماده‌سازی اشتباه است یا فایل دیسک هم باید عوض شود؛ اگر commit شده، بپرس آیا کس دیگری آن را دریافت کرده؟

When everyone says “undo it,” follow this order. First determine whether the change is committed. Then decide whether only the staging is wrong or the disk file should change too. If it is committed, ask whether anyone else has received it.

اگر پاسخ سؤال «چه چیزی را می‌خواهم نگه دارم؟» روشن نیست، فرمان برگشت را عقب بینداز. اول git status --short، git diff و git diff --staged را بخوان. اگر قرار است commit یا شاخه‌ای را جابه‌جا کنی، در محیط آزمایشی یک اشاره‌گر مثل safety/before-undo بساز و نشان بده به کدام commit اشاره می‌کند. در تاریخچهٔ مشترک، هماهنگی بخشی از راه‌حل فنی است.

If you cannot yet answer “what do I want to keep?”, postpone the undo command. First inspect status and both diffs. Before moving a commit or branch, create a ref such as safety/before-undo in a test environment and verify which commit it names. In shared history, coordination is part of the technical solution.

وقتی «برگرداندن» خودش دردسر می‌سازدWhen undo creates another problem

بیشتر فاجعه‌های «undo» از خود reset یا restore شروع نمی‌شوند؛ از این شروع می‌شوند که هنوز نمی‌دانیم چه چیزی باید بماند. قبل از هر دستور مخرب، یک بار واضح بگو: «می‌خواهم شاخه جابه‌جا شود؟ ناحیهٔ آماده‌سازی؟ فایل روی دیسک؟ یا فقط اثر یک commit مشترک خنثی شود؟»

Undo failures rarely begin with an obscure command; they begin with an unchecked destination. Read the message, record the three-area state, and only then repair.

تمرین‌ها: اول پیدا کن چه چیزی باید بماندExercises: first decide what must remain

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

Start each answer by naming the destination: working tree, index, branch, or shared history. Sometimes the safe answer is “no command yet—create a safety ref.”

درمانگاه برگرداندن: چهار پرونده، چهار تصمیمUndo clinic: four cases, four decisions

چهار پرونده داریم و قرار نیست برای همه reset بزنیم. هر بار اول وضعیت را ثبت می‌کنی، بعد تصمیم می‌گیری چه چیزی باید حفظ شود و فقط همان بخش را تغییر می‌دهی. هدف پروژه این است که «undo» از یک واکنش عصبی تبدیل شود به یک تصمیم قابل توضیح.

A small team hears “undo this” four times in one afternoon. You are responsible for preserving the right version and showing evidence that nothing else was lost. Run this clinic in a fresh disposable repository—not in your working project or on a shared branch.

مخزن undo-clinic بساز و یک فایل notes.txt را در commit پایه قرار بده. برای هر پرونده، قبل از تغییر git status --short، git diff و git diff --staged را ثبت کن. بعد از اصلاح همان سه بررسی را دوباره اجرا و نتیجه را کنار هم بگذار.

Create undo-clinic and commit a base notes.txt. For every case, record status and both diffs before changing anything. After the repair, run the same checks again and compare the results.

mkdir undo-clinic
cd undo-clinic
git init -b main
git config user.name "Clinic Learner"
git config user.email clinic@example.test
printf 'نسخهٔ پایه\n' > notes.txt
git add notes.txt
git commit -m "Add baseline note"

برای پروندهٔ چهارم، یک مخزن راه دور محلی و clone همکار بساز. از پوشهٔ undo-clinic به پوشهٔ والد برو و این آماده‌سازی را انجام بده؛ بعد دوباره به clone اصلی برگرد. حالا هر دو clone همان commit پایه را دارند.

For case four, create a local remote and a teammate clone. Run this setup from the parent directory of undo-clinic; it returns you to the original clone. Both clones now share the baseline commit.

cd ..
git init --bare clinic-remote.git
cd undo-clinic
git remote add origin ../clinic-remote.git
git push -u origin main
cd ..
git clone clinic-remote.git clinic-bob

1. ویرایش ناخواسته، ناحیه‌ آماده‌سازی نشدهUnwanted unstaged edit

   یک خط اشتباه روی دیسک اضافه کن اما ناحیه‌ آماده‌سازی نکن. نسخهٔ ناحیه‌ آماده‌سازی را نگه دار و فقط پوشه‌ کاری را اصلاح کن. مدرک: diff قبل از restore خط اضافه را دارد؛ بعد از restore diff خالی است و فایل پایه سر جایش.

   Add a wrong line on disk but do not stage it. Keep the index version and repair only the working tree. Proof: the pre-restore diff contains the line; afterward the diff is empty and the base file remains.

2. فایل اشتباه ناحیه‌ آماده‌سازی شده، محتوا باید بماندWrong file staged, content must remain

   یک فایل تازه بساز و ناحیه‌ آماده‌سازی کن، اما تصمیم بگیر فعلاً commit نشود. آن را از ناحیه‌ آماده‌سازی بیرون بیاور و روی دیسک نگه دار. مدرک: آماده‌شده diff دیگر آن فایل را نشان نمی‌دهد، فایل هنوز هست و در وضعیت ردیابی‌نشده دیده می‌شود.

   Create and stage a new file, then decide not to commit it yet. Remove it from the index but keep it on disk. Proof: staged diff no longer contains it, the file still exists, and status shows it as untracked.

3. commit خصوصی را دوباره بازچینی کنReshape a private commit

   یک تغییر درست را commit کن، ایمنی اشاره‌گر را بساز و تأیید کن، بعد با mixed آن را به تغییر آماده‌نشده برگردان تا فقط بخشی از آن را ناحیه‌ آماده‌سازی و commit کنی. مدرک: ایمنی و log قبل/بعد، diffهای دو ناحیه و محتوای نهایی فایل.

   Commit a valid change, create and verify a safety ref, then use mixed reset to make the change unstaged so you can stage and recommit only one part. Proof: the safety ref, before/after logs, both diffs, and final file content.

4. commit بد را همکار هم گرفتهA teammate already has the bad commit

   در undo-clinic یک commit بد بساز و push کن؛ بعد در clinic-bob آن را fetch کن تا واقعاً در دید همکار باشد. به clone اصلی برگرد، با revert اصلاحش کن و push کن؛ سپس در clone همکار fetch بزن. مدرک: log هر دو commit اصلی و معکوس را دارد، عکس فوری نهایی درست است و تاریخچهٔ clone همکار با fetch عادی پیش می‌رود، بی‌آنکه reset شود.

   Create and push a bad commit from undo-clinic, then fetch it in clinic-bob so the teammate really has it. Return to the original clone, revert the change, and push; then fetch in the teammate clone. Proof: the log retains both original and inverse commits, the final snapshot is correct, and the teammate advances with a normal fetch rather than a reset.

وقتی log عادی دیگر commit را نشان نمی‌دهد چه؟What if the normal log no longer shows the commit?

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

You can now identify which area each undo command changes, why a shared commit is usually corrected with revert, and why none can recover content Git never stored. But suppose reset moved the branch and ordinary git log no longer shows the earlier commit. Chapter 10 opens Git’s local journal of ref movements: the reflog—a useful clue, not a promise to recover every bit of data.

مرور کوتاهQuick reference

برای جزئیات گزینه‌ها، راهنمای رسمی restore، reset، revert و commit را ببین. فرمان را با نسخهٔ نصب‌شده‌ات و در مخزن آزمایشی بررسی کن، به‌خصوص پیش از تغییر تاریخچه.

For option details, see the official manuals for git restore, git reset, git revert, and git commit --amend. Check commands against your installed version in a disposable repository, especially before rewriting history.