मर्ज (Merge) — यह क्या है, merge कैसे काम करता है और मर्जिंग रणनीतियाँ

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

मर्ज (Merge) git merge कमांड है जो निर्दिष्ट ब्रांच से परिवर्तनों को वर्तमान ब्रांच में संयोजित करता है। Git सामान्य पूर्वज (बेस कमिट) ढूंढता है, पूर्वज के सापेक्ष प्रत्येक ब्रांच के diff की गणना करता है, और परिवर्तनों का संयुक्त सेट वाला merge-कमिट बनाता है। परिणाम यह होता है कि लक्ष्य ब्रांच को मर्ज की गई ब्रांच से सभी परिवर्तन प्राप्त होते हैं।

सिंटैक्स: लक्ष्य ब्रांच (जैसे, main) पर रहते हुए, git merge feature निष्पादित करें। यदि कोई विवाद नहीं है तो Git स्वचालित रूप से merge-कमिट बनाता है। डिफ़ॉल्ट merge-कमिट संदेश है: “Merge branch 'feature' into main”। आप -m फ़्लैग का उपयोग करके संदेश बदल सकते हैं या खुले संपादक में इसे संपादित कर सकते हैं।

मर्ज एक गैर-विनाशकारी प्रक्रिया है। rebase के विपरीत, merge मौजूदा कमिट को नहीं छूता: वे समान हैश, लेखक और तिथियाँ बनाए रखते हैं। यह merge को उन ब्रांचों को मर्ज करने का एकमात्र सुरक्षित तरीका बनाता है जिन पर एक साथ कई डेवलपर काम कर रहे हैं। यदि कुछ गलत होता है, तो merge को git merge --abort से रद्द किया जा सकता है।

# लक्ष्य ब्रांच पर स्विच करें
git checkout main

# फ़ीचर ब्रांच मर्ज करें
git merge feature

# परिणाम — दो पैरेंट के साथ merge-कमिट
git log --oneline --graph

# कस्टम संदेश के साथ मर्ज
git merge feature -m "feat: integrate authentication module"

मर्ज के प्रकार: regular, squash, fast-forward

Git तीन मर्जिंग मोड का समर्थन करता है जो वांछित परिणाम के आधार पर चुने जाते हैं। रेगुलर मर्ज (डिफ़ॉल्ट) merge-कमिट बनाता है। Squash merge फ़ीचर ब्रांच के सभी कमिट को एक में संयोजित करता है। Fast-forward यदि संभव हो तो बिना कमिट बनाए ब्रांच पॉइंटर को आगे बढ़ाता है। मोड का चुनाव टीम के वर्कफ़्लो और इतिहास के नियमों पर निर्भर करता है।

रेगुलर मर्ज (--no-ff) — merge-कमिट बनाता है भले ही merge को fast-forward के रूप में किया जा सके। main ब्रांच के लिए अनुशंसित: merge-कमिट स्पष्ट रूप से फ़ीचर एकीकरण बिंदु को चिह्नित करता है और एक ही merge-कमिट revert के साथ सभी फ़ीचर ब्रांच परिवर्तनों को वापस लेना आसान बनाता है। GitHub PR को Merge बटन से मर्ज करते समय डिफ़ॉल्ट रूप से इस मोड का उपयोग करता है।

Squash merge (--squash) — फ़ीचर ब्रांच के सभी कमिट को लक्ष्य ब्रांच में एक एकल कमिट में इकट्ठा करता है। उपयोगी जब फ़ीचर ब्रांच का ड्राफ़्ट इतिहास main को दूषित नहीं करना चाहिए। कमी: मूल कमिट से संबंध खो जाता है — आप यह नहीं देख सकते कि फ़ीचर कैसे विकसित हुआ। GitHub PR में “Squash and merge” चुनने पर इस मोड का उपयोग करता है।

Fast-forward (--ff) — यदि फ़ीचर ब्रांच के अलग होने के बाद लक्ष्य ब्रांच में कोई नया कमिट नहीं है, तो Git बिना merge-कमिट बनाए पॉइंटर को आगे बढ़ा देता है। इतिहास रैखिक रहता है। --no-ff फ़्लैग merge-कमिट को बाध्य करता है, जबकि --ff-only त्रुटि देगा यदि fast-forward संभव नहीं है।

# Merge-कमिट बाध्य करें (main के लिए अनुशंसित)
git merge --no-ff feature

# Squash merge — सभी कमिट एक में
git merge --squash feature
git commit -m "feat: add authentication"

# Fast-forward केवल यदि संभव हो
git merge --ff-only feature

# विवादित मर्ज रद्द करें
git merge --abort

Git मर्जिंग रणनीतियाँ

मर्जिंग रणनीतियाँ एल्गोरिदम निर्धारित करती हैं जो Git परिवर्तनों को संयोजित करने के लिए उपयोग करता है। प्रत्येक रणनीति विभिन्न परिदृश्यों के लिए उपयुक्त है। Git स्वचालित रूप से उपयुक्त रणनीति चुनता है, लेकिन डेवलपर --strategy फ़्लैग का उपयोग करके इसे स्पष्ट रूप से निर्दिष्ट कर सकते हैं। रणनीतियों को समझने से जटिल मर्ज में Git के व्यवहार की भविष्यवाणी करने में मदद मिलती है।

Recursive — दो ब्रांचों को मर्ज करने के लिए डिफ़ॉल्ट रणनीति। Git सामान्य पूर्वज ढूंढता है, प्रत्येक ब्रांच में परिवर्तनों की गणना करता है, और उन्हें मर्ज करता है। यदि कोई सामान्य पूर्वज पाया जाता है, तो recursive फ़ाइल पुनर्नामकरण और जोड़ को सही ढंग से संभालता है। विवादों के दौरान, recursive अतिरिक्त विकल्पों का उपयोग कर सकता है: ours (स्वचालित रूप से हमारा संस्करण चुनें) और theirs (उनका संस्करण चुनें)।

Octopus — एक साथ दो से अधिक ब्रांचों को मर्ज करने के लिए: git merge feature1 feature2 feature3। Octopus विवाद समाधान का समर्थन नहीं करता — कमांड को कॉल करने से पहले सभी विवादों को हल किया जाना चाहिए। इसका उपयोग शायद ही कभी किया जाता है, मुख्य रूप से कई स्वतंत्र ब्रांचों को मर्ज करने के लिए जो गारंटीकृत रूप से विवाद नहीं करतीं (जैसे, विभिन्न मॉड्यूल)।

Ours — एक विशेष रणनीति जो मर्ज की गई ब्रांच के परिवर्तनों को पूरी तरह से अनदेखा करती है और लक्ष्य ब्रांच की वर्तमान सामग्री को रखती है। Merge-कमिट बनाया जाता है, लेकिन सामग्री अपरिवर्तित रहती है। उपयोगी जब आपको इतिहास में मर्ज के तथ्य को रिकॉर्ड करने की आवश्यकता हो लेकिन वास्तव में दूसरी ब्रांच के सभी परिवर्तनों को अस्वीकार करना हो।

मर्ज विवादों का समाधान

मर्ज विवाद (Merge conflict) तब होता है जब किसी फ़ाइल की समान पंक्तियों को दोनों ब्रांचों में अलग-अलग बदल दिया जाता है। Git स्वचालित रूप से यह निर्धारित नहीं कर सकता कि कौन सा संस्करण सही है और merge को रोक देता है। विवाद तब भी उत्पन्न हो सकता है जब किसी फ़ाइल का नाम एक ब्रांच में बदल दिया जाए और दूसरी में संशोधित किया जाए, या जब एक ही फ़ाइल को एक साथ हटाया और संशोधित किया जाए।

समाधान प्रक्रिया: Git विवादित फ़ाइलों को मार्करों से चिह्नित करता है। फ़ाइल में <<<<<<< HEAD (हमारा संस्करण), ======= (विभाजक), और >>>>>>> feature (उनका संस्करण) वाले अनुभाग दिखाई देते हैं। डेवलपर मैन्युअल रूप से विवादित अनुभाग को संपादित करता है, दोनों संस्करणों से वांछित पंक्तियों का चयन करता है, मार्करों को हटाता है, फ़ाइल को सहेजता है, और इसे git add के साथ इंडेक्स में जोड़ता है।

विवादों के दृश्य समाधान के लिए, Git mergetool का समर्थन करता है — एक बाहरी तुलना उपकरण। लोकप्रिय mergetool: Meld, KDiff3, Beyond Compare, VS Code (अंतर्निर्मित विवाद संपादक)। Mergetool तीन पैनल प्रदर्शित करता है: हमारा संस्करण, उनका संस्करण और परिणाम। डेवलपर अंतिम फ़ाइल में शामिल करने के लिए दृश्य रूप से कोड ब्लॉक चुनता है।

# मर्ज शुरू करें और विवाद का पता लगाएँ
git merge feature
# विवाद (सामग्री): src/main.swift में मर्ज विवाद

# विवादित फ़ाइलों की जाँच करें
git status

# दृश्य mergetool खोलें
git mergetool

# समाधान के बाद — add और commit
git add src/main.swift
git commit

# मर्ज रद्द करें
git merge --abort

rebase के बजाय merge कब चुनें

Merge, rebase से बेहतर है कई प्रमुख स्थितियों में। पहली: अन्य डेवलपर्स के लिए सुलभ सार्वजनिक ब्रांचों के साथ काम करते समय। Merge इतिहास को फिर से नहीं लिखता, इसलिए सहकर्मी सुरक्षित रूप से सिंक्रोनाइज़ कर सकते हैं। सार्वजनिक ब्रांच पर rebase करने से विचलित इतिहास बनता है और उन सभी के लिए विवाद होते हैं जिनके पास पहले से पुराने कमिट हैं।

दूसरी स्थिति: फ़ीचर ब्रांच को समाप्त करते समय। अधिकांश टीमें main में merge (--no-ff फ़्लैग के साथ) पसंद करती हैं ताकि फ़ीचर एकीकरण के क्षण को कैप्चर किया जा सके। यह इतिहास नेविगेशन को सरल बनाता है और merge-कमिट के एकल git revert के साथ पूरे फ़ीचर को वापस लेना आसान बनाता है। GitHub Flow डिफ़ॉल्ट रूप से तीन merge विकल्प प्रदान करता है: सरल merge, squash merge और rebase merge।

तीसरी स्थिति: समीक्षित pull request के साथ काम करते समय। GitHub और GitLab विभिन्न विकल्पों के साथ merge बटन प्रदान करते हैं। Merge (Create a merge commit) — merge-कमिट के साथ पूर्ण इतिहास। Squash and merge — विकास विवरण के बिना साफ इतिहास। Rebase and merge — बिना merge-कमिट के रैखिक इतिहास, लेकिन कमिट पुनर्लेखन के साथ। चुनाव टीम के नियमों पर निर्भर करता है।

• सार्वजनिक ब्रांच (main, develop) — केवल merge, कभी rebase नहीं।
• PR पूर्णता — एकीकरण बिंदु चिह्नित करने के लिए --no-ff के साथ merge।
• दूसरों के कमिट वाली ब्रांच — merge दूसरों के काम को फिर से नहीं लिखता।
• रिलीज़ से पहले — merge अधिक सुरक्षित है क्योंकि इसमें कम जोखिम हैं।
• साझा ब्रांच — यदि कई डेवलपर किसी ब्रांच पर काम करते हैं, तो merge अनिवार्य है।

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

पहला नियम: मर्ज करने से पहले हमेशा लक्ष्य ब्रांच के नवीनतम संस्करण पर रहें। फ़ीचर ब्रांच को मर्ज करने से पहले git checkout main && git pull चलाएँ। यह विवादों को कम करता है और सुनिश्चित करता है कि merge-कमिट में सभी नवीनतम परिवर्तन शामिल हों। यदि लक्ष्य ब्रांच काफी आगे बढ़ गई है, तो पहले फ़ीचर ब्रांच के अंदर git merge main चलाएँ ताकि उसके संदर्भ में विवादों को हल किया जा सके।

दूसरा नियम: मर्ज के बाद कोड का परीक्षण करें। मर्ज व्यवहार बदल सकता है भले ही कोई विवाद न हुआ हो। CI/CD पाइपलाइन को प्रोडक्शन में भेजने से पहले merge-कमिट पर परीक्षण चलाने चाहिए। कुछ टीमें merge गेट का उपयोग करती हैं — अनिवार्य जाँच जो merge को तब तक रोकती हैं जब तक वे पास न हो जाएँ।

तीसरा नियम: merge-कमिट का दस्तावेज़ीकरण करें। मानक संदेश “Merge branch 'feature' into main” बहुत उपयोगी नहीं है। यह अनुशंसा की जाती है कि क्या मर्ज किया गया इसका विवरण जोड़ें: “Merge authentication module: login, registration, password recovery”। यह इतिहास विश्लेषण और रिग्रेशन खोज को सरल बनाता है। बड़े प्रोजेक्ट्स में, merge-कमिट स्वचालित रूप से PR शीर्षक से उत्पन्न होते हैं।

• अद्यतन — मर्ज करने से पहले, सुनिश्चित करें कि लक्ष्य ब्रांच अपडेटेड है (git pull).
• परीक्षण — CI/CD को परिणामी merge-कमिट पर परीक्षण चलाने चाहिए।
• वर्णनात्मक संदेश — merge-कमिट में निर्दिष्ट करें कि कौन सी फ़ीचर मर्ज की गई।
• आवृत्ति — फ़ीचर ब्रांच को जितनी जल्दी और जितनी बार संभव हो मर्ज करें (अधिकतम एक सप्ताह)।
• वापस लेना — merge-कमिट का git revert पूरी फ़ीचर को वापस लाता है।