Git में पिछला कमिट Revert करें: बदलाव को सुरक्षित रूप से कैसे Undo करें

सॉफ्टवेयर विकास में गलतियाँ स्वाभाविक हैं, लेकिन उन्हें कैसे संभाला जाता है यह खासकर टीम में काम करते समय मायने रखता है।

जब आप shared रिपोजिटरी में Git के साथ काम करते हैं, तो आप सिर्फ एक खराब कमिट को undo नहीं करना चाहते—आप उसे सुरक्षित तरीके से करना चाहते हैं। इसी वजह से मैंने अपने अनुभव के आधार पर git revert पर यह लेख लिखा है।

git reset की तरह इतिहास मिटाने के बजाय, git revert एक नया कमिट बनाता है जो पिछले कमिट में किए गए बदलावों को उलट देता है। यह तरीका आपके कमिट इतिहास को सुरक्षित रखता है।

यदि आप इन कॉन्सेप्ट्स में नए हैं, तो हमारा Git Fundamentals स्किल ट्रैक लें और रिपोजिटरी तथा वर्ज़न कंट्रोल के बारे में सब कुछ सीखें।

Git Revert क्या है, और यह कैसे काम करता है?

git revert को ऐसे समझें जैसे Git कह रहा हो, "आइए इसे सुरक्षित तरीके से undo करें।" जब किसी कमिट में कुछ गलत रह जाए — जैसे कोई बग, टाइपो, या जल्दबाज़ी में किया गया बदलाव — तो उसे हटाने का मन हो सकता है। लेकिन shared repo में इतिहास मिटाना मूल गलती से ज्यादा परेशानी खड़ी कर सकता है। यही वजह है कि git revert मौजूद है। कमिट मिटाने के बजाय, यह एक नया कमिट जोड़ता है जो उन बदलावों को रद्द कर देता है।

तो, git revert क्या करता है?

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

• यह बदलाव तुरंत लागू करता है: जैसा कि मैंने अब तक नहीं कहा था, जैसे ही आप git revert कमांड चलाते हैं, revert किए गए बदलाव आपकी working directory में दिखने लगते हैं। यानी आप फिक्स को तुरंत देख पाएंगे।

• यह स्टेजिंग में दखल नहीं देता (जब तक कॉन्फ्लिक्ट न हो): एक और बात जानने लायक: Git revert को आंतरिक रूप से संभालता है। अगर सब कुछ सुचारू रहा, तो फाइलों को मैन्युअली स्टेज करने की ज़रूरत नहीं पड़ती। लेकिन अगर Git किसी बदलाव को उलटना समझ नहीं पाता (जैसे जटिल merges में), तो वह आपसे हस्तक्षेप कर मदद मांगता है।

कमिट Revert करने के बाद क्या होता है

तो, आपने git revert चला दिया। अब हुआ क्या? कुछ भी मिटाने के बजाय, Git एक नया कमिट बनाता है जो टार्गेट किए गए कमिट में किए गए बदलावों को उलट देता है। यह नया कमिट आपके मौजूदा इतिहास के ऊपर जोड़ दिया जाता है, यानी मूल कमिट जस का तस और पूरी तरह दिखता रहता है। कुछ भी दोबारा नहीं लिखा जाता या हटाया नहीं जाता; Git बस एक परत जोड़ देता है जो प्रभावी रूप से कहती है, "इसे undo करें।" साथ ही, उस रिवर्सल से आई फाइल-स्तरीय बदलाएँ आपकी working directory में तुरंत लागू हो जाती हैं। आप प्रभाव को उसी तरह तुरंत देखेंगे जैसे किसी और कमिट के बाद।

यह पूरी प्रक्रिया git revert को उन गलतियों को ठीक करने का सबसे सुरक्षित तरीका बनाती है जिन्हें shared ब्रांच पर पहले ही पुश किया जा चुका है। टीम का हर सदस्य स्पष्ट रूप से देख सकता है कि क्या बदला, क्या revert हुआ, और क्यों—बिना किसी उलझन या चल रहे काम में बाधा के।

git revert बनाम git reset की तुलना

हालाँकि git revert और git reset दोनों का उपयोग कमिट्स को undo करने के लिए किया जा सकता है, वे बुनियादी तौर पर अलग तरीके से काम करते हैं। git reset लोकल, निजी फिक्स के लिए अच्छा है। यह आपको उलझे हुए कमिट्स को साफ करने और अपनी working directory को ठीक उसी तरह रीसेट करने देता है जैसे आप चाहते हैं। लेकिन एक पेंच है: अगर आपने अपना काम पहले ही पुश कर दिया है और फिर git reset किया, तो shared कमिट इतिहास बदलने से आप अपने साथियों के लिए चीज़ें बिगाड़ सकते हैं।

वहीं दूसरी ओर, git revert खास तौर पर shared या public ब्रांचों के लिए बनाया गया है। यह कुछ मिटाने के बजाय एक नया कमिट बनाता है जो पहले किए गए बदलावों को रद्द कर देता है। इससे shared प्रोजेक्ट्स में यह ज्यादा सुरक्षित रहता है।

इसे और स्पष्ट करने के लिए यहाँ साथ-साथ तुलना दी गई है:

एक से अधिक कमिट Revert करना

कभी-कभी समस्या सिर्फ एक खराब कमिट तक सीमित नहीं रहती—पूरी श्रृंखला को undo करना पड़ सकता है। सौभाग्य से, Git आपको एक कमांड में कमिट रेंज का उपयोग कर कई कमिट्स को revert करने देता है।

सिंटैक्स इस तरह दिखता है:

git revert OLDEST_HASH^..NEWEST_HASHसंचालित द्वारा

यह Git को बताता है कि सबसे पुराने कमिट से ठीक पहले से शुरू करे (यही ^ का मतलब है) और सबसे नए कमिट तक—उसे शामिल करते हुए—हर कमिट को revert करे। उदाहरण:

git revert a1b2c3d^..d4e5f6gसंचालित द्वारा

यह कमांड उस रेंज के हर मूल कमिट के लिए अलग-अलग revert कमिट्स बनाएगा।

ध्यान दें, एक साथ कई कमिट्स को revert करना अक्सर merge conflicts को ट्रिगर कर सकता है, खासकर जब वे कमिट्स एक ही फाइलों या लाइनों को छूते हैं। Git क्रम से हर कमिट को उलटने की कोशिश करेगा, लेकिन ओवरलैपिंग बदलावों के लिए आपकी मदद की ज़रूरत पड़ सकती है।

आप यह भी पढ़ सकते हैं कि Git revert ऑपरेशन्स को कैसे हैंडल करता है, जटिल मामलों जैसे merge commits पर हमारी Git Revert Merge Commit: A Guide With Examples में।

Revert के दौरान Merge Conflicts को संभालना

Revert करना सरल लगता है—जब तक Git आपको एक मुश्किल गेंद न फेंक दे: merge conflict। ये आम तौर पर तब आते हैं जब:

• आप ऐसा कमिट revert कर रहे हों जिसने उन्हीं लाइनों को बदला है जिन्हें हाल के अन्य कमिट्स ने भी बदला है।
• आप किसी merge commit को, या ओवरलैपिंग बदलावों वाले कमिट्स के समूह को revert कर रहे हों।

Git बदलावों को साफ़ तरीके से उलटने की पूरी कोशिश करता है, लेकिन जहाँ अस्पष्टता होती है वहाँ वह रुककर आपसे मदद मांगता है।

इसे इस तरह संभालें:

git revert HEADसंचालित द्वारा

और किन फाइलों में कॉन्फ्लिक्ट है, यह देखने के लिए:

git statusसंचालित द्वारा

अपने कोड एडिटर में कॉन्फ्लिक्ट्स को मैन्युअली हल करने के लिए <<<<<<<, =======, और >>>>>>> मार्कर्स देखें।

अब, मैं उन्हें resolved के रूप में मार्क कर रहा हूँ:

git add <resolved-file>संचालित द्वारा

अब, मैं revert जारी रखता हूँ:

git revert-- continueसंचालित द्वारा

अगर आप अपना मन बदल लें और revert को पूरी तरह रद्द करना चाहें:

git revert --abortसंचालित द्वारा

यह फ्लो आपको पूरा नियंत्रण देता है। आप तय कर सकते हैं कि revert आगे बढ़ाना है या पूरी तरह से पीछे हटना है।

यदि आप समझना चाहते हैं कि ऐसे ऑपरेशन्स के दौरान Git reference logs को कैसे ट्रैक रखता है, तो Git Reflog: Understanding and Using Reference Logs देखें—यह उलझे हुए इतिहासों को troubleshoot करने के सुझाव देता है।

विशेष मामले: Merge Commits को Revert करना

साधारण कमिट को revert करना सीधा है, लेकिन merge commits एक अलग ही चुनौती हैं। इसका कारण है कि एक merge commit के दो या अधिक पैरेंट होते हैं, और Git को जानना होता है कि किस पथ (या "mainline") को आधार माना जाए।

किसी merge commit को revert करने के लिए, आपको -m फ्लैग का स्पष्ट रूप से उपयोग करना होगा।

git revert -m 1 <merge-commit-hash>संचालित द्वारा

यहाँ -m फ्लैग क्या करता है:

• -m का अर्थ mainline है, और यह Git को बताता है कि किस पैरेंट कमिट को बनाए रखना है।

• 1 आमतौर पर पहले पैरेंट को संदर्भित करता है, यानी वह ब्रांच जिस पर आप merge करते समय थे।

• 2 दूसरे पैरेंट को संदर्भित करता है, यानी वह ब्रांच जिसे merge किया गया था।

1 या 2 का उपयोग कब करें?

• अगर आप merged-in बदलावों के प्रभाव को हटाना चाहते हैं लेकिन अपनी main ब्रांच का काम बनाए रखना चाहते हैं, तो -m 1 का उपयोग करें।

• अगर आप mainline के बदलावों को हटाना चाहते हैं लेकिन feature या merged ब्रांच की सामग्री बनाए रखना चाहते हैं, तो -m 2 का उपयोग करें। यह दुर्लभ है। किसी merge commit को revert करना कॉन्फ्लिक्ट-प्रवण होता है और अक्सर जटिल स्थिति पैदा करता है, खासकर जब आगे के कमिट्स उस पर निर्भर हों। यदि आप अनिश्चित हैं, तो पहले किसी टेस्ट ब्रांच पर revert करके देखें।

git revert का उपयोग करते समय सर्वोत्तम अभ्यास

git revert का बेहतरीन उपयोग करने और आम गलतियों से बचने के लिए, इन सर्वोत्तम अभ्यासों का ध्यान रखें:

• रीवर्ट करने से पहले कमिट हैश सत्यापित करें: हमेशा git log या git log-- oneline से अपना कमिट इतिहास देखें ताकि आप सही बदलाव को टार्गेट कर रहे हों। आप इन कमांड्स पर दोबारा नज़र डाल सकते हैं Foundations of Git में, या आवश्यक बातें हमारे Git Cheat Sheet के साथ हाथ में रखें।

• अपना कमिट संदेश अनुकूलित करें: Git का डिफ़ॉल्ट “Revert” संदेश ही पर्याप्त न मानें। संदर्भ जोड़ें—जैसे आपने कमिट क्यों revert किया—ताकि सहयोगियों (और भविष्य के आप) को बदलाव समझने में आसानी हो।

• शेयर की गई ब्रांच पर revert करते समय संवाद करें: अगर आप पब्लिक ब्रांच—जैसे main या develop—पर बदलावों को revert कर रहे हैं, तो पहले टीम को सूचित करें। Reverts सभी को प्रभावित करते हैं, इसलिए समन्वय करना बेहतर है। सहयोगी वर्कफ्लो के बारे में और जानें हमारे GitHub Concepts और Intermediate GitHub Concepts कोर्सेज़ में।

• किसी revert को फिर से revert करने से बचें, जब तक पक्का न हो: पिछले revert को revert करना अनचाहे बदलाव वापस ला सकता है या कॉन्फ्लिक्ट्स पैदा कर सकता है। यदि आपको कोई बदलाव फिर से लागू करना है, तो git cherry-pick का उपयोग करने पर विचार करें।

• अगर चीज़ें बिगड़ जाएँ तो रिकवरी के लिए reflog का उपयोग करें: क्या आपने बीच में गलती कर दी? हाल की क्रियाएँ देखने और खोई हुई स्टेट्स को रिकवर करने के लिए git reflog का उपयोग करें।

निष्कर्ष

यदि आप पेशेवर माहौल में सहयोग कर रहे हैं, तो git revert HEAD के साथ आख़िरी कमिट को revert करना पारदर्शिता बनाए रखता है और आकस्मिक डेटा हानि के जोखिम को कम करता है। चाहे आप कोई गलती साफ कर रहे हों या किसी बग को रोल बैक कर रहे हों, revert आपके repo को सभी संबंधित लोगों के लिए स्थिर और समझने योग्य रखता है।