जब Git दो शाखाओं (branches) को स्वचालित रूप से संयोजित नहीं कर पाता है, तो यह रुक जाता है और परस्पर विरोधी परिवर्तनों को आपके समाधान के लिए छोड़ देता है। Mac पर, प्रभावित फ़ाइलों को खोजने के लिए git status का उपयोग करें, दोनों संस्करणों की तुलना करें, प्रत्येक विवाद को एक सुविचारित संयुक्त परिणाम में संपादित करें, फिर स्टेज करें और मर्ज को पूरा करें। मुख्य बात दोनों परिवर्तनों के मूल उद्देश्य को बनाए रखना है, न कि आँख मूंदकर किसी एक पक्ष को स्वीकार करना या यह मान लेना कि दोनों ब्लॉकों को रखने से काम करने योग्य कोड तैयार हो जाएगा।

कार्रवाई की पुष्टि करें और अधूरे संपादनों को सुरक्षित रखें

टर्मिनल या अपने एडिटर का एकीकृत टर्मिनल खोलें, रिपॉजिटरी में जाएं, और इसकी स्थिति की जाँच करें:

cd "/path/to/repository"
git status

उदाहरण के स्थान पर वास्तविक फ़ोल्डर पथ का उपयोग करें। Git का स्टेटस आपको बताता है कि कौन सी फ़ाइलें अनमर्ज्ड (unmerged) हैं और क्या कार्रवाई मर्ज, रीबेस या कोई अन्य कार्य है। यह लेख मर्ज को कवर करता है। एक सामान्य मर्ज के लिए, जब Git आपके विवादों को हल करने की प्रतीक्षा कर रहा होता है, तो वह वर्तमान शाखा को यथावत छोड़ देता है; जो पथ बिना किसी समस्या के मर्ज हो गए हैं वे पहले से ही अपडेट हो चुके होते हैं, जबकि विवादित पथों की समीक्षा की आवश्यकता होती है। Git का git merge दस्तावेज़

यदि आपके पास मर्ज से पहले का कोई ऐसा काम है जो कमिट नहीं किया गया है, तो संपादन करते समय ध्यान रखें कि वह ओवरराइट न हो जाए। Git एक मर्ज को रोकने के तरीके के रूप में git merge --abort का दस्तावेजीकरण करता है, लेकिन यह भी नोट करता है कि यह हमेशा पहले से मौजूद अनकमिटेड परिवर्तनों को पुनर्निर्मित नहीं कर सकता है। यदि स्थिति अस्पष्ट है, तो जारी रखने से पहले महत्वपूर्ण स्थानीय संपादनों की एक अलग प्रतिलिपि सहेजें। केवल तभी निरस्त (abort) करें जब आपका इरादा मर्ज को रोकने का हो, और उसके बाद परिणामी स्थिति की जाँच करें। Git के मर्ज विवाद निर्देश

प्रत्येक विवाद को दो प्रस्तावों के रूप में पढ़ें

प्रत्येक सूचीबद्ध फ़ाइल को एक टेक्स्ट एडिटर में खोलें। एक टेक्स्ट विवाद आमतौर पर इस प्रकार चिह्नित होता है:

<<<<<<< HEAD
current branch version
=======
incoming branch version
>>>>>>> branch-name

======= के ऊपर का टेक्स्ट आम तौर पर वर्तमान शाखा का संस्करण होता है; इसके नीचे का टेक्स्ट आम तौर पर वह शाखा होती है जिसे मर्ज किया जा रहा है। लेबल भिन्न हो सकते हैं। Git इंडेक्स में सामान्य पूर्वज (common ancestor) और दोनों शाखाओं के संस्करणों को रिकॉर्ड करता है, और वर्किंग फ़ाइल आपके संपादन के लिए विवाद-चिह्नित परिणाम दिखाती है। Git का मर्ज दस्तावेज़

दोनों अनुभागों को अभीष्ट परिवर्तनों के साक्ष्य के रूप में देखें, न कि ऐसे विकल्पों के रूप में जिन्हें आपको पूरी तरह से स्वीकार करना ही है। पूछें कि प्रत्येक संपादन क्या हासिल करने की कोशिश कर रहा था। एक पक्ष सत्यापन शर्त (validation condition) जोड़ सकता है जबकि दूसरा फ़ील्ड का नाम बदल सकता है; दोनों को संरक्षित करने का अर्थ उन्हें एक अद्यतन शर्त में संयोजित करना हो सकता है। फ़ाइल-स्तरीय विवाद के लिए, जैसे कि एक पक्ष फ़ाइल को हटा रहा है जबकि दूसरा उसे संपादित कर रहा है, यह तय करें कि क्या फ़ाइल रहनी चाहिए, और यदि हाँ तो आवश्यक संपादनों को शामिल करें। यदि पंक्तियों से आशय स्पष्ट नहीं है, तो निर्णय लेने से पहले आस-पास के कोड का निरीक्षण करें या परिवर्तन के लेखक से पूछें।

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

हल की गई फ़ाइलों की समीक्षा करें और स्टेज करें

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

git grep -n -E '^(<<<<<<<|=======|>>>>>>>)'

यदि इसे कोई मिलान मिलता है, तो उनकी समीक्षा करें: वैध दस्तावेज़ों या परीक्षण फिक्स्चर (test fixtures) में ये स्ट्रिंग्स हो सकती हैं, इसलिए मिलानों को बिना सोचे-समझे न हटाएं। एक बार जब किसी फ़ाइल का परिणाम सही हो जाए, तो git add को उसका उद्धृत पथ (quoted path) देकर उसे स्टेज करें, उदाहरण के लिए git add "Sources/Example.swift"। स्टेजिंग Git को बताती है कि फ़ाइल का विवाद हल हो गया है; यह यह साबित नहीं करता कि परिणाम सही है। Git के निर्देश प्रत्येक विवाद को संपादित करने, हल किए गए पथों को जोड़ने और फिर मर्ज को कमिट करने या जारी रखने के हैं। Git मर्ज दस्तावेज़

Mac पर एक विज़ुअल वर्कफ़्लो के लिए, Visual Studio Code स्रोत नियंत्रण (Source Control) में Merge Changes के अंतर्गत विवादित फ़ाइलों को सूचीबद्ध करता है। एक फ़ाइल खोलें और वर्तमान पक्ष, आने वाले पक्ष और परिणाम का निरीक्षण करने के लिए इसके इनलाइन विवाद क्रियाओं या Open in Merge Editor का उपयोग करें। एडिटर की Accept Both Changes क्रिया दोनों अनुभागों को क्रम में रखती है; परिणामी फ़ाइल की समीक्षा करें और आवश्यकता पड़ने पर सामग्री को संयोजित या समायोजित करें। परिणाम सहेजें और फ़ाइल को Source Control में स्टेज करें। ये नियंत्रण VS Code के हैं; अन्य एडिटर विभिन्न लेबलों या सुविधाओं का उपयोग कर सकते हैं। VS Code की मर्ज विवाद गाइड

मर्ज पूरा करें और परिणाम सत्यापित करें

प्रत्येक विवादित फ़ाइल को हल और स्टेज करने के बाद, स्थिति की दोबारा जाँच करें:

git status
git diff --cached

यह सुनिश्चित करने के लिए स्टेज किए गए डिफ (diff) की समीक्षा करें कि दोनों अभीष्ट योगदान एक समझदारी भरे अंतिम रूप में दिखाई दे रहे हैं और असंबद्ध संपादन शामिल नहीं हैं। यदि उपलब्ध हो तो प्रोजेक्ट के प्रासंगिक परीक्षण (checks) चलाएं; Git यह निर्धारित नहीं कर सकता कि संयुक्त तर्क (logic) इच्छानुसार व्यवहार करता है या नहीं।

कमांड-लाइन मर्ज के लिए, कार्रवाई को git merge --continue के साथ पूरा करें (या जब Git आपको ऐसा करने का निर्देश दे तो मर्ज को कमिट करें)। Git का --continue कमिट बनाने से पहले जाँचता है कि कोई मर्ज प्रगति पर है या नहीं। फिर यह पुष्टि करने के लिए git status दोबारा चलाएं कि मर्ज अब प्रगति पर नहीं है। यदि Git और अधिक विवादों की रिपोर्ट करता है, तो उन फ़ाइलों को भी हल और स्टेज करें। Git के मर्ज निर्देश

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

स्रोत