Lesson 10 / الدرس 10

Undoing: restore, reset and revert / التراجع: restore وreset وrevert

Three commands with similar names that do very different things. Choosing between them is entirely a question of which of the three places you are undoing, and whether anyone else has seen it.

ثلاثة أوامر بأسماء متشابهة تفعل أشياء شديدة الاختلاف. والاختيار بينها كله سؤال عن أي المواضع الثلاثة تتراجع عنه، وهل رآه أحد غيرك.

This is the lesson people look up in a panic, so it is arranged as an answer key. Find your situation, use the command beside it. The reasoning underneath is always the same question: which of the three places from lesson 4 holds the thing you regret?

You want toCommandSafe?
Unstage a filegit restore --staged fileYes — nothing is lost
Discard edits to a filegit restore fileNO — the edits are gone
Fix the last commit messagegit commit --amendOnly if not pushed
Undo the last commit, keep the changesgit reset --soft HEAD~1Only if not pushed
Undo the last commit and the changesgit reset --hard HEAD~1NO — and only if not pushed
Undo a commit that others havegit revert 3f9a21cYes — always
Get back a file as it was in a commitgit restore --source 3f9a21c fileOverwrites your copy

Read the third column before the second. Two of these destroy work permanently, and they are one word away from the ones that do not.

reset and revert are opposites

Before:   A ── B ── C   (C is the commit you regret)

reset:    A ── B                C is removed from history — as if it never happened

revert:   A ── B ── C ── D      D is a NEW commit that undoes C. Both are in the history.
That difference decides everything. reset rewrites history, which is fine alone and a disaster shared. revert adds to history, which is always safe because nothing anyone else has is changed. Run the demonstration for the rule in one line.

The safety net for everything else

Anything that was committed is recoverable, even after a reset --hard that appeared to delete it. git reflog lists every position HEAD has been in, including ones no longer reachable from any branch — so the commit you thought you destroyed is usually sitting there with its identifier, and git reset --hard 3f9a21c brings it back.

That is the practical summary of this whole lesson, and it is worth saying plainly: commit early and often, and almost nothing can be lost. The commands that destroy work only destroy work that was never committed. Everything else has a way back, even when the situation looks final.

Try it live / جرّب بنفسك

Preview / المعاينة

Check yourself / اختبر نفسك

1. A commit you made is on GitHub and others have it. How do you undo it?

2. What does git reset --soft HEAD~1 do to your files?

3. You ran git reset --hard and lost a commit. Is it recoverable?

Your task / مهمتك

Practise every recovery in a throwaway repository, not a real one. Make some commits, then demonstrate four things with real output: unstaging a file, undoing a commit with --soft and recommitting it properly, reverting a commit, and recovering something with git reflog after a --hard. Finish with your own one-line rule for choosing between reset and revert.

تدرّب على كل استعادة في مستودع للرمي لا في مستودع حقيقي. اصنع بعض الـcommits، ثم اعرض أربعة أشياء بمخرَج حقيقي: إلغاء تجهيز ملف، والتراجع عن commit بـ--soft وإعادة إيداعها كما ينبغي، وعمل revert لـcommit، واستعادة شيء بـgit reflog بعد --hard. واختم بقاعدتك من سطر واحد للاختيار بين reset وrevert.

  • A throwaway repository, said explicitly مستودع للرمي، مقولًا صراحةً
  • All four recoveries, with real output الاستعادات الأربع كلها بمخرَج حقيقي
  • reflog shown actually finding a lost commit reflog معروض وهو يجد commit ضائعة فعلًا
  • Your own rule for reset against revert قاعدتك أنت لـreset في مقابل revert
How do you want to submit? / كيف تريد التسليم؟