ब्रांचों को मर्ज करना — यह क्या है, विलय के तरीके और संघर्ष समाधान

Git में मर्ज क्या है

Git में मर्ज दो या अधिक डेवलपमेंट इतिहासों को एक में संयोजित करने की क्रिया है। जब कोई डेवलपर ब्रांच को मर्ज करता है, Git स्वचालित रूप से सामान्य पूर्वज (base commit) ढूंढता है और एक नया मर्ज commit बनाता है जिसमें दोनों ब्रांचों के परिवर्तन शामिल होते हैं। Three-way merge मानक एल्गोरिदम है जो तीन अवस्थाओं की तुलना करता है: सामान्य पूर्वज, पहली ब्रांच और दूसरी ब्रांच।

मर्ज प्रक्रिया git merge कमांड से शुरू होती है। Git ब्रांचों के विचलन बिंदु को निर्धारित करता है और स्रोत ब्रांच से लक्ष्य ब्रांच पर क्रमिक रूप से परिवर्तन लागू करता है। यदि परिवर्तन संघर्ष नहीं करते, Git सेटिंग्स के अनुसार fast-forward या merge commit बनाता है। Fast-forward एक परिदृश्य है जहाँ लक्ष्य ब्रांच स्रोत ब्रांच के commits पर चली जाती है।

# लक्ष्य ब्रांच पर स्विच करें और मर्ज करें
git checkout main
git merge feature/payment-module

# स्पष्ट no-fast-forward के साथ मर्ज करें
git merge --no-ff feature/payment-module

# यदि संघर्ष बहुत जटिल हैं तो मर्ज रद्द करें
git merge --abort

--no-ff फ्लैग (no fast-forward) fast-forward संभव होने पर भी merge commit बनाने के लिए बाध्य करता है। यह जानकारी संरक्षित करता है कि परिवर्तन एक अलग ब्रांच में किए गए थे। कई टीमें स्पष्ट रूप में ब्रांचिंग इतिहास बनाए रखने के लिए इस दृष्टिकोण को पसंद करती हैं।

ब्रांच विलय के तरीके

Git में ब्रांच विलय की तीन मुख्य रणनीतियाँ हैं, प्रत्येक एक विशिष्ट परिदृश्य के लिए उपयुक्त है। रणनीति का चुनाव टीम की संस्कृति और प्रोजेक्ट इतिहास की स्वच्छता की आवश्यकताओं पर निर्भर करता है।

Standard merge दो माता-पिता के साथ merge commit बनाता है। पूरा इतिहास संरक्षित रहता है, लेकिन ब्रांचिंग ग्राफ अधिक जटिल हो जाता है। Squash merge फीचर ब्रांच के सभी commits को एक में जोड़ता है और लक्ष्य ब्रांच पर लागू करता है — इतिहास रैखिक और साफ हो जाता है, लेकिन मध्यवर्ती चरणों की जानकारी खो जाती है।

Rebase, हालाँकि पूर्ण मर्ज नहीं है, वही परिणाम प्राप्त करता है — एक ब्रांच के परिवर्तन दूसरे के ऊपर स्थानांतरित हो जाते हैं। अंतर यह है कि इतिहास फिर से लिखा जाता है: फीचर ब्रांच के commits लक्ष्य ब्रांच के नवीनतम commit के ऊपर फिर से बनाए जाते हैं। यह पूरी तरह से रैखिक इतिहास देता है, लेकिन push करते समय force push की आवश्यकता होती है।

मर्ज में संघर्ष कैसे हल करें

मर्ज संघर्ष तब उत्पन्न होता है जब किसी फ़ाइल की समान पंक्तियाँ दो ब्रांचों में बदल दी जाती हैं। Git स्वचालित रूप से यह निर्धारित नहीं कर सकता कि कौन सा संस्करण रखना है और डेवलपर के हस्तक्षेप की आवश्यकता है। संघर्ष फ़ाइलों में विशेष मार्करों के साथ प्रदर्शित होते हैं: <<<<<<<, =======, >>>>>>>।

संघर्ष समाधान प्रक्रिया में कई चरण शामिल हैं। पहले, डेवलपर संघर्ष वाली फ़ाइल खोलता है और मैन्युअल रूप से आवश्यक परिवर्तन चुनता है। केवल एक संस्करण चुनना नहीं, बल्कि दोनों परिवर्तनों के तर्क को समझना और सही निर्णय लेना महत्वपूर्ण है। फ़ाइल संपादित करने के बाद, संघर्ष मार्कर हटा दिए जाते हैं और परिवर्तन git add के माध्यम से staging area में जोड़े जाते हैं।

# संघर्ष वाली फ़ाइलों की सूची देखें
git status

# mergetool शुरू करें (जैसे VS Code, IntelliJ)
git mergetool

# सभी संघर्ष हल करने के बाद
git add .
git merge --continue

# या मर्ज पूरी तरह रद्द करें
git merge --abort

दृश्य मर्ज टूल का उपयोग संघर्ष समाधान को काफी तेज करता है। VS Code, IntelliJ IDEA और GitKraken तीन पैनलों के साथ इंटरफेस प्रदान करते हैं: वर्तमान ब्रांच, आने वाली ब्रांच और परिणाम। git mergetool टूल प्रत्येक संघर्ष वाली फ़ाइल के लिए स्वचालित रूप से कॉन्फ़िगर किया गया संपादक खोलता है।

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

मर्ज के बजाय rebase का उपयोग कब करें

Rebase और merge परिवर्तनों को संयोजित करने के दो तरीके हैं, और उनके बीच चुनाव अक्सर टीमों में बहस का कारण बनता है। Rebase इतिहास को फिर से लिखते हुए एक ब्रांच के commits को दूसरे के ऊपर स्थानांतरित करता है। Merge ब्रांचिंग इतिहास को संरक्षित करते हुए एक नया merge commit बनाता है। प्रत्येक दृष्टिकोण के अपने फायदे और सीमाएँ हैं।

Rebase उपयुक्त है जब डेवलपर अपनी स्थानीय फीचर ब्रांच पर काम कर रहा हो और Pull Request बनाने से पहले एक साफ रैखिक इतिहास चाहता हो। Rebase के बाद, सभी commits अनावश्यक merge commits के बिना क्रमिक रूप से व्यवस्थित हो जाते हैं। हालाँकि, rebase के लिए force push की आवश्यकता होती है और यह उन ब्रांचों पर लागू नहीं होता जिन पर एक साथ कई लोग काम करते हैं।

• Rebase — व्यक्तिगत फीचर ब्रांचों के लिए जहाँ साफ इतिहास चाहिए
• Merge — साझा ब्रांचों और विलय क्षण को रिकॉर्ड करने के लिए
• Squash — जब फीचर ब्रांच में कई छोटे ड्राफ्ट commits हों

Git का सुनहरा नियम: उन commits पर rebase का उपयोग न करें जो पहले से साझा रिपॉजिटरी में push किए जा चुके हैं। यह सुनिश्चित करता है कि साझा ब्रांच में इतिहास अपरिवर्तित रहे और अन्य डेवलपर्स को डुप्लिकेट या खोए हुए commits का सामना न करना पड़े। फीचर ब्रांच को मुख्य ब्रांच में एकीकृत करने के लिए Pull Request के माध्यम से merge का उपयोग करें।

ब्रांच विलय के सर्वोत्तम अभ्यास

सही मर्ज प्रक्रिया स्थिर डेवलपमेंट की नींव है। आधुनिक टीम वर्क में, मर्ज कंसोल के माध्यम से नहीं, बल्कि GitHub पर Pull Request या GitLab में Merge Request के माध्यम से किया जाता है। PR कोड समीक्षा, स्वचालित CI जाँचों से गुज़रता है और उसके बाद ही मुख्य ब्रांच में मर्ज किया जाता है।

पहला अभ्यास — सभी जाँचें पास होने के बाद ही मर्ज करें। CI पाइपलाइन को प्रोजेक्ट बनाना चाहिए, परीक्षण चलाने चाहिए और कोड गुणवत्ता की जाँच करनी चाहिए। यदि कम से कम एक जाँच विफल होती है, मर्ज अवरुद्ध हो जाता है। आधुनिक प्लेटफ़ॉर्म (GitHub, GitLab) में अंतर्निहित सुरक्षा है: branch protection rules CI विफल होने पर स्वचालित रूप से मर्ज को अवरुद्ध करते हैं।

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

तीसरा अभ्यास — मर्ज के बाद फीचर ब्रांचों को साफ करें। जो ब्रांच पहले ही मर्ज हो चुकी है उसे हटा देना चाहिए। यह भ्रम और रिपॉजिटरी में अव्यवस्था को रोकता है। GitHub PR मर्ज होने के बाद स्वचालित रूप से ब्रांच हटाने का सुझाव देता है, और रिपॉजिटरी सेटिंग्स को स्वचालित हटाने के लिए कॉन्फ़िगर किया जा सकता है।