पुल अनुरोध द्वारा मर्ज पूर्ववत करें?

Question

किसी ने एक पुल अनुरोध स्वीकार कर लिया जो उनके पास नहीं होना चाहिए था। अब हमारे पास टूटे हुए कोड का एक गुच्छा मिला है। आप एक पुल अनुरोध को कैसे पूर्ववत करते हैं? मैं मर्ज से ठीक पहले कमिटमेंट में हुए बदलावों को वापस करने जा रहा था, लेकिन मैंने देखा कि यह कमिट्स के एक समूह में विलीन हो गया। तो अब मर्ज होने के कुछ दिन पहले से ही इस व्यक्ति के ये सभी काम हैं। आप इसे कैसे पूर्ववत करते हैं?

Comments

स्वीकार किए गए उत्तर की सलाह के बावजूद, कृपया रिपॉजिटरी पर बल न दें, यदि रेपो किसी और के साथ साझा नहीं किया जाता है। आप दूसरों के किए गए काम को बर्बाद करने का जोखिम उठाते हैं, और GitHub यह दिखाना जारी रख सकता है कि पुल अनुरोध को विलय कर दिया गया है। इस सवाल का एक और जवाब एक पुल अनुरोध को पूर्ववत करने का एक सुरक्षित तरीका बताता है।

— अलक्षेंद्र

नोट: कम से कम अब (जून 2014), GitHub ने उनके Pull Request web GUI में "रिवर्ट" बटन प्रस्तावित किया है। देखें नीचे मेरा उत्तर

— VonC

रिवर्ट बटन के साथ मुद्दा यह है कि यह पुल अनुरोध के उलट एक नई प्रतिबद्धता बनाता है, जिसका अर्थ है कि यदि आप अंततः इन परिवर्तनों को मर्ज करना चाहते हैं, तो "रिवर्ट" बटन का उपयोग करके इसे और अधिक कठिन बना सकते हैं।

— फ्लिफ़सामुराई

Answer 1

इस समस्या का एक बेहतर जवाब है, हालांकि मैं इस कदम दर कदम टूट सकता है।

आपको नवीनतम अपस्ट्रीम परिवर्तनों को लाने और चेक करने की आवश्यकता होगी, जैसे:

git fetch upstream
git checkout upstream/master -b revert/john/foo_and_bar

कमिट लॉग पर एक नज़र डालते हुए, आपको कुछ इसी तरह का पता लगाना चाहिए:

commit b76a5f1f5d3b323679e466a1a1d5f93c8828b269
Merge: 9271e6e a507888
Author: Tim Tom <[e-mail]>
Date:   Mon Apr 29 06:12:38 2013 -0700

    Merge pull request #123 from john/foo_and_bar

    Add foo and bar

commit a507888e9fcc9e08b658c0b25414d1aeb1eef45e
Author: John Doe <[e-mail]>
Date:   Mon Apr 29 12:13:29 2013 +0000

    Add bar

commit 470ee0f407198057d5cb1d6427bb8371eab6157e
Author: John Doe <[e-mail]>
Date:   Mon Apr 29 10:29:10 2013 +0000

    Add foo

अब आप बाद में अप्रतिबंधित करने की क्षमता के साथ पूरे पुल अनुरोध को वापस करना चाहते हैं। ऐसा करने के लिए, आपको मर्ज कमिट की आईडी लेनी होगी ।

उपरोक्त उदाहरण में मर्ज कमिट सबसे ऊपर है, जहां यह कहता है "मर्ज पुल अनुरोध # 123 ..." ।

दोनों बदलावों को वापस करने के लिए ऐसा करें ( "बार जोड़ें" और "फू जोड़ें" ) और आप एक के बाद एक समाप्त होने वाले अनुरोध को पूरा करने का अनुरोध करेंगे, जिसे आप बाद में अनियंत्रित कर सकते हैं और परिवर्तनों के इतिहास को साफ रख सकते हैं:

git revert -m 1 b76a5f1f5d3b323679e466a1a1d5f93c8828b269

Comments

यह सही उत्तर होना चाहिए। Git-mailing लिस्ट के अधिक विवरण के लिए git-

— revert

क्यों git checkout upstream/master -b revert/john/foo_and_bar? यह वास्तव में क्या करता है?

— मैग्ने

@Magne - आप रिवर्ट करने के लिए एक नई शाखा का निर्माण कर रहे हैं, जिसे आप बाद में चुन सकते हैं कि रिवर्स को कहां मर्ज किया जाए। मूल रूप से बस आपको शाखा के साथ क्या करना है इसका अधिक नियंत्रण देता है। मेरे मामले में, मैंने इस "फिक्स्ड" शाखा से एक नया पुल अनुरोध प्रस्तुत किया, जिसमें हमारी विकास शाखा वापस आ गई थी, जिसका अर्थ है कि यदि आवश्यक हो तो मेरा नया पुल अनुरोध भी वापस किया जा सकता है। यह एक रिलीज के लिए किया गया था जहां हमने एक फीचर के पहले ड्राफ्ट को फिर से जारी करने का फैसला किया था। कोई बुरा कोड नहीं, बस इस रिलीज में नहीं जा रहा।

— डैनियल नलबाक

मैंने इस पर एक कठिन सबक सीखा। हमने अपनी सुविधा शाखा में एक सुविधा को आगे बढ़ाया लेकिन एहसास हुआ कि डेटा मुद्दे थे और सीधे विकास पर वापस आ गए। बाद में जब चीजें तय हो गईं, तो हम पुश करने से पहले इस सुविधा के साथ उनकी संगतता का परीक्षण करने के लिए इस शाखा में नए विकास की विशेषताओं को जोड़ना चाहते थे, इसलिए मैंने विकास को वापस शाखा में विलय कर दिया। इसने रिवर्जन कमिट को भी लागू किया, जिसने फीचर शाखा में किए गए हर बदलाव को खोल दिया। > <

— ग्रेग

Answer 2

अपने कमिट ग्राफ (gitk या इसी तरह के प्रोग्राम के साथ) को देखें। आप पुल अनुरोध से कमिट्स देखेंगे, और आप अपने स्वयं के कमिट्स देखेंगे, और मर्ज कमिट (यदि यह एक फास्ट-फॉरवर्ड मर्ज नहीं था)। आपको केवल मर्ज से पहले अपने खुद के आखिरी का पता लगाना होगा, और इस कमेटी को शाखा को रीसेट करना होगा।

(यदि आपके पास शाखा का स्थान है, तो मर्ज से पहले कमिटमेंट ढूंढना और भी आसान होना चाहिए।)

---

(टिप्पणियों में अधिक जानकारी के बाद संपादित करें :)

ठीक है, ग्राफ को देखने देता है:

मैं मानती हूं कि अंतिम (सबसे सही) कमिटमेंट आपके गलत मर्ज को पुल रिक्वेस्ट के द्वारा किया गया था , जो यहां दिखाई देने वाली नीली रेखा को मिला देता है। आपकी अंतिम अच्छी प्रतिबद्धता काली रेखा से पहले होगी, यहाँ लाल रंग में चिह्नित किया गया है:

इस कमिट पर रीसेट करें, और आपको ठीक होना चाहिए।

इसका मतलब है, आपकी स्थानीय कामकाजी कॉपी में ऐसा होता है (यह सुनिश्चित करने के बाद कि आपके पास कोई और अधिक सामान नहीं है, उदाहरण के लिए git stash द्वारा):

git checkout master
git reset --hard 7a62674ba3df0853c63539175197a16122a739ef
gitk 

अब इस बात की पुष्टि करें कि आप वास्तव में मेरे द्वारा चिन्हित किए गए वचन पर हैं, और आपको इसके पूर्वजों में से कोई भी सामान दिखाई नहीं देगा।

git push -f origin master

(यदि आपके गितुब रिमोट का नाम दिया गया है origin- तो नाम बदल दें)।

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

(एक ही काम करने का एक Github विशिष्ट वेब-ही तरीका हो सकता है, लेकिन मैं Github और इसके पुल प्रबंधन प्रणाली से बहुत परिचित नहीं हूं।)

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

यदि यह संभावना है कि ऐसा हुआ है, या आप किसी भी समस्या से बचना चाहते हैं, तो git revertआदेश का उपयोग करें git reset, एक नई प्रतिबद्धता के साथ परिवर्तनों को वापस करने के लिए, एक पुराने को वापस सेट करने के बजाय। (कुछ लोग सोचते हैं कि आपको प्रकाशित शाखाओं के साथ कभी भी रीसेट नहीं करना चाहिए।) इस प्रश्न के अन्य उत्तर देखें कि यह कैसे करना है।

भविष्य के लिए:

यदि आप रोजरपलाडिन की शाखा के कुछ कमिटमेंट चाहते हैं, तो cherry-pickइसके बजाय का उपयोग करने पर विचार करें merge। या उन्हें एक अलग शाखा में स्थानांतरित करने के लिए रोजरपलाडिन से संवाद करें और एक नया पुल अनुरोध भेजें।

Comments

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

— विल

हाँ, यह हर उस चीज़ में विलीन हो जाएगा जो विलय की गई प्रतिबद्धता का पूर्वज है (और पहले से ही आपकी प्रतिबद्धता का पूर्वज नहीं है)। इसे आपको रीसेट करने में बाधा नहीं डालनी चाहिए - यदि आपके द्वारा बाद में रिबास नहीं किया गया है, तो कमिट्स को स्वयं द्वारा पुन: व्यवस्थित नहीं किया जाएगा।

— पाओलो एबरमन

हाँ, अब यह सही लगता है ( अपने आप में अजीब मर्ज के अलावा - लेकिन यह नेटवर्क ग्राफ सॉफ़्टवेयर में एक गड़बड़ हो सकता है)। :-) मैं खुश हूं कि मैं मदद कर सका।

— पाओलो एबरमन

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

— मायल्स मैकडोनेल

@Will मैं इस जवाब को अस्वीकार करने का सुझाव दूंगा। यह उस कोड के लिए ठीक है जिसे अभी तक धक्का नहीं दिया गया है (किस मामले में, यह अधिक प्रासंगिक SO प्रश्न है, लेकिन कोड के लिए जिसे सार्वजनिक रूप से साझा किया गया है, एक git कमांड कर रहा है जो इतिहास को फिर से लिखता है (इस मामले में, reset --hardऔर एक बल धक्का है) बहुत बुरा अभ्यास)। नीचे दिए गए @errordeveloper के उत्तर को बिना किसी इतिहास के पुनर्लेखन या बल के धकेलने का एक तरीका दिखाया गया है।

— asmeurer

Answer 3

अगर वह आखिरी चीज थी, तो वह थी

git reset --hard HEAD~1

Comments

इस निर्देश का पालन करें, यह वास्तव में मुझे एक नहीं, बल्कि 2 कदम पीछे ले गया।

— २२

@ स्वेज़लीन ऐसा कैसे हो सकता है कि यह आपको 2 कदम पीछे ले जाए, एक नहीं? मुझे पता है कि यह टिप्पणी 4 साल पहले छोड़ी गई थी, लेकिन मैं उत्सुक हूं कि अगर किसी को एक उत्तर पता है कि यह कैसे हो सकता है। यह मेरे लिए बहुत महत्वपूर्ण है। धन्यवाद।

— हरदज़निएक

मुझे अब याद नहीं है, लेकिन मैं अनुमान लगा रहा हूं कि क्या ऐसा हो सकता है जब मैंने रीसेट करने की कोशिश की थी? यदि आप इसके बारे में चिंतित हैं तो मैं इसे एक डमी रेपो के साथ परीक्षण करूंगा।

— ६:१६ में सेज़िटलिन

इसने मेरे लिए अच्छा काम किया। इसने हाल ही में विलय किए गए अनुरोध को हटा दिया। के बाद git reset --hard HEAD~1, मैं git push origin -fदूरस्थ रिपॉजिटरी को अपडेट करता था। लेकिन सावधान रहें, ऐसा करने से पहले सावधानी बरतें।

— डेनिस ओलूका

Answer 4

जून 24 वें, 2014 से, आप ( "देखें आसानी से एक पीआर रद्द कोशिश कर सकते हैं एक पुल अनुरोध वापस लाया जा रहा ") के साथ:

पेश है रिवर्ट बटन

आप रिवर्ट पर क्लिक करके आसानी से GitHub पर पुल अनुरोध वापस ला सकते हैं:

आपको नए बदलावों के साथ एक नया पुल बनाने का संकेत दिया जाएगा:

इसका परीक्षण किया जाना बाकी है, भले ही वह वापस लौटे -mया नहीं (मर्ज को फिर से भरने के लिए)

लेकिन आदिल एच रज़ा टिप्पणियों में कहते हैं (दिसंबर 2019):

यह अपेक्षित व्यवहार है, इसने एक नई शाखा बनाई और आप इस नई शाखा से अपने लिए एक पीआर बना सकते हैं master।
भविष्य में इस तरह से आप जरूरत पड़ने पर वापस लौट सकते हैं, यह सबसे सुरक्षित विकल्प है और सीधे तौर पर आपके बदलने का नहीं master।

---

चेतावनी : कोरयम टिप्पणी में बताते हैं कि:

वापस जाने के बाद, मान लें कि आपने Git शाखा में कुछ और बदलाव किए और उसी स्रोत / गंतव्य शाखा से एक नया PR बनाया।
आपको पीआर केवल नए परिवर्तन दिखाएगा, लेकिन श्रद्धेय होने से पहले वहां कुछ भी नहीं था ।

कोरेम हमें संदर्भित करता है "गितुब :git cherry-pickgit rebase अधिक के लिए रिवर्ट ( , ) " के बाद नजरअंदाज किए गए परिवर्तन ।

Comments

मैंने यह कोशिश की और इसने मास्टर पर पीआर को पूर्ववत करने के बजाय एक नई शाखा बनाई?

— मंगलपाठ

अजीब। क्या आप उस व्यवहार का वर्णन करने के लिए एक नया प्रश्न पूछ सकते हैं?

— वॉनक

यह अपेक्षित व्यवहार है, इसने एक नई शाखा बनाई और आप इस नई शाखा से अपने स्वामी के लिए एक पीआर बना सकते हैं। भविष्य में इस तरह से आप जरूरत पड़ने पर वापस लौट सकते हैं, यह सबसे सुरक्षित विकल्प है और सीधे अपने मालिक को नहीं बदल सकता है।

— आदिल एच। रज़ा

@ आदिल.राजा धन्यवाद। अधिक दृश्यता के उत्तर में मैंने आपकी टिप्पणी को शामिल किया है।

— VONC

@VonC उँगलियाँ इसे पार कर दुनिया भर के डेवलपर्स को बहुत पीड़ा और समय की बर्बादी से

— बचाएगी

Answer 5

जीथुब पुल के अनुरोध को पूर्ववत करने के लिए कि आप हटाना नहीं चाहते हैं, आपको एक चलाना होगा:

git reset --hard --merge <commit hash>

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

इसे खोजने का एक अच्छा तरीका यह है कि अब बंद पुल अनुरोध पर जाएं और इस क्षेत्र को खोजें:

पुल अनुरोध छवि

आपके द्वारा चलाने के बाद git reset, एक चलाएं:

git push origin --force <branch name>

यह पुल अनुरोध से पहले वापस आ जाना चाहिए, पुल अनुरोध में प्रतिबद्धताओं के बीच प्रतिबद्ध इतिहास में peppered शाखा में किसी भी हिट को प्रभावित किए बिना।

संपादित करें:

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

Comments

किसी भी पागल श्रद्धा या चेरी लेने की आवश्यकता के बिना चीजों को सीधा करने का शानदार तरीका

— कमुलो निम्बस

धन्यवाद! यही मैं करने की योजना बना रहा था, लेकिन यह लगभग ~ 200 चेरी चेरी पिक आउट करने के लिए किया गया था।

— फुलसमुराई

Answer 6

मैं हर समय इस जगह का उपयोग करता हूं, धन्यवाद।

मैं खोज रहा था कि कैसे एक पुल अनुरोध को पूर्ववत् करें और यहां प्राप्त करें।

मैं बस git reset --hard"एक लंबे समय से पहले" के बारे में था और एक तेजी से आगे की ओर वापस कर दूं जहां मैं पुल अनुरोध करने से पहले था।

यहाँ देखने के अलावा, मैंने अपने सहकर्मी से यह भी पूछा कि वह क्या करेगा, और उसके पास आमतौर पर अच्छा जवाब था: ऊपर दिए गए पहले उत्तर में उदाहरण आउटपुट का उपयोग करना:

git reset --hard 9271e6e

Git में अधिकांश चीजों के साथ, यदि आप इसे कुछ इस तरह से कर रहे हैं जो आसान नहीं है, तो आप शायद इसे गलत कर रहे हैं।