एक मर्ज कमिट को वापस कैसे करें जो पहले से ही दूरस्थ शाखा में धकेल दिया गया है?

959

git revert <commit_hash>अकेले काम नहीं करेगा। -mनिर्दिष्ट किया जाना चाहिए, और मैं इसके बारे में बहुत भ्रमित हूं।

इससे पहले किसी को यह अनुभव हुआ?

git

— Yaz
स्रोत

3

इस प्रश्न के उत्तर पर एक नज़र डालें: stackoverflow.com/questions/2318777/…

— eugen

2

संबंधित: पूर्ववत एक मर्ज? ।

यहाँ लिंक सबसे अच्छा उदाहरण है जो मर्ज किए गए वचन का सम्मान करते हुए दिखाता है: christianengvall.se/undo-pushed-merge-git

— SK Venkat

यह एक उदाहरण है जहां डिजाइन सभी-उपयोग वर्कफ़्लो से gitमेल नहीं खाता है git-flow। यदि आपने developचेक-आउट कर लिया है, तो निश्चित रूप से आप 2-प्रतिबद्ध फीचर ब्रांच को वापस लाना चाहते हैं , जो बग को प्रस्तुत किए हुए है और न कि वर्षों तक साझा की गई ईकाई शाखा। इसे लेने के लिए हास्यास्पद की आवश्यकता महसूस होती है -m 1।

— pkamb

2

सिर्फ एक अन्य सुझाव जो मुझे पहले कभी नहीं हुआ - यदि शाखाओं की सूची में से एक छोटा है, तो आप कमिट की पूरी शाखा के बजाय व्यक्तिगत कमिट्स को अधिक सहज महसूस कर सकते हैं।

— श्रीधर सरनोबत

1152

-mविकल्प निर्दिष्ट करता है माता पिता संख्या । इसका कारण यह है कि एक मर्ज कमिट में एक से अधिक माता-पिता होते हैं, और Git को स्वचालित रूप से नहीं पता होता है कि कौन सा पैरेंट मेनलाइन था, और कौन सा पैरेंट वह शाखा है जिसे आप मर्ज करना चाहते हैं।

जब आप के उत्पादन में एक मर्ज कमिट git logदेखते हैं, तो आप उसके माता-पिता को उस लाइन पर सूचीबद्ध देखेंगे जो इसके साथ शुरू होती है Merge:

commit 8f937c683929b08379097828c8a04350b9b8e183
Merge: 8989ee0 7c6b236
Author: Ben James <ben@example.com>
Date:   Wed Aug 17 22:49:41 2011 +0100

Merge branch 'gh-pages'

Conflicts:
    README

इस स्थिति में, git revert 8f937c6 -m 1आपको पेड़ मिलेगा जैसा कि वह था 8989ee0, और git revert -m 2पेड़ को फिर से स्थापित कर देगा जैसा कि वह अंदर था 7c6b236।

माता-पिता की आईडी को बेहतर ढंग से समझने के लिए, आप चला सकते हैं:

git log 8989ee0

तथा

git log 7c6b236

— बेन जेम्स
स्रोत

126

दो नंबर से 8989ee0, 7c6b236है, जो एक जाने के लिए। मैं कैसे समझूंगा?

— अरूप रक्षित

12

वापस आने के बाद, मुझे नहीं लगता कि स्रोत शाखा में कोड को आसानी से ठीक करने और फिर से विलय करने में सक्षम होगा ? kernel.org/pub/software/scm/git/docs/howto/…

— IsmailS

10

बेहतर स्पष्टीकरण की तलाश में घूमने के दौरान, मुझे यह लेख मिला जो मुझे लगा कि विवरणों पर जाने का एक बड़ा काम किया है। मुझे यह पढ़ने के बाद पता चला कि जो मैं वास्तव में खोज रहा था वह RESET कमांड था, उसके बाद एक बल धक्का था। शायद यह किसी और की मदद करेगा। atlassian.com/git/tutorials/…

— फनकट्र्न

46

@ अरूप रक्षित यदि आप दौड़ते हैं git log 8989ee0और git log 7c6b236आपको इसका उत्तर जानना चाहिए।

— बीएमडब्ल्यू

4

git लॉग - सभी मर्ज देखने के लिए और git लॉग -इन-मर्ज विलय के बिना इतिहास देखने के लिए। एक शाखा को विलय करके लक्षित इतिहास में विलय कर दिया जाता है और सादे गिट लॉग का उपयोग करके इसे बनाना मुश्किल हो जाता है

— एलेक्स पुन्नन

368

यहाँ इस उम्मीद में एक पूरा उदाहरण है कि यह किसी की मदद करता है:

git revert -m 1 <commit-hash> 
git push -u origin master

कहाँ <commit-hash>मर्ज के हैश है कि आप वापस लौटने के लिए चाहते हैं के लिए प्रतिबद्ध है, और के रूप में की व्याख्या में कहा गया है इस सवाल का जवाब , -m 1इंगित करता है कि आप मर्ज करने से पहले पहले माता-पिता के पेड़ पर वापस लौटने करना चाहते हैं।

git revert ...लाइन अनिवार्य रूप से अपने परिवर्तन करता है, जबकि दूसरी पंक्ति अपने परिवर्तनों को उन्हें दूरदराज के शाखा को धक्का द्वारा सार्वजनिक बनाता है।

— शहीद
स्रोत

21

मुझे विश्वास था कि git revertकमांड ने पहले से ही बनाई गई वस्तु वस्तु की सराहना की है। ऐसा न हो इसके लिए आपको --no-commitध्वज का प्रयोग करना होगा

— Delfic

2

जैसा कि @Delfic ने उल्लेख किया है, प्रतिबद्ध पहले से ही पहली पंक्ति द्वारा प्रबंधित है (मुझे इसे सत्यापित करने के लिए a: wq की आवश्यकता है) इसलिए दूसरी पंक्ति आवश्यक नहीं है।

— eka808

1

यह भ्रामक है। केवल 2 लाइनें हैं और कोई कमिट नहीं है .. क्या कोई कृपया संपादित कर सकता है।

— जे रैंडम

176

बेन ने आपको बताया है कि एक मर्ज कमेटी को वापस कैसे करना है, लेकिन ऐसा करना बहुत महत्वपूर्ण है

"... घोषणा करता है कि आप कभी भी मर्ज द्वारा लाए गए पेड़ के बदलावों को नहीं चाहेंगे। नतीजतन, बाद में मर्ज केवल पेड़ों के बदलाव लाएंगे जो कि पहले से मर्ज किए गए मर्ज के पूर्वजों नहीं हैं। यह हो सकता है या नहीं। आप क्या चाहते हैं। " (गिट-मर्ज मैन पेज) ।

मैन पेज से जुड़े एक लेख / मेलिंग सूची संदेश में शामिल तंत्र और विचारों का विवरण है। बस यह सुनिश्चित कर लें कि यदि आप मर्ज कमिट को वापस करते हैं, तो आप ब्रांच को बाद में फिर से मर्ज नहीं कर सकते हैं और वही बदलाव वापस आने की उम्मीद कर सकते हैं।

— रयान स्टीवर्ट
स्रोत

80

लेकिन आप उन्हें वापस लाने के लिए वापस ला सकते हैं अगर वास्तव में जरूरत हो।

— देहरादून

5

धन्यवाद। एक मर्ज को पूर्ववत करने के लिए उपयोग के मामले के रूप में जानने के लिए बहुत उपयोगी है - एक बग के कारण, कहते हैं - और फिर बग को ठीक करने के बाद पूरी शाखा को फिर से मर्ज करना, एक सामान्य है।

— घटक 10

3

यदि आप मेरी तरह हैं और बाद में चाहते हैं कि मर्ज आप या तो रिवर्ट वापस कर सकते हैं, या चेरी आपके द्वारा बदले गए बदलाव को चुन सकते हैं।

— यूनिटासब्रुक

अपनी स्थिति में, मैंने अपने परिवर्तन-बैक-इश्यू को प्राप्त करने के लिए 'रिवर्ट रिवर्ट' करने के लिए हिट किया। चेरी-पिकिंग एक भद्दा तरीका हो सकता है? मैं अगली बार कोशिश करूँगा ...

— स्टीवन एंडरसन

79

आप गलत कदम वापस करने के लिए या HEAD / स्थिति को ठीक करने के लिए अपनी दूरस्थ शाखा को रीसेट करने के लिए इन चरणों का पालन कर सकते हैं।

दूरस्थ शाखा को स्थानीय रिपो में चेकआउट करें।
git checkout development
git लॉग से कमिट हैश (यानी गलत कमिटमेंट से तुरंत पहले आईडी) को कॉपी करें git log -n5

उत्पादन:

प्रतिबद्ध 7cd42475d6f95f5896b6f02e902efab0b70e8038 "मर्ज शाखा 'विकास' में 'गलत-लिखें'"
प्रतिबद्ध f9a734f8f44b0b37ccea769b9a2fd774c0f0c012 "यह एक गलत है प्रतिबद्ध"
प्रतिबद्ध 3779ab50e72908da92d2cfcd72256d7a09f446ba "यह सही है प्रतिबद्ध"
पिछले चरण में कॉपी किए गए प्रतिबद्ध हैश को शाखा रीसेट करें
git reset <commit-hash> (i.e. 3779ab50e72908da92d2cfcd72256d7a09f446ba)
git statusउन सभी परिवर्तनों को दिखाने के लिए चलाएं जो गलत प्रतिबद्ध का हिस्सा थे।
बस git reset --hardउन सभी परिवर्तनों को वापस लाने के लिए दौड़ें ।
बलपूर्वक अपनी स्थानीय शाखा को रिमोट पर धकेलें और ध्यान दें कि आपका प्रतिबद्ध इतिहास साफ है क्योंकि यह प्रदूषित होने से पहले था।
git push -f origin development

— ssasi
स्रोत

4

क्या होगा अगर इस बीच 20 डेवलपर्स ने नवीनतम देव मर्ज खींच लिया?

— इवोक

2

जब टीम में 20 डिवेलपर्स होते हैं तो मैं उस ब्रांच का इस्तेमाल करने पर जोर नहीं देता। :) उस मामले में, यह केवल एक वापस करने के लिए बुद्धिमान है।

— ssasi

4

यह एक बहुत अच्छा उपाय है जब आप अपने आप से काम कर रहे हैं या आप निश्चित हैं कि कोई अन्य देवता आपके द्वारा किए गए कमिट को नहीं खींचता है

— काइल बी

52

git revert -m 1 <merge-commit>

— नीरज कुमार
स्रोत

2

इस उत्तर में बहुत सारे विवरणों का अभाव है। शायद इसीलिए यह अच्छा है।

— गुस्तावो स्ट्राबे

30

लॉग को साफ रखने के लिए कुछ भी नहीं हुआ (इस दृष्टिकोण के साथ कुछ डाउनसाइड के साथ (पुश -फ के कारण)):

git checkout <branch>
git reset --hard <commit-hash-before-merge>
git push -f origin HEAD:<remote-branch>

'कमिट-हैश-पहले-मर्ज' मर्ज के बाद लॉग (गिट लॉग) से आता है।

— NVD
स्रोत

संकेत: यदि आप अपनी कंपनी में ऐसा कर रहे हैं, तो आपके पास अनुमति नहीं हो सकती है।

— 11

3

push -fएक साझा रेपो पर कभी मत करो

— बैपटिस्ट मिल-मैथियस

17

कभी-कभी रोलबैक करने का सबसे प्रभावी तरीका पीछे हटना और बदलना है।

git log

2 वें प्रतिबद्ध हैश (पूर्ण हैश, आप जिसे वापस सूचीबद्ध करना चाहते हैं, गलती सूचीबद्ध होने से पहले) का उपयोग करें और फिर वहां से पुन: प्राप्त करें।

git checkout -b newbranch <HASH>

फिर पुरानी शाखा को हटा दें, उसके स्थान पर न्यूब्रांच को कॉपी करें और वहां से पुनरारंभ करें।

git branch -D oldbranch
git checkout -b oldbranch newbranch

यदि इसका प्रसारण किया गया है, तो सभी रिपॉजिटरी से पुरानी शाखा को हटा दें, फिर से शाखा को सबसे केंद्रीय में धकेलें, और इसे वापस नीचे सभी तक खींचें।

— ppostma1
स्रोत

4

प्रसारण के बारे में चेतावनी वास्तव में इस बारे में अधिक स्पष्ट होनी चाहिए कि यह एक विचार कितना भयानक है। यह उस शाखा के सभी संस्करण को दूषित कर देगा और केवल तभी उपयोगी होगा जब आप एक दूरस्थ रिपॉजिटरी (github / bitbucket) के साथ काम कर रहे हों, जिसमें केवल आपकी पहुंच हो।

— रॉबडी

नहीं के रूप में बुरा के रूप में संशोधित करने के लिए उत्पादन के लिए धारा नीचे फाइल को धक्का धक्का। यह भ्रष्ट नहीं होगा, यह सिर्फ एक पूर्व कमिट से एक रिफ्रैन्च है, इसलिए शाखाओं के पॉइंटर को एक पुराने संस्करण में ले जाने का एक गोल-गोल तरीका है। उम्मीद है कि यह केवल स्थानीय रिपॉजिटरी को प्रभावित करता है

— ppostma1

5

यदि आप एक mergeकमिट वापस करना चाहते हैं, तो यहां आपको करना है।

सबसे पहले, git logअपने मर्ज कमिट की आईडी खोजने के लिए जांचें । आपको मर्ज से जुड़ी कई पेरेंट आईडी भी मिलेंगी (नीचे चित्र देखें)।

पीले रंग में दिखाई गई मर्ज कमेटी आईडी पर ध्यान दें। माता-पिता की आईडी अगली पंक्ति में लिखी गई हैं Merge: parent1 parent2। अभी...

लघु कथा:

उस शाखा पर स्विच करें जिस पर मर्ज किया गया था। उसके बाद बस वह करें git revert <merge commit id> -m 1जिसमें viकमिट मैसेज डालने का कंसोल होगा । लिखें, सहेजें, बाहर निकलें, किया!

लम्बी कहानी:

उस शाखा पर स्विच करें जिस पर मर्ज किया गया था। मेरे मामले में, यह testशाखा है और मैं feature/analytics-v3शाखा को इससे हटाने की कोशिश कर रहा हूं ।
git revertवह आदेश है जो किसी भी प्रतिबद्धता का सम्मान करता है। लेकिन एक mergeप्रतिबद्ध करने के बाद एक बुरा चाल है । आपको -mध्वज में प्रवेश करने की आवश्यकता है अन्यथा यह विफल हो जाएगा। यहां से, आपको यह तय करने की आवश्यकता है कि क्या आप अपनी शाखा को वापस करना चाहते हैं और इसे वैसा ही बनाना चाहते हैं, जैसा कि यह parent1या इसके parent2माध्यम से था:

git revert <merge commit id> -m 1(श्रद्धेय parent2)

git revert <merge commit id> -m 2(श्रद्धेय parent1)

आप इन अभिभावकों से यह पता लगाने के लिए लॉग इन कर सकते हैं कि आप किस रास्ते पर जाना चाहते हैं और यही सारे भ्रम की जड़ है।

— saran3h
स्रोत

5

सभी उत्तर पहले से ही अधिकांश चीजों को कवर कर चुके हैं लेकिन मैं अपने 5 सेंट जोड़ूंगा। संक्षेप में मर्ज करने की प्रतिबद्धता काफी सरल है:

git revert -m 1 <commit-hash>

यदि आपके पास अनुमति है तो आप इसे सीधे "मास्टर" शाखा में धकेल सकते हैं अन्यथा बस इसे अपनी "रिवर्ट" शाखा में धकेल दें और पुल अनुरोध बनाएं।

आपको इस विषय पर अधिक उपयोगी जानकारी यहाँ मिल सकती है: https://itcodehub.blogspot.com/2019/06/how-to-revert-merge-in-git.html

— xproph
स्रोत

1

मैंने पाया कि दो अंत बिंदुओं के बीच एक रिवर्स पैच बनाया गया और उस पैच को लगाने से काम होगा। यह माना जाता है कि आपने अपनी मास्टर ब्रांच से स्नैपशॉट (टैग) बनाए हैं या यहां तक कि अपनी मास्टर ब्रांच का बैक अप भी मास्टर_बेक_01012017 कहते हैं।

मान लें कि आपके द्वारा मास्टर में विलय की गई कोड शाखा mycodebranch थी।

चेकआउट मास्टर।
मास्टर और आपके बैकअप के बीच एक पूर्ण बाइनरी रिवर्स पैच बनाएं। git diff --binary master..master_bk_01012017 > ~/myrevert.patch
अपने पैच की जाँच करें git apply --check myrevert.patch
साइन-ऑफ के साथ पैच लागू करें git am --signoff < myrevert.patch
यदि आपको इस कोड को एक बार तय करने के बाद फिर से लाना होगा, तो आपको उल्टे मास्टर की शाखा और फिक्स शाखा की जांच करनी होगी git branch mycodebranch_fix git checkout mycodebranch_fix
यहां आपको रिवर्ट के लिए SHA कुंजी ढूंढनी होगी और रिवर्ट को वापस करना होगा git revert [SHA]
अब आप अपने mycodebranch_fix का उपयोग मुद्दों को ठीक करने के लिए कर सकते हैं, कमिट कर सकते हैं और एक बार किए गए मास्टर में फिर से विलय कर सकते हैं।

— alexplain
स्रोत

1

सही ढंग से चिह्नित उत्तर ने मेरे लिए काम किया लेकिन मुझे व्हाट्सएप के निर्धारण के लिए कुछ समय बिताना पड़ा .. इसलिए मैंने अपने जैसे मामलों के लिए सरल सरल कदमों के साथ उत्तर जोड़ने का फैसला किया।

कहते हैं कि हमें शाखाएँ A और B मिलीं .. आपने शाखा A को शाखा B में मिला दिया और शाखा B को स्वयं में धकेल दिया, इसलिए अब विलय इसका हिस्सा है .. लेकिन आप विलय से पहले अंतिम प्रतिबद्ध पर वापस जाना चाहते हैं .. क्या करते हैं तुम करो?

अपने git रूट फ़ोल्डर (आमतौर पर प्रोजेक्ट फ़ोल्डर) पर जाएं और उपयोग करें git log
आप हाल के कमिट्स का इतिहास देखेंगे - कमिट्स में कमिट / लेखक / डेट प्रॉपर्टीज होती हैं जबकि मर्ज में भी एक मर्ज प्रॉपर्टी होती है - इसलिए आप उन्हें इस तरह देखते हैं:

commit: <commitHash> Merge: <parentHashA> <parentHashB> Author: <author> Date: <date>
का प्रयोग करें git log <parentHashA>और git log <parentHashB>- नवीनतम होते हैं सूची में पहले प्रतिबद्ध - आप उन माता पिता शाखाओं के इतिहास के लिए प्रतिबद्ध देखेंगे
ले लो <commitHash>के लिए प्रतिबद्ध आप चाहते हैं, अपना Git रूट फ़ोल्डर और उपयोग करने के लिए जाने git checkout -b <newBranchName> <commitHash>- कि एक नई शाखा है कि पिछले से शुरू प्रतिबद्ध आपके द्वारा चुनी गई मर्ज से पहले .. देखा, तैयार पैदा करेगा!

— Божидар Йовчев
स्रोत

1

git doc के बारे में git revert -m एक लिंक प्रदान करते हैं जो वास्तव में इसे समझाता है: https://github.com/git/git/blob/master/Documentation/howto/revert-a-faulty-merge.txt

— Junyong
स्रोत

0

मुझे इस मुद्दे पर एक पीआर पर भी सामना करना पड़ा जिसे एक GitHub रेपो की मास्टर शाखा में मिला दिया गया है।

जब से मैं बस कुछ संशोधित फ़ाइलों को संशोधित करना चाहता था लेकिन नहीं पूरे परिवर्तन पीआर लाया, मैं करने के लिए किया था के साथ ।amendmerge commitgit commit --am

कदम:

उस शाखा पर जाएं जिसे आप कुछ संशोधित फ़ाइलों को बदलना / वापस करना चाहते हैं
संशोधित फ़ाइलों के अनुसार अपने इच्छित परिवर्तन करें
भागो git add *याgit add <file>
दौड़ें git commit --amऔर मान्य करें
Daud git push -f

यह दिलचस्प क्यों है:

यह पीआर के लेखक को अपरिवर्तित रखता है
यह गिट के पेड़ को नहीं तोड़ता है
आपको कमिटर के रूप में चिह्नित किया जाएगा (मर्ज कमेंट लेखक अपरिवर्तित रहेगा)
Git अधिनियम के रूप में यदि आप संघर्ष का समाधान, यह संशोधित फ़ाइलों में कोड को हटा / बदल देगा जैसे कि आप मैन्युअल रूप से GitHub को इसे मर्ज करने के लिए नहीं कहते हैं।

— मैक्सिमे लाफारी
स्रोत

0

मुझे इस लिंक से मर्ज को वापस लाने के लिए अच्छी व्याख्या मिली और मैंने नीचे दिए गए स्पष्टीकरण को कॉपी किया और यदि नीचे लिंक काम नहीं करता है तो यह उपयोगी होगा।

एक दोषपूर्ण विलय को वापस कैसे करें एलन (alan@clueserver.org) ने कहा:

मेरी एक मास्टर ब्रांच है। हमारी एक शाखा है जो कुछ डेवलपर्स काम कर रहे हैं। उनका दावा है कि यह तैयार है। हम इसे मास्टर शाखा में विलय कर देते हैं। यह कुछ तोड़ता है इसलिए हम मर्ज वापस कर देते हैं। वे कोड में परिवर्तन करते हैं। वे इसे एक बिंदु पर ले जाते हैं, जहां वे कहते हैं कि यह ठीक है और हम फिर से विलय कर देते हैं। जब जांच की जाती है, तो हम पाते हैं कि रिवर्ट से पहले किए गए कोड परिवर्तन मास्टर ब्रांच में नहीं होते हैं, लेकिन मास्टर ब्रांच में कोड परिवर्तन के बाद होते हैं। और इस स्थिति से उबरने के लिए मदद मांगी।

"मर्ज के वापस आने" के तुरंत बाद का इतिहास इस तरह दिखेगा:

---o---o---o---M---x---x---W
              /
      ---A---B

जहाँ A और B उस साइड डेवलपमेंट पर हैं जो इतना अच्छा नहीं था, M वह मर्ज है जो इन प्रीमेच्योर बदलावों को मेनलाइन में लाता है, x उन परिवर्तनों से असंबंधित है जो साइड ब्रांच ने किए थे और पहले से ही मेनलाइन पर किए गए थे, और W "है" मर्ज M के पीछे "(W, M को उल्टा नहीं देखता है?)। IOW, "diff W ^ .. W" "diff -RM ^ .. M" के समान है।

इस तरह के एक "वापसी" के साथ बनाया जा सकता है:

$ git रिवर्ट -m 1 M साइड शाखा के डेवलपर्स अपनी गलतियों को ठीक करने के बाद, इतिहास इस तरह दिख सकता है:

---o---o---o---M---x---x---W---x
              /
      ---A---B-------------------C---D

जहाँ C और D को A और B में जो टूट गया था उसे ठीक करना है, और W के बाद मेनलाइन पर आपके पास पहले से ही कुछ अन्य बदलाव हो सकते हैं।

यदि आप अपडेटेड साइड ब्रांच (इसके टिप पर D के साथ) को मर्ज करते हैं, तो ए या बी में किए गए परिवर्तनों में से कोई भी परिणाम में नहीं होगा, क्योंकि वे डब्ल्यू द्वारा वापस कर दिए गए थे।

लिनस स्थिति बताते हैं:

नियमित रूप से कमिट करना केवल प्रभावी ढंग से कम करता है जो कि किया, और काफी सीधा है। लेकिन एक मर्ज कमिटमेंट को वापस लाने से भी डेटा बदल जाता है कि कमेट बदल गया है, लेकिन यह इतिहास पर उन प्रभावों के लिए बिल्कुल कुछ नहीं करता है जो मर्ज़ के पास थे। तो मर्ज अभी भी मौजूद रहेगा, और इसे अभी भी दो शाखाओं को एक साथ मिलाने के रूप में देखा जाएगा, और भविष्य के मर्ज उस विलय को अंतिम साझा स्थिति के रूप में देखेंगे - और वापस लाए गए मर्ज को वापस लाएंगे जो कि बिल्कुल भी प्रभावित नहीं करेगा। इसलिए "रिवर्ट" डेटा में बदलाव को पूर्ववत करता है, लेकिन यह बहुत अधिक है नहीं हैएक "पूर्ववत" इस अर्थ में कि यह रिपॉजिटरी इतिहास पर एक प्रतिबद्ध के प्रभाव को पूर्ववत नहीं करता है। इसलिए यदि आप "पूर्ववत करें" को "पूर्ववत" मानते हैं, तो आप हमेशा श्रद्धा के इस हिस्से को याद करेंगे। हां, यह डेटा को पूर्ववत करता है, लेकिन नहीं, यह इतिहास को पूर्ववत नहीं करता है। ऐसी स्थिति में, आप पहले वाले रिवर्ट को पहले वापस करना चाहेंगे, जिससे इतिहास इस तरह दिखाई देगा:

---o---o---o---M---x---x---W---x---Y
              /
      ---A---B-------------------C---D

जहां Y, W का पुनर्निमाण है। ऐसा "रिवर्ट का रिवर्ट" के साथ किया जा सकता है:

$ git W को वापस लाएगा यह इतिहास होगा (जो कि W और W..Y बदल गया है, के बीच संभावित संघर्षों की अनदेखी करना) इतिहास में W या Y के बिल्कुल न होने के बराबर होगा:

---o---o---o---M---x---x-------x----
              /
      ---A---B-------------------C---D

और साइड ब्रांच को फिर से मर्ज करने से पहले के रिवर्ट और रिवर्ट के रिवर्ट से उत्पन्न होने वाले संघर्ष नहीं होंगे।

---o---o---o---M---x---x-------x-------*
              /                       /
      ---A---B-------------------C---D

बेशक सी और डी में किए गए परिवर्तन अभी भी किसी भी एक्स द्वारा किए गए के साथ संघर्ष कर सकते हैं, लेकिन यह सिर्फ एक सामान्य मर्ज संघर्ष है।

— MK446
स्रोत

-2

जैसा कि रेयान ने उल्लेख किया है, git revertसड़क के नीचे विलय मुश्किल बना सकता है, इसलिए git revertऐसा नहीं हो सकता है जो आप चाहते हैं। मैंने पाया कि git reset --hard <commit-hash-prior-to-merge>कमांड का उपयोग यहां अधिक उपयोगी है।

एक बार जब आप हार्ड रीसेट भाग कर लेते हैं, तो आप दूरस्थ शाखा को धक्का दे सकते हैं, अर्थात git push -f <remote-name> <remote-branch-name>, जहाँ <remote-name>अक्सर नाम दिया जाता है origin। यदि आप चाहें तो उस बिंदु से आप फिर से विलय कर सकते हैं।

— हैरी वांग
स्रोत

4

कुछ भी जिसमें बल-धक्का शामिल है, एक बुरा विचार है जब तक कि आप केवल रेपो का उपयोग करने वाले व्यक्ति नहीं हैं, और आप वास्तव में जानते हैं कि आप क्या कर रहे हैं। Git रिवर्ट के साथ रिवर्टिंग और फिर संभवतः रिवर्ट को git रिवर्ट (यदि आपको चीजों को फिर से वापस लाने की जरूरत है) के साथ रिवर्टिंग करना ज्यादा सुरक्षित विकल्प है।

— ओयविंद