एक विलय को वापस कैसे करें जो रणनीति = हमारा उपयोग करता है?

Question

मैं एक भंडार के साथ काम कर रहा हूं जहां एक मर्ज सप्ताह पहले किया गया था जिसे हमने अभी पाया है --strategy=ours ध्वज (इसे --strategategy-option = ours flag का उपयोग करना था), इस प्रकार हेड में कोई भी परिवर्तन लागू नहीं किया गया था। हालांकि, हमें बदलावों को लागू करने की आवश्यकता है। गिट पहले ही शाखा को विलय के रूप में मान्यता देता है और शाखा के इतिहास में काम करता है।

मर्ज इस तरह का उपयोग कर git revert -m ...

क्या पूर्ववत करने और/या पुनः आवेदन मर्ज फ़ाइलों को बदलने के लिए की उचित तरीका होगा वापस नहीं लाई जा सकती है?

master A - B - E - F - G ---> L - M - N 
      \ /
topic   C - D 

मर्ज प्रतिबद्ध (F) इस परिदृश्य में अपराधी होगा।

Answer 1

मुझे इस समस्या का हल पता चला है। यह सब पत्र में लिखा गया था कि लिनस ने दोषपूर्ण विलय को वापस करने के बारे में लिखा था: How to revert a faulty merge। हमारे मामले में git merge --strategy=ours topic का इरादा नहीं था। भले ही यह एक दोषपूर्ण विलय हो, फिर भी इसे वापस नहीं किया जा सकता है, और लंबे समय से धकेलने के बाद, रिवर्ट प्रतिबद्धता को वापस करने में सक्षम होने के बिना एक विलय विलय प्रतिबद्ध होने का एक ही प्रभाव पड़ता है।

समाधान पहली शाखा से rebase --no-ff चलाने के लिए विषय शाखा को चेकआउट करना था और फिर उस शाखा को मास्टर में वापस विलय करना था।

fixed–topic C'–––D'––––––––––––––––––––- 
      /       \ 
master A–––B–––E–––F–––G –––> L–––M–––N–––F2 
      \ /
topic   C–––D 

वास्तव में गहराई से यह समझने के लिए, --no-ff रिबेस विकल्प का उपयोग शाखा फिर से बनाने के लिए पत्र How to Revert a Faulty Merge का अंतिम भाग पढ़ें:

git checkout topic 
git rebase -i --no-ff <C> 
git checkout master 
git merge topic 

यह उपज का प्रभाव नहीं पड़ा।

Answer 2

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

अद्यतन:

आपके मामले में, अगर आप अतीत के बारे में परवाह नहीं है, तो आप जी एन ई पर rebase कर सकते हैं और फिर बस इस नए मास्टर पर डी मर्ज करें। रिबाज छोटा होगा क्योंकि एफ एक मर्ज था।

Answer 3

@ हाइवे ऑफ लाइफ का एक बड़ा जवाब है। एक बात यह है कि पुनर्जन्मित काम अब नए अलग-अलग कामों की तरह दिखता है, जो कई मामलों में अवांछित हो सकता है। मैं दूसरी बार समान काम करना चाहता था, लेकिन git-merge इसे रोकता है। हालांकि, मुझे बार-बार लगता है कि आप जो चाहते हैं उसे करने के लिए गिट प्राप्त करना हमेशा संभव होता है।

1. जीवन के निर्देशों का पालन करें राजमार्ग लेकिन गुरु पर सीधे विलय नहीं है:

   re-merged    ––––––––––––––––––––------R 
           /      /
   fixed–topic  C'–––D'      /
          /       /
   master  A–––B–––E–––F–––G –––> L–––M–––N–––F2 
          \ /
   topic   C–––D 
   

2. अब पेड़ की स्थापना की है वास्तव में कैसे आप चाहते हैं:

   git checkout -b fixed-topic <D> 
   git rebase -i --no-ff <B> 
   git checkout -b re-merged master 
   git merge fixed-topic 
   

   इस में जो परिणाम - फाइलें वास्तव में आपकी इच्छित सामग्री दिखाती हैं। एक समस्या यह है कि वास्तव में मूल होने के बजाय, आपके विलय प्रतिबद्धता के माता-पिता आपके मूल प्रतिबद्धताओं की प्रतियां प्रतियां हैं।यह git-reparent साथ इसे ठीक करना आसान है:

   master  A–––B–––E–––F–––G –––> L–––M–––N–––F2 
          \ /      \ 
   topic   C–––D       \ 
            \       \ 
   re-merged    ---------------------------R 
   

   नोट करने के लिए एक महत्वपूर्ण बात यह है कि आर की सामग्री को अंतिम चरण-केवल माता-पिता के बाद से नहीं बदला है:

   git reparent -p master -p <D> 
   

   इस के साथ समाप्त होता है ।

3. नए मर्ज करने के लिए तेजी से आगे मास्टर के लिए प्रतिबद्ध:

   git checkout master 
   git merge re-merged 
   

4. अंत में आप

   git branch -d fixed-topic re-master 
   

हो गया साथ साफ कर सकते हैं! अपने इतिहास, इस तरह दिखता है एक शाखा के साथ दो बार विलय कर दिया:

master A–––B–––E–––F–––G –––> L–––M–––N–––F2---R 
      \ /      /
topic   C–––D----------------------------