कमांड लाइन पर और थ्री-वे एडिटर में गिट मर्ज संघर्षों को कैसे हल करें

Git में मर्ज विवादों को हल करने के लिए, प्रत्येक फ़ाइल को खोलें Git विवादित के रूप में रिपोर्ट करता है, तय करें कि <<<<<<<, ======= और >>>>>>> मार्करों के बीच कोड क्या होना चाहिए, मार्कर हटाएं, फ़ाइल को git add के साथ चरणबद्ध करें, और git commit (या git merge --continue) के साथ समाप्त करें। इसके बजाय पीछे हटने के लिए, git merge --abort चलाएँ। यह मार्गदर्शिका कमांड लाइन पर उस लूप के माध्यम से चलती है, फिर विज़ुअल थ्री-वे एडिटर में, और उन आदतों के साथ समाप्त होती है जो संघर्षों को दुर्लभ और पूर्ववत करना आसान बनाती हैं। रुके हुए मर्ज, रीबेस या चेरी-पिक द्वारा दिए गए विकल्पों का अभ्यास करने के लिए, निःशुल्क पाठ लें किसी सक्रिय ऑपरेशन को जारी रखें, छोड़ें या निरस्त करें।

विज़ुअल उदाहरण GitTree का उपयोग करते हैं, Git क्लाइंट जिसे हम macOS, Windows और Linux के लिए बनाते हैं। यह आपके कंप्यूटर पर इंस्टॉल किए गए Git को चलाता है, इसलिए क्लिक करने और टाइप करने से एक ही परिणाम मिलता है; GitTree फीचर सूची में व्यापक तस्वीर है।

वास्तव में Git में मर्ज विरोध क्या है

Git प्रत्येक फ़ाइल के तीन संस्करणों का उपयोग करके पंक्ति दर पंक्ति विलय करता है: आधार (अंतिम प्रतिबद्धता दोनों शाखाएँ साझा करती हैं), हमारी (आपकी वर्तमान शाखा, HEAD) और उनकी (आने वाली शाखा, MERGE_HEAD)। यदि किसी क्षेत्र में केवल एक पक्ष ने परिवर्तन किया है, तो Git उस परिवर्तन को ले लेता है। यदि दोनों पक्षों ने समान पंक्तियों को अलग-अलग बदल दिया है, तो Git रुक जाता है, दोनों संस्करणों को फ़ाइल में लिखता है और निर्णय आप पर छोड़ देता है।

यही बात git pull, git rebase, git cherry-pick, git revert और git stash pop में भी हो सकती है। फिक्स समान है; केवल अंतिम आदेश भिन्न है। git status प्रत्येक विवादित पथ को लेबल करता है:

• दोनों संशोधित: दोनों शाखाओं ने समान पंक्तियाँ बदल दीं। यह सामान्य मामला है.
• हमारे द्वारा हटा दिया गया / उनके द्वारा हटा दिया गया: एक पक्ष ने फ़ाइल को हटा दिया और दूसरे ने इसे बदल दिया, इसलिए आप बदली हुई फ़ाइल को रखें या हटाए जाने की पुष्टि करें।
• दोनों जोड़े गए: प्रत्येक शाखा ने एक ही पथ पर एक अलग फ़ाइल बनाई।

कमांड लाइन पर मर्ज विवादों को कैसे ठीक करें

1. विवादित फ़ाइलें ढूँढ़ें

मर्ज रुकते ही Git विवादों को सूचीबद्ध करता है, और git status आपके समाप्त होने तक सूची को बनाए रखता है। git diff --name-only --diff-filter=U केवल असंबद्ध पथों को प्रिंट करता है।

$ git merge feature/login
Auto-merging src/auth.ts
CONFLICT (content): Merge conflict in src/auth.ts
Automatic merge failed; fix conflicts and then commit the result.

$ git status
On branch main
You have unmerged paths.

Unmerged paths:
  (use "git add <file>..." to mark resolution)
        both modified:   src/auth.ts

2. संघर्ष मार्कर पढ़ें

मार्करों के बाहर सब कुछ साफ़-साफ़ विलीन हो गया। <<<<<<< HEAD के बाद वाला ब्लॉक आपकी वर्तमान शाखा है, >>>>>>> feature/login से पहले वाला ब्लॉक आने वाला है, और ======= लाइन उन्हें अलग करती है।

export const retries = 3;
<<<<<<< HEAD
export const timeout = 45;
=======
export const timeout = 60;
>>>>>>> feature/login
export const debug = false;

निर्णय लेने के लिए अक्सर दो संस्करण पर्याप्त नहीं होते हैं। Git की zdiff3 द्वंद्व शैली को एक बार सेट करें, और प्रत्येक द्वंद्व एक ||||||| पंक्ति के बाद आधार भी दिखाता है:

$ git config --global merge.conflictStyle zdiff3

<<<<<<< HEAD
export const timeout = 45;
||||||| 556e564
export const timeout = 30;
=======
export const timeout = 60;
>>>>>>> feature/login

अब आप देख सकते हैं कि मुख्य ने टाइमआउट को 30 से बढ़ाकर 45 और फीचर शाखा ने 60 तक बढ़ा दिया है: यह तय करें कि उत्पाद को किस मूल्य की आवश्यकता है, न कि कौन सी शाखा जीतती है।

3. फ़ाइल को संपादित करें और इसे हल हो गया चिह्नित करें

Write the code you want (one side, the other, a mix or something new) and delete every marker line. Let Git check for leftovers before you stage, because a stray ======= committed by accident is a classic broken build.

$ git diff --check          # lists any leftover conflict markers
$ git add src/auth.ts
$ git commit                # or: git merge --continue

यदि पूरी फ़ाइल का एक तरफ का संस्करण सही है, तो उसे सीधे ले लें। विलय के दौरान Git को प्रत्येक परस्पर विरोधी गुट के लिए एक पक्ष को प्राथमिकता देने के लिए, इसके बजाय git merge -X ours या git merge -X theirs से विलय शुरू करें; जो परिवर्तन संघर्ष नहीं करते वे अभी भी दोनों शाखाओं से आते हैं।

$ git checkout --ours -- src/auth.ts     # keep the current branch's version
$ git checkout --theirs -- src/auth.ts   # keep the incoming version
$ git add src/auth.ts

4. ऑपरेशन समाप्त करें

जब प्रत्येक फ़ाइल चरणबद्ध हो जाए, तो जो भी रुका है उसे जारी रखें: git commit (या git merge --continue), git rebase --continue, git cherry-pick --continue या git revert --continue। एक रिबेस बाद की प्रतिबद्धता पर फिर से रुक सकता है; लूप दोहराएँ.

GUI में मर्ज विवादों का समाधान करें: एक तीन-तरफा Git संघर्ष समाधानकर्ता

दो-पंक्ति टकराव के लिए मार्कर ठीक हैं। एक लंबी फ़ाइल में एक दर्जन संघर्षों के साथ, एक GUI संघर्ष समाधानकर्ता तेज़ है और ग़लती निकालना बहुत कठिन है। एक अच्छा Git मर्ज विरोध उपकरण सभी तीन संस्करणों को एक साथ दिखाता है, आपको संघर्ष दर संघर्ष तय करने देता है और मार्कर बने रहने पर सहेजने से इंकार कर देता है।

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

• प्रति संघर्ष: वर्तमान पक्ष, आने वाला पक्ष, दोनों या न ही लें, या प्रत्येक से एकल पंक्तियाँ चुनें।
• आउटपुट संपादित करें किसी भी चीज़ के लिए हाथ से जिसे बटन कवर नहीं करते।
• सामान्य पूर्वज को देखने के लिए आधार दिखाएं (Git इसे तब लिखता है जब merge.conflictStyle diff3 या zdiff3 होता है)।
• अपने निर्णयों से पीछे हटने के लिए विकल्प पूर्ववत करें।
• हटाई गई फ़ाइलें: जब एक पक्ष ने एक फ़ाइल को हटा दिया तो दूसरे ने उसे बदल दिया, उस पक्ष की फ़ाइल को रखें या हटाए जाने की पुष्टि करें।

GitTree ऐसे परिणाम को सहेज नहीं पाएगा जिसमें अभी भी मार्कर रेखाएं हों। यह आपके बाहरी मर्ज टूल में भी फ़ाइल खोल सकता है: वीएस कोड, कर्सर, जेटब्रेन आईडीई, बियॉन्ड कंपेयर, मेल्ड, केडिफ़3, पी4मर्ज, विनमर्ज, एक कस्टम प्रोग्राम, या गिट का अपना merge.tool। यदि उपकरण फ़ाइल का समाधान किए बिना बंद हो जाता है, तो फ़ाइल विवादित बनी रहती है।

मर्ज करने से पहले मर्ज विवादों की भविष्यवाणी करें

Git 2.38 के बाद से, git merge-tree --write-tree आपके वर्किंग ट्री या इंडेक्स को पढ़े या लिखे बिना, और कोई कमिट किए बिना मेमोरी में मर्ज करता है। --name-only के साथ यह उन फ़ाइलों को सूचीबद्ध करता है जिनका विरोध हो सकता है; जब विरोध होता है तो निकास स्थिति 1 होती है और जब मर्ज साफ़ होता है तो 0 होता है।

$ git fetch
$ git merge-tree --write-tree --name-only HEAD origin/main
0d708adc4a836d088802870278cb1f3daf06355f
src/auth.ts

Auto-merging src/auth.ts
CONFLICT (content): Merge conflict in src/auth.ts

GitTree आपके लिए यह पूर्वावलोकन चलाता है: मर्ज संवाद आपके पुष्टि करने से पहले अनुमानित परिणाम दिखाता है। प्रत्येक फ़ेच के बाद, यह आपकी शाखा को उसके अपस्ट्रीम और आधार शाखा (मुख्य या मास्टर, जब तक कि आप कोई अन्य सेट नहीं करते हैं) के विरुद्ध जाँचता है और शाखा नाम के बगल में एक चेतावनी दिखाता है, जैसे "2 फ़ाइलों में मुख्य के साथ विरोध होगा"। दूसरा संकेत उन फ़ाइलों को चिह्नित करता है जिन्हें आप बदल रहे हैं कि अन्य प्राप्त, असंबद्ध शाखाएँ भी बदल जाती हैं।

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

Git rerere के साथ संघर्ष समाधानों का पुन: उपयोग करें

रेरेरे का अर्थ है "रिकॉर्ड किए गए रिज़ॉल्यूशन का पुन: उपयोग करें"। इसके साथ, Git प्रत्येक संघर्ष को रिकॉर्ड करता है और आपने इसे कैसे हल किया। जब समान संघर्ष वापस आता है, जैसे लंबे समय से मौजूद शाखा के बार-बार रिबेस पर या आपके द्वारा फिर से किए गए मर्ज पर, तो Git आपके पिछले रिज़ॉल्यूशन को फ़ाइल में लिखता है।

$ git config --global rerere.enabled true
$ git rerere forget src/auth.ts   # drop a recorded resolution that was wrong

Git पुन: उपयोग किए गए परिणाम को समीक्षा के लिए तब तक बिना रुके छोड़ देता है जब तक कि rerere.autoUpdate सेट न हो जाए। GitTree में, रिपॉजिटरी सेटिंग्स में उन Git विकल्पों के लिए रिकॉर्ड किए गए रिज़ॉल्यूशन का पुन: उपयोग (rerere) और स्टेज पुन: उपयोग किए गए रिज़ॉल्यूशन स्विच हैं; विरोध दृश्य एक पुन: उपयोग किए गए रिज़ॉल्यूशन को लेबल करता है, और रिज़ॉल्यूशन भूल जाओ एक गलत को हटा देता है।

Git में मर्ज को कैसे निरस्त करें या रद्द करें

किसी ऐसे मर्ज को रद्द करने के लिए जो विरोधों पर रुका हो, git merge --abort चलाएँ। रिबेस, चेरी-पिक या रिवर्ट का अपना गर्भपात होता है:

$ git merge --abort
$ git rebase --abort
$ git cherry-pick --abort
$ git revert --abort

Git के स्वयं के दस्तावेज़ में चेतावनी दी गई है कि मर्ज शुरू होने पर आपके द्वारा किए गए अप्रतिबद्ध परिवर्तनों को git merge --abort हमेशा दोबारा नहीं बनाया जा सकता है। विलय करने से पहले कमिट करें या छिपाएँ, और निरस्त करने से केवल पुनर्स्थापित करने का कार्य प्रतिबद्ध होता है।

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

किसी मर्ज को करने के बाद उसे कैसे पूर्ववत करें

क्या करना है यह इस पर निर्भर करता है कि आपने मर्ज को आगे बढ़ाया है या नहीं:

# Not pushed yet, right after the merge:
$ git reset --hard ORIG_HEAD     # also discards uncommitted changes
$ git reset --merge ORIG_HEAD    # keeps uncommitted changes

# Already pushed:
$ git revert -m 1 <merge-commit> # a new commit that reverses it

मर्ज आपकी शाखा की पिछली टिप को ORIG_HEAD में सहेजता है, इसलिए इसे रीसेट करने से मर्ज हट जाता है, जब तक कि बाद में रीसेट या रीबेस को ORIG_HEAD में स्थानांतरित नहीं किया जाता है। एक बार जब दूसरों का विलय हो जाए, तो इसके बजाय वापस लौटें। मर्ज को पूर्ववत करना Git को बताता है कि आप कभी भी उन परिवर्तनों को नहीं चाहते हैं: उस शाखा को दोबारा विलय करने से वे तब तक वापस नहीं आएंगे जब तक कि आप पूर्ववत न करें।

GitTree में, ग्राफ़ में मर्ज के पहले पैरेंट (आपकी शाखा पहले जिस कमिट पर थी) का चयन करें और कमिट मेनू से इसके लिए एक सॉफ्ट, मिश्रित या हार्ड रीसेट चुनें, प्रत्येक को जो वह रखता है उसके साथ लेबल किया गया है। GitTree चलने से पहले 19 प्रकार के ऑपरेशन के स्नैपशॉट, रीसेट शामिल हैं, इसलिए पूर्ववत रीसेट को उलट सकता है, और रीफ्लॉग दृश्य पुरानी स्थितियों को पुनर्प्राप्त करता है। रीसेट, रीबेस या कमिट को पूर्ववत करने की मार्गदर्शिका गहराई से पुनर्प्राप्ति को कवर करती है।

अधिकांश मर्ज विवादों को कैसे रोकें

• शाखाओं को छोटा और अल्पकालिक रखें। जितनी लंबी दो शाखाएँ अलग-अलग होंगी, उतनी ही अधिक रेखाएँ वे दोनों स्पर्श करेंगी।
• आधार शाखा को बार-बार लाएँ, अंत में एक बार नहीं।
• फ़ॉर्मेटिंग को तर्क से अलग करें। एक फ़ॉर्मेटर पर सहमत हों और संपूर्ण-फ़ाइल सुधार को अपने आप पूरा करें।
• लॉकफ़ाइलों को हाथ से मर्ज करने के बजाय उन्हें पुन: उत्पन्न करें। किसी भी तरफ ले जाएं, फिर अपने पैकेज मैनेजर को दोबारा चलाएं।
• zdiff3 चालू करें और एक बार पुनः प्राप्त करें। दो आदेश, स्थायी लाभ।
• एकीकृत करने से पहले प्रतिबद्ध करें या छिपाएँ, इसलिए हर निरस्त और पूर्ववत सटीक है।

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

GitTree के पास एक नि:शुल्क योजना है जो प्रत्येक Git सुविधा को कवर करती है, जिसमें निजी रिपॉजिटरी भी शामिल है, और Nour, AI सहायक, GitTree प्रो के साथ आता है (देखें मूल्य निर्धारण); इसे साइन इन करने के लिए Git 2.39 या नए और GitTree खाते की आवश्यकता है। इसे macOS, Windows या Linux के लिए प्राप्त करें, या GitTree डाउनलोड पृष्ठ पर प्रत्येक इंस्टॉलर को देखें। Ubuntu 22.04 पर, पहले Git को अपग्रेड करें। एक जिद्दी संघर्ष में फंस गए? मांगें GitTree समर्थन.