जीआईटी मर्ज कमिटमेंट रिबासिंग

183

निम्नलिखित मामले को लें:

मेरे पास विषय शाखा में कुछ काम है और अब मैं वापस मास्टर में विलय करने के लिए तैयार हूं:

* eb3b733 3     [master] [origin/master]
| * b62cae6 2   [topic]
|/  
* 38abeae 1

मैं मास्टर से मर्ज करता हूं, संघर्षों को हल करता हूं और अब मेरे पास है:

*   8101fe3 Merge branch 'topic'  [master]
|\  
| * b62cae6 2                     [topic]
* | eb3b733 3                     [origin/master]
|/  
* 38abeae 1

अब, मर्ज में मुझे कुछ समय लगा, इसलिए मैं एक और खोज करता हूं और ध्यान देता हूं कि दूरस्थ मास्टर शाखा में नए परिवर्तन हैं:

*   8101fe3 Merge branch 'topic'  [master]
|\  
| * b62cae6 2                     [topic]
| | * e7affba 4                   [origin/master]
| |/  
|/|   
* | eb3b733 3
|/  
* 38abeae 1

यदि मैं गुरु से 'गित प्रतिशोध मूल / गुरु' की कोशिश करता हूं, तो मुझे फिर से सभी संघर्षों को हल करने के लिए मजबूर किया जाता है, और मैं विलय की प्रतिबद्धता भी खो देता हूं:

* d4de423 2       [master]
* e7affba 4       [origin/master]
* eb3b733 3
| * b62cae6 2     [topic]
|/  
* 38abeae 1

क्या मर्ज कमिट को रिबेट करने का एक साफ तरीका है, इसलिए मैं एक इतिहास के साथ समाप्त होता हूं जैसे कि मैं नीचे दिखा रहा हूं?

*   51984c7 Merge branch 'topic'  [master]
|\  
| * b62cae6 2                     [topic]
* | e7affba 4                     [origin/master]
* | eb3b733 3
|/  
* 38abeae 1

— jipumarino
स्रोत

74

टीएल; डीआर:git rebase --preserve-merges origin/master

— इलिया के।

6

संघर्षों को फिर से हल करने के संबंध में, आप गिट रीरे पर एक नज़र रखना चाहते हैं ।

— पार्कर ने

git config --global pull.rebase preserve हमेशा छूट को संरक्षित करने के लिए एक छूट के दौरान

— galath

4

चेतावनी: Git 2.18 (Q2 2018, 5 साल बाद) के साथ शुरू, git --rebase-mergesअंततः पुराने को बदल देगा git --preserve-merges। देखें क्या वास्तव में Git का " rebase --preserve-merges" (और क्यों?) है

— VonC

1

--preserve-mergesपदावनत किया गया है। उपयोगgit rebase --rebase-merges origin/master

— अर्जुन श्रीधरन

127

यहां दो विकल्प हैं।

एक इंटरएक्टिव रिबेस करना है और मर्ज कमिट को एडिट करना है, मर्ज को मैन्युअल रूप से रिडोज़ करें और रिबेस को जारी रखें।

एक अन्य --rebase-mergesविकल्प का उपयोग करना है git rebase, जिसे मैनुअल से निम्नानुसार वर्णित किया गया है: "डिफ़ॉल्ट रूप से, एक रिबेस बस टूडू सूची से मर्ज के कमिट्स को छोड़ देगा, और रिबूट किए गए कमिट्स को एकल, रैखिक शाखा में डाल देगा। --rebase के साथ। मर्ज, रिबेज बजाय मर्ज किए गए कमिट्स को फिर से क्रिएट करने के लिए ब्रांचिंग संरचना को संरक्षित करने की कोशिश करेगा, मर्ज कमिट्स को फिर से जोड़कर। इन मर्ज कमिट्स में किसी भी मर्ज किए गए मर्ज टकराव या मैन्युअल संशोधनों को मैन्युअल रूप से हल / पुनः लागू करना होगा। "

— siride
स्रोत

16

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

— जिपुमारिनो

2

@jipumarino: git rebase -i (इसे मर्ज कमिट को संपादित करने के लिए बताएं), जब यह मर्ज कमिट के लिए हो जाता है, तो git रीसेट --hard HEAD ^, git मर्ज, फिक्स कॉन्फ्लिक्ट्स, git कमिट, git रीबेज - कॉन्टिन्यू। आप git rerere को भी देखना चाहेंगे, जो इस तरह की चीज़ के साथ मदद करने वाला है (लेकिन मैंने कभी इस्तेमाल नहीं किया है, इसलिए मैं कोई सलाह या मदद नहीं दे सकता)।

— प्रात:

2

धन्यवाद। मैंने रीरे को सक्षम किया और रिबेस-पी के साथ प्रयास किया और यह उसी तरह काम कर रहा है जैसे इसे करना चाहिए।

— 1848 में जिपुमारिनो

3

यहाँ इस सटीक स्थिति का वर्णन करने वाला एक उत्कृष्ट ब्लॉग पोस्ट है: Git में

— रीबासिंग

1

rere समाधान नहीं है, क्योंकि आपको अभी भी पहली बार मैन्युअल रूप से मर्ज को हल करना है।

— फ्लिम्स

29

ठीक है, यह एक पुराना सवाल है और इसने पहले ही इसका जवाब स्वीकार कर लिया है @siride, लेकिन यह जवाब मेरे मामले में पर्याप्त नहीं था, क्योंकि --preserve-mergesआप दूसरी बार सभी संघर्षों को हल करने के लिए मजबूर करते हैं। मेरे विचार पर @Tobi Bसटीक कदम-दर-चरण कमांड के आधार पर समाधान

तो हम प्रश्न में उदाहरण के आधार पर ऐसी स्थिति की शुरुआत करेंगे:

*   8101fe3 Merge branch 'topic'  [HEAD -> master]
|\  
| * b62cae6 2                     [topic]
| |
| | * f5a7ca8 5                   [origin/master]
| | * e7affba 4
| |/  
|/|   
* | eb3b733 3
|/  
* 38abeae 1

ध्यान दें कि हमारे पास 2 आगे मास्टर हैं, इसलिए चेरी-पिक काम नहीं करेगा।

सबसे पहले, चलिए सही इतिहास बनाते हैं जो हम चाहते हैं:
```
git checkout -b correct-history # create new branch to save master for future
git rebase --strategy=ours --preserve-merges origin/master
```
हम --preserve-mergesइतिहास में अपनी मर्ज कमेटी को बचाने के लिए उपयोग करते हैं । हम प्रयोग करते हैं--strategy=ours सभी मर्ज संघर्षों को अनदेखा लिए करते हैं क्योंकि हम इस बात पर ध्यान नहीं देते हैं कि उस मर्ज कमिट में क्या सामग्री होगी, हमें अब केवल अच्छे इतिहास की आवश्यकता है।

इतिहास ऐसा लगेगा (गुरु को अनदेखा करना):
```
*   51984c7 Merge branch 'topic'  [HEAD -> correct-history]
|\  
| * b62cae6 2                     [topic]
* | f5a7ca8 5                     [origin/master]
* | e7affba 4
* | eb3b733 3
|/  
* 38abeae 1
```
चलिए अब सही इंडेक्स मिलता है।
```
git checkout master # return to our master branch
git merge origin/master # merge origin/master on top of our master
```
हमें यहां कुछ अतिरिक्त मर्ज टकराव हो सकते हैं, लेकिन यह केवल उन फ़ाइलों से टकराव होगा जो 8101fe3और के बीच बदल गए हैंf5a7ca8 , लेकिन पहले से हल किए गए संघर्ष शामिल नहीं हैंtopic

इतिहास इस तरह दिखेगा (सही इतिहास की अनदेखी):
```
*   94f1484 Merge branch 'origin/master'  [HEAD -> master]
|\  
* | f5a7ca8 5                   [origin/master]
* | e7affba 4
| *   8101fe3 Merge branch 'topic'
| |\  
| | * b62cae6 2                     [topic]
|/ /
* / eb3b733 3
|/  
* 38abeae 1
```
अंतिम चरण हमारी शाखा को सही इतिहास और सही सूचकांक के साथ शाखा के साथ जोड़ना है
```
git reset --soft correct-history
git commit --amend
```
हम प्रयोग करते हैं reset --soft इतिहास को सही करने के लिए अपनी शाखा (और इतिहास) को रीसेट लिए , लेकिन इंडेक्स और वर्किंग ट्री को छोड़ दें। फिर हम commit --amendअपनी मर्ज कमिट को फिर से लिखने के लिए उपयोग करते हैं, जो कि मास्टर से हमारे अच्छे इंडेक्स के साथ गलत इंडेक्स हुआ करता था।

अंत में हमारे पास ऐसी स्थिति होगी (नोट करें)
```
*   13e6d03 Merge branch 'topic'  [HEAD -> master]
|\  
| * b62cae6 2                     [topic]
* | f5a7ca8 5                     [origin/master]
* | e7affba 4
* | eb3b733 3
|/  
* 38abeae 1
```

— इवान नायडोनोव
स्रोत

यह कमाल है और इससे काफी मदद मिली है! लेकिन मुझे कमिटमेंट के साथ ट्रिक नहीं मिली: क्या आप उस पर और जानकारी जोड़ सकते हैं? आपके द्वारा इसे चलाने के बाद वास्तव में क्या होता है - मैंने देखा कि प्रतिबद्ध का SHA बदल गया है - लेकिन क्यों? या अगर आप इसे नहीं चलाते हैं तो क्या होगा?

— ZenJ

1

@ZenJ git commit --amendअंतिम प्रतिबद्ध में परिवर्तन जोड़ता है (HEAD, इस मामले में मर्ज कमिट)। क्योंकि सामग्री में परिवर्तन होता है, हैश अपडेट किया जाता है।

— स्ट्रेल्सन

1

उन लोगों के लिए जो संघर्षों को ठीक करने से पहले 'रीरेयर' सक्षम नहीं हैं, यह समाधान बहुत अच्छा है क्योंकि यह आपको फिर से संघर्षों को ठीक करने से बचाता है। धन्यवाद!

— शेकलफोर्ड

6

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

हमारे पास एक बड़ा कोड बेस है और हमें एक ही समय में 2 शाखा के साथ भारी संशोधन करना होगा। यदि आप हैं तो एक मुख्य शाखा और एक द्वितीयक शाखा है।

जब मैं माध्यमिक शाखा को मुख्य शाखा में विलय कर देता हूं, तो मुख्य शाखा में काम जारी रहता है और जब तक मैं काम नहीं करता, तब तक मैं अपने बदलावों को आगे नहीं बढ़ा सकता क्योंकि वे असंगत हैं।

इसलिए मुझे अपने "मर्ज" को "रिबेस" करने की आवश्यकता है।

इस तरह हमने आखिरकार यह किया:

1) SHA पर ध्यान दें। उदा .: c4a924d458ea0629c0d694f1b9e9576a3ec35050bb

git log -1

2) उचित इतिहास बनाएं लेकिन इससे मर्ज टूट जाएगा।

git rebase -s ours --preserve-merges origin/master

3) SHA पर ध्यान दें। उदा .: 29dd8101d78

git log -1

4) अब पहले जहां आप थे, वहां रीसेट करें

git reset c4a924d458ea0629c0d694f1b9e9576a3ecf506b --hard

5) अब वर्तमान मास्टर को अपनी कार्य शाखा में मर्ज करें

git merge origin/master
git mergetool
git commit -m"correct files

6) अब जब आपके पास सही फाइलें हैं, लेकिन गलत इतिहास है, तो अपने परिवर्तन के साथ सही इतिहास प्राप्त करें:

git reset 29dd8101d78 --soft

7) और फिर - परिणाम को अपने मूल मर्ज कमिट में भेजें

git commit --amend

देखा!

— क्लाउड पेलेक्विन
स्रोत

1

ऐसा लगता है कि आप जो करना चाहते हैं, वह आपका पहला मर्ज हटा देगा। आप निम्नलिखित प्रक्रिया का पालन कर सकते हैं:

git checkout master      # Let's make sure we are on master branch
git reset --hard master~ # Let's get back to master before the merge
git pull                 # or git merge remote/master
git merge topic

जो आप चाहते हैं वह आपको देगा।

— एंटोनी पेलिस
स्रोत

4

रीरेयर सक्षम होने के साथ, यह वही परिणाम देता है जो ऊपर दिए गए रिबेस-पी समाधान के रूप में दिया जाता है।

— ५२ पर जिपुमारिनो

0

अपने मर्ज कमिटमेंट से
नया बदलाव चुनिए जो आसान होना चाहिए
अपना सामान कॉपी करें
विलय को फिर से करें और अपनी स्थानीय कॉपी से फ़ाइलों को कॉपी करके संघर्ष को हल करें;)

— तोबी बी
स्रोत

1

यह उत्तर अच्छा लग रहा है, लेकिन यदि आप एक उपयोगकर्ता को गिट के लिए नया है, तो आप वास्तविक git कमांड देते हैं और अधिक उपयोगी होगा

— लुईस डेविस