Git undo last commit: बदलाव सुरक्षित रखने का सही तरीका

TL;DR: आख़िरी कमिट अन-डू करना है पर बदलाव रखने हैं, तो git reset --soft HEAD~1 चलाइए (बदलाव स्टेज्ड रहेंगे) या git reset HEAD~1 (बदलाव वर्किंग ट्री में रहेंगे)। अगर कमिट पहले ही पुश हो चुका है, तो इसकी जगह git revert HEAD चलाइए — यह एक नया कमिट बनाता है जो पुराने को रद्द कर देता है, बिना हिस्ट्री दोबारा लिखे। यही तीन कमांड्स “मैंने बहुत जल्दी कमिट कर दिया” वाले लगभग हर पल को कवर कर लेते हैं। इस गाइड का बाक़ी हिस्सा हर केस को कॉपी-पेस्ट कमांड्स के साथ देखता है, --soft, --mixed और --hard का फ़र्क़ समझाता है, और दिखाता है कि कुछ बिगड़ जाए तो नुक़सान कैसे वापस लाएँ। नीचे का हर कमांड Linux, macOS या Windows के किसी भी हालिया Git इंस्टॉल पर चलता है।

आख़िरी कमिट अन-डू करें, पर बदलाव कैसे बचाए रखें?

सबसे आम हालत: आपने कमिट किया, फिर एक टाइपो या छूटी हुई फ़ाइल दिखी, या समझे कि यह बदलाव किसी और कमिट में जाना चाहिए था। अभी कुछ पुश नहीं हुआ है। कमिट हटाइए और सब कुछ वैसे के वैसे वापस लाइए:

# कमिट हिस्ट्री में कहीं नहीं बचता — बदलाव स्टेजिंग एरिया में वापस चले जाते हैं
git reset --soft HEAD~1

# बदलाव इसकी जगह वर्किंग ट्री (अनस्टेज्ड) में वापस जाते हैं
git reset HEAD~1

HEAD~1 का मतलब है “जहाँ HEAD अभी इशारा कर रहा है, उससे एक कमिट पहले”। दोनों में से कोई भी कमांड चलाने के बाद आपकी फ़ाइलें डिस्क पर अछूती रहती हैं — सिर्फ़ ब्रांच पॉइंटर हिलता है। git status से जाँच लीजिए: --soft के साथ बदलाव स्टेज्ड रहते हैं, फ़िक्स जोड़कर दोबारा कमिट के लिए तैयार; बिना फ़्लैग के वे अनस्टेज्ड रहते हैं, ताकि पहले आज़ादी से एडिट कर सकें।

सिर्फ़ आख़िरी कमिट में फ़ाइलें जोड़नी हों, तो ज़्यादा सुरक्षित आदत है — अन-डू करें ही मत:

git add forgotten-file.txt
git commit --amend --no-edit

--amend आख़िरी कमिट को उसकी जगह बदल देता है (यहाँ कमिट मैसेज नहीं बदला)। ध्यान रखें कि पुश किए हुए कमिट को amend करना हिस्ट्री दोबारा लिखता है — इस पर आगे और भी बात है।

—soft, —mixed और —hard में क्या फ़र्क़ है?

यही हिस्सा रटने लायक है, क्योंकि फ़्लैग तय करता है कि आपके बदलाव कहाँ पहुँचेंगे — और वे खो सकते हैं या नहीं:

फ़्लैग	कमिट रद्द?	बदलाव डिस्क पर	बदलाव स्टेज्ड?	आम इस्तेमाल
--soft	हाँ	बचे रहते हैं	हाँ	छोटे फ़िक्स के साथ दोबारा कमिट
--mixed (डिफ़ॉल्ट)	हाँ	बचे रहते हैं	नहीं	बदलाव फिर से बाँटें, चुन-चुनकर स्टेज करें
--hard	हाँ	मिट जाते हैं	—	काम को पूरी तरह फेंक दें
git revert	नहीं (नया कमिट)	बचे रहते हैं	—	पहले से पुश हो चुका कमिट रद्द करें

--hard अकेला ख़तरनाक है: यह कमिट और बदलाव — दोनों फेंक देता है। किसी भी reset --hard से पहले अपना काम stash करें या ब्रांच बना लें:

git branch backup-before-reset   # सस्ता बीमा
git reset --hard HEAD~1          # कमिट + बदलाव — दोनों गए

अगर ख़तरनाक वाला वर्ज़न पहले ही चल चुका है, तो सब खोया नहीं है — git reflog याद रखता है कि HEAD कहाँ-कहाँ रहा:

git reflog                       # खोया हुआ कमिट हैश ढूँढ़ें
git reset --hard HEAD@{1}        # या फिर: git reset --hard <hash>

reflog डिफ़ॉल्ट रूप से लटके हुए कमिट्स करीब 90 दिन तक रखता है, इसलिए “मैंने ग़लती से hard-reset कर दिया” लगभग हमेशा वापस लाया जा सकता है — बशर्ते garbage collection से पहले हिल जाएँ।

कमिट पहले ही पुश हो चुका है तो क्या करें?

अगर कमिट शेयर्ड ब्रांच पर है (अपनी प्राइवेट फ़ीचर ब्रांच के अलावा कुछ भी), तो हिस्ट्री मत दोबारा लिखिए। git revert इस्तेमाल कीजिए, जो उलटा बदलाव निकालकर उसे कमिट कर देता है:

git revert HEAD
git push

जो लोग pull करेंगे उन्हें सीधा एक नया कमिट मिलेगा जो पुराने के बदलाव हटा देता है। कोई force-push नहीं, कोई टूटे हुए सहकर्मी नहीं। कई कमिट्स एक साथ रद्द करने हों तो रेंज revert कीजिए: git revert --no-commit HEAD~3..HEAD && git commit।

दूसरा रास्ता — git reset --hard HEAD~1 && git push --force-with-lease — तभी मंज़ूर है जब ब्रांच पर कोई और काम न करता हो, और --force-with-lease (कभी भी खाली --force नहीं) अकेला सुरक्षित रूप है, क्योंकि बीच में किसी ने पुश किया हो तो यह इनकार कर देता है। शेयर्ड ब्रांच पर force-push ही वह तरीका है जिससे टीमों के कमिट्स खोते हैं और CI के लॉग रहस्यमयी तरीक़े से सबकी चेकआउट से मेल खाना बंद कर देते हैं।

आख़िरी कमिट अन-डू करें, पर उसे बाद के लिए सुरक्षित कैसे रखें?

कभी-कभी कमिट अच्छा काम है, बस ग़लत पते पर — ग़लत ब्रांच पर, या बहुत जल्दी। उसे अन-डू करने की जगह खिसका दीजिए:

git branch stash-commit          # कमिट को नई ब्रांच पर पार्क करें
git reset --hard HEAD~1          # फिर अपनी मौजूदा ब्रांच साफ़ करें

या सिर्फ़ उस कमिट को दूसरी ब्रांच पर ले जाइए, बिना अपनी मौजूदा ब्रांच को छुए:

git cherry-pick <hash>           # जब आप टारगेट ब्रांच पर हों

reset --soft, cherry-pick और revert के बीच ऐसा कोई कमिट नहीं जिसे आप खिसका न सकें या रद्द न कर सकें — ज़ुग्लबाँदी बस यह है कि फ़्लैग तक पहुँचने से पहले “खिसकाना” बनाम “रद्द करना” चुन लिया जाए।

कौन-सा अन-डू इस्तेमाल करें? एक छोटा फ़ैसला गाइड

1. पुश नहीं हुआ, ठीक करके दोबारा कमिट करना है → git reset --soft HEAD~1
2. पुश नहीं हुआ, चुन-चुनकर दोबारा स्टेज करना है → git reset HEAD~1 (mixed)
3. बदलाव पूरी तरह जाते रहें → git reset --hard HEAD~1 (पछताएँगे तो reflog जानता है)
4. शेयर्ड ब्रांच पर पहले ही पुश हो चुका है → git revert HEAD
5. कमिट दरअसल दूसरी ब्रांच का है → cherry-pick, अन-डू नहीं

एक आख़िरी ऑपरेशनल बात: अगर कोई ग़लत कमिट सर्वर तक पहुँच गया है — बिगड़ा हुआ deploy हुक, force-push के बाद बिगड़ जाने वाला CI रनर — तो अगली जगह मशीन के लॉग हैं, Git नहीं। किसी भी systemd वाली मशीन पर journalctl -u <service> -n 100 साफ़ दिखा देता है कि क्या चला और कब; हमारी journalctl cheat sheet में कॉपी-पेस्ट पैटर्न मौजूद हैं। और अगर आपके वर्कफ़्लो में डिफ़ रिव्यू के लिए लोकल LLM टूलिंग शामिल है, तो हमने दो मुख्य विकल्पों की तुलना Ollama vs LM Studio में की है।