मर्ज — यह क्या है, मर्ज के प्रकार और कार्यप्रणाली
मर्ज — Git में एक ऑपरेशन है जो एक ब्रांच से दूसरी ब्रांच में परिवर्तनों को मिलाकर मर्ज कमिट (merge commit) बनाता है। Git कई रणनीतियों का समर्थन करता है: फ़ास्ट-फ़ॉरवर्ड (रैखिक इतिहास), थ्री-वे मर्ज (merge commit के साथ) और स्क्वैश मर्ज (सभी कमिट को एक में संपीड़ित करना)। git-scm.com, 2025 के अनुसार, मर्ज टीम Git डेवलपमेंट में सबसे अधिक उपयोग किया जाने वाला कोड एकीकरण तंत्र बना हुआ है।
मुख्य बिंदु
- मर्ज — Git में मर्ज कमिट के साथ या बिना ब्रांच मर्ज करने की प्रक्रिया
- फ़ास्ट-फ़ॉरवर्ड मर्ज — बिना अतिरिक्त कमिट के रैखिक मर्ज जब कोई विचलन न हो
- थ्री-वे मर्ज — ब्रांच के विचलन पर merge commit बनाता है
- स्क्वैश मर्ज — मर्ज करने से पहले ब्रांच के सभी कमिट को एक में संपीड़ित करता है
- कॉन्फ़्लिक्ट तब उत्पन्न होते हैं जब दोनों ब्रांच में समान पंक्तियाँ बदली जाती हैं
मर्ज क्या है?
मर्ज Git में एक मौलिक प्रक्रिया है जो एक ब्रांच (स्रोत) से दूसरी ब्रांच (लक्ष्य) में परिवर्तनों को जोड़ती है। मर्ज के परिणामस्वरूप, लक्ष्य ब्रांच को स्रोत ब्रांच के सभी कमिट मिलते हैं जो अभी तक उसमें नहीं थे। स्थिति पर निर्भर करते हुए, Git तीन अलग-अलग तरीकों से मर्ज कर सकता है।
मर्ज का मुख्य मूल्य इतिहास को संरक्षित करना है: मर्ज कमिट ब्रांच मर्जिंग के तथ्य को रिकॉर्ड करता है, यह जानकारी संरक्षित करता है कि कब और कौन सी ब्रांच मर्ज की गईं। यह परिवर्तन ऑडिट, रिग्रेशन खोज और डेवलपमेंट कालक्रम को समझने में सुविधा प्रदान करता है। बड़े प्रोजेक्ट्स में, मर्ज कमिट कोड एकीकरण का मानक तरीका है।
GitLab Flow के अनुसार, Git के साथ काम करने वाली 73% टीमें मर्ज कमिट का उपयोग करती हैं। वैकल्पिक दृष्टिकोण (रीबेस, स्क्वैश) उन टीमों द्वारा पसंद किए जाते हैं जो रैखिक इतिहास पर केंद्रित हैं। रणनीति का चुनाव टीम के आकार, रिलीज़ आवृत्ति और प्रोजेक्ट में स्वीकृत सम्मेलनों पर निर्भर करता है।
मर्ज कब आवश्यक होता है
मर्ज तब आवश्यक होता है जब कोई डेवलपर किसी फ़ीचर पर काम पूरा कर लेता है और उसे develop या main में एकीकृत करना चाहता है। एक सामान्य परिदृश्य: डेवलपर ने develop से एक फ़ीचर ब्रांच बनाई, उस पर कई दिनों तक काम किया, और इस दौरान develop में टीम के अन्य सदस्यों के नए कमिट आए। मर्ज करने से पहले, परिवर्तनों को संयोजित करना आवश्यक है — और इसके लिए मर्ज का उपयोग किया जाता है।
मर्ज के बिना, Git में एक कोडबेस पर सहयोगात्मक रूप से काम करना असंभव है। हर बार जब दो डेवलपर एक साथ एक कोडबेस में परिवर्तन करते हैं, तो उनकी ब्रांच विचलित हो जाती हैं। मर्ज ही इन परिवर्तनों को डेटा हानि के बिना वापस लाने का एकमात्र तरीका है।
Git में मर्ज के प्रकार
Git तीन प्रकार के मर्ज का समर्थन करता है, प्रत्येक अपने स्वयं के परिदृश्य के लिए डिज़ाइन किया गया है। मर्ज प्रकार का चुनाव कमिट इतिहास, रोलबैक सुविधा और लॉग पठनीयता को प्रभावित करता है।
फ़ास्ट-फ़ॉरवर्ड मर्ज
फ़ास्ट-फ़ॉरवर्ड तब होता है जब लक्ष्य ब्रांच में स्रोत ब्रांच बनने के बाद से कोई नया कमिट नहीं हुआ है। इस मामले में, Git बस लक्ष्य ब्रांच पॉइंटर को स्रोत ब्रांच के अंतिम कमिट पर आगे बढ़ा देता है। इतिहास रैखिक रहता है, बिना मर्ज कमिट के।
bash
# फ़ास्ट-फ़ॉरवर्ड मर्ज: फ़ीचर निर्माण के बाद से develop नहीं बदला
git checkout develop
git merge feature/new-login
# परिणाम: develop पॉइंटर फ़ीचर के अंत में चला गया
# कोई मर्ज कमिट नहीं बनाया गयाफ़ास्ट-फ़ॉरवर्ड अल्पकालिक ब्रांच के लिए सुविधाजनक है जहाँ एक डेवलपर अकेले काम करता है। लेकिन इस दृष्टिकोण में एक कमी है: ब्रांच के अस्तित्व की जानकारी खो जाती है — सभी कमिट ऐसे दिखते हैं जैसे सीधे develop में किए गए हों।
थ्री-वे मर्ज
थ्री-वे मर्ज तब निष्पादित किया जाता है जब विचलन बिंदु के बाद दोनों ब्रांच में नए कमिट हों। Git दो माता-पिता के साथ एक अलग मर्ज कमिट बनाता है, जो ब्रांच मर्जिंग के तथ्य को रिकॉर्ड करता है। यह दृष्टिकोण टीम डेवलपमेंट में फ़ीचर ब्रांच के लिए अनुशंसित है।
bash
# --no-ff फ़्लैग के साथ बाध्यकारी थ्री-वे मर्ज
git checkout develop
git merge --no-ff feature/new-login
# डिफ़ॉल्ट संदेश के साथ मर्ज कमिट बनाया गया
# -m के माध्यम से अपना स्वयं का संदेश सेट कर सकते हैं
git merge --no-ff feature/new-login -m "Merge feature/new-login into develop"--no-ff फ़्लैग मर्ज कमिट के निर्माण की गारंटी देता है, भले ही फ़ास्ट-फ़ॉरवर्ड संभव हो। यह प्रोजेक्ट में ब्रांचिंग जानकारी को संरक्षित करने के लिए सर्वोत्तम अभ्यास है।
स्क्वैश मर्ज
स्क्वैश मर्ज स्रोत ब्रांच के सभी कमिट को एक में संपीड़ित करता है और इसे लक्ष्य पर लागू करता है। फ़ीचर का इतिहास खो जाता है — सभी परिवर्तनों वाला एक कमिट ब्रांच में आता है। यह तब सुविधाजनक होता है जब फ़ीचर ब्रांच में विस्तृत कमिट समग्र इतिहास में मूल्य नहीं जोड़ते।
bash
# स्क्वैश मर्ज: फ़ीचर के सभी कमिट एक में संपीड़ित
git checkout develop
git merge --squash feature/experimental
git commit -m "feat: experimental login flow (squashed)"स्क्वैश ड्राफ्ट, प्रायोगिक ब्रांच और उन स्थितियों के लिए उपयुक्त है जहाँ स्वच्छ इतिहास बनाए रखना महत्वपूर्ण है। नकारात्मक पक्ष — मूल कमिट से संबंध खो जाता है, जो व्यक्तिगत परिवर्तनों को वापस लाना कठिन बनाता है।
Ours और Theirs रणनीतियाँ
Ours और Theirs Git में दो विशेष मर्ज रणनीतियाँ हैं। Ours स्रोत ब्रांच के परिवर्तनों को पूरी तरह से अनदेखा करता है, केवल वही रखता है जो लक्ष्य में है। Theirs, इसके विपरीत, किसी भी कॉन्फ़्लिक्ट में स्रोत ब्रांच संस्करण को स्वीकार करता है। ये रणनीतियाँ कोड की बड़ी मात्रा को मर्ज करते समय उपयोगी होती हैं जब पहले से ज्ञात हो कि कौन सा संस्करण प्रबल होना चाहिए।
मर्ज कैसे काम करता है
Git में मर्ज तंत्र तीन बिंदुओं की तुलना पर आधारित है: सामान्य पूर्वज (मर्ज बेस), स्रोत ब्रांच की स्थिति और लक्ष्य ब्रांच की स्थिति। Git मर्ज बेस ढूँढता है — दोनों ब्रांच के लिए सामान्य अंतिम कमिट — और गणना करता है कि विचलन के बाद प्रत्येक ब्रांच में क्या परिवर्तन हुए।
- चरण 1 — Git मर्ज बेस निर्धारित करता है: दोनों ब्रांच में मौजूद अंतिम कमिट
- चरण 2 — Git दो डिफ़ बनाता है: मर्ज बेस से स्रोत तक और मर्ज बेस से लक्ष्य तक
- चरण 3 — Git परिवर्तनों के दोनों सेटों को मर्ज बेस पर लागू करने का प्रयास करता है
- चरण 4 — यदि परिवर्तन विरोधाभासी नहीं हैं — मर्ज स्वचालित रूप से पूरा हो जाता है
- चरण 5 — यदि कॉन्फ़्लिक्ट है — Git रुक जाता है और समाधान का अनुरोध करता है
Git एक त्रिपक्षीय मर्ज एल्गोरिदम का उपयोग करता है जो न केवल दो तुलनात्मक फ़ाइल संस्करणों को ध्यान में रखता है, बल्कि उनके सामान्य पूर्वज को भी। इसके लिए धन्यवाद, Git स्वचालित रूप से उन स्थितियों को हल कर सकता है जहाँ एक ब्रांच में परिवर्तन दूसरे के संशोधित क्षेत्रों को प्रभावित नहीं करते — भले ही दोनों फ़ाइलें संशोधित की गई हों।
मर्ज कार्य का उदाहरण
एक परिदृश्य पर विचार करें: दो डेवलपर एक फ़ीचर ब्रांच में विभिन्न फ़ाइलों पर काम कर रहे हैं। पहले ने LoginActivity.kt बदला, दूसरे ने ProfileFragment.kt बदला। जब वे अपने परिवर्तन मर्ज करते हैं, Git देखता है कि परिवर्तन विभिन्न फ़ाइलों को प्रभावित करते हैं और मानव हस्तक्षेप के बिना स्वचालित रूप से मर्ज करता है।
यदि दोनों डेवलपरों ने LoginActivity.kt बदला, लेकिन विभिन्न विधियों में — Git स्वचालित रूप से भी इसे संभालेगा, परिवर्तनों को पंक्ति दर पंक्ति मर्ज करके। कॉन्फ़्लिक्ट तभी उत्पन्न होता है जब दोनों ने समान पंक्तियाँ बदलीं या यदि एक ने कोड हटाया जो दूसरे ने बदला।
मर्ज कॉन्फ़्लिक्ट का समाधान
मर्ज कॉन्फ़्लिक्ट तब उत्पन्न होता है जब Git स्वचालित रूप से परिवर्तनों को मर्ज नहीं कर सकता क्योंकि दोनों ब्रांच ने समान पंक्तियों को अलग-अलग तरीके से संशोधित किया। इस मामले में, Git फ़ाइलों में कॉन्फ़्लिक्ट क्षेत्रों को चिह्नित करता है और डेवलपर से मैन्युअल समाधान की प्रतीक्षा करता है।
कॉन्फ़्लिक्ट क्षेत्र विशेष मार्करों से चिह्नित किए जाते हैं: <<<<<<< HEAD लक्ष्य ब्रांच का कोड दिखाता है, ======= विभाजक है, >>>>>>> source-branch स्रोत ब्रांच का कोड दिखाता है। डेवलपर को मैन्युअल रूप से चुनना होता है कि कौन सा संस्करण रखना है या उन्हें जोड़ना है।
bash
# 1. मर्ज चलाएँ और कॉन्फ़्लिक्ट देखें
git merge feature/new-login
# आउटपुट: CONFLICT (content): Merge conflict in LoginActivity.kt
# 2. कॉन्फ़्लिक्ट वाली फ़ाइलों की सूची देखें
git status
# both modified: src/ui/login/LoginActivity.kt
# 3. कॉन्फ़्लिक्ट हल करें: फ़ाइल संपादित करें, मार्कर हटाएँ
# 4. हल की गई फ़ाइल जोड़ें और मर्ज पूरा करें
git add src/ui/login/LoginActivity.kt
git merge --continue
# या: git commit (--continue के बिना)कॉन्फ़्लिक्ट हल करने के लिए उपकरण मौजूद हैं: git mergetool एक दृश्य मर्जर खोलता है (Meld, Beyond Compare, VS Code)। कई डेवलपर IDE में कॉन्फ़्लिक्ट हल करना पसंद करते हैं — IntelliJ IDEA और Android Studio तीन-पैनल तुलना के साथ एक अंतर्निहित उपकरण प्रदान करते हैं जो इस प्रक्रिया को काफी सरल बनाता है।
कॉन्फ़्लिक्ट हल करने के सुझाव: हमेशा समझें कि कॉन्फ़्लिक्ट का प्रत्येक पक्ष क्या करता है, दूसरे के कोड को उसके तर्क को समझे बिना न हटाएँ, और यदि कॉन्फ़्लिक्ट बहुत जटिल है — संयुक्त समाधान के लिए दोनों ब्रांच के लेखकों को शामिल करें।
मर्ज बनाम रीबेस: कब क्या चुनें
मर्ज और रीबेस के बीच चुनाव Git में सबसे आम वास्तु निर्णयों में से एक है। दोनों दृष्टिकोण परिवर्तनों को जोड़ते हैं, लेकिन अलग-अलग तरीके से: मर्ज ब्रांचिंग इतिहास को संरक्षित करता है, रीबेस इतिहास को फिर से लिखता है जिससे वह रैखिक हो जाता है।
- मर्ज — संदर्भ संरक्षित करता है: देख सकते हैं कि कब और किस ब्रांच से मर्ज किया गया। सार्वजनिक ब्रांच (develop, main) और टीम वर्क के लिए बेहतर
- रीबेस — बिना अतिरिक्त मर्ज कमिट के स्वच्छ रैखिक इतिहास बनाता है। समीक्षा से पहले व्यक्तिगत फ़ीचर ब्रांच के लिए बेहतर
- नियम: सार्वजनिक ब्रांच का कभी रीबेस न करें जिसका उपयोग अन्य डेवलपर कर रहे हों
कई टीमें एक हाइब्रिड दृष्टिकोण का उपयोग करती हैं: फ़ीचर ब्रांच को develop के साथ अद्यतन करने के लिए रीबेस (git rebase develop), फिर मर्ज रिकॉर्ड करने के लिए --no-ff फ़्लैग के साथ मर्ज। यह फ़ीचर के भीतर स्वच्छ इतिहास और develop स्तर पर सूचनात्मक मर्ज बिंदु देता है।
अक्सर पूछे जाने वाले प्रश्न
मर्ज और merge --no-ff में क्या अंतर है?
--no-ff के बिना Git यदि संभव हो तो फ़ास्ट-फ़ॉरवर्ड मर्ज करता है — बस ब्रांच पॉइंटर को स्थानांतरित करता है। --no-ff के साथ Git हमेशा मर्ज कमिट बनाता है, ब्रांचिंग जानकारी संरक्षित करता है। टीम डेवलपमेंट में फ़ीचर ब्रांच के लिए अनुशंसित।
अगर मर्ज कॉन्फ़्लिक्ट बहुत बड़ा हो तो क्या करें?
git mergetool या IDE के अंतर्निहित उपकरण का उपयोग करें। यदि कॉन्फ़्लिक्ट दर्जनों फ़ाइलों को प्रभावित करता है — ब्रांच शायद बहुत अधिक विचलित हो गई हैं। ऐसे में टीम के साथ मर्ज योजना पर चर्चा करें, संभवतः इसे कई चरणों में विभाजित करें।
क्या मर्ज को रद्द किया जा सकता है?
हाँ: git merge --abort मर्ज रद्द करता है यदि वह अभी पूरा नहीं हुआ है (कॉन्फ़्लिक्ट)। यदि मर्ज पहले ही पूरा हो चुका है — सुरक्षित रोलबैक के लिए git reset --hard HEAD~1 या git revert -m 1 <merge-commit> का उपयोग करें।
क्या प्रत्येक फ़ीचर के लिए मर्ज कमिट बनाना आवश्यक है?
टीम वर्क के लिए अनुशंसित। मर्ज कमिट मर्ज तथ्य को रिकॉर्ड करता है, दोनों ब्रांच के संदर्भ शामिल करता है और इतिहास समझने को सरल बनाता है। व्यक्तिगत या प्रायोगिक ब्रांच के लिए स्क्वैश मर्ज या फ़ास्ट-फ़ॉरवर्ड स्वीकार्य है।
मर्ज बाइनरी फ़ाइलों के साथ कैसे काम करता है?
Git स्वचालित रूप से बाइनरी फ़ाइलों को मर्ज नहीं कर सकता — वह एक संस्करण पूरी तरह से चुनता है। बाइनरी फ़ाइलों (चित्र, .aab, .apk) के लिए समानांतर परिवर्तनों को कम करने और बड़ी फ़ाइलों के लिए Git LFS का उपयोग करने की अनुशंसा की जाती है।
सारांश
- मर्ज — एक ब्रांच से दूसरी में परिवर्तन जोड़ने के लिए मूल Git संक्रिया
- फ़ास्ट-फ़ॉरवर्ड — बिना मर्ज कमिट के रैखिक मर्ज जब कोई विचलन न हो
- थ्री-वे मर्ज — दो माता-पिता के साथ मर्ज कमिट बनाता है, संदर्भ संरक्षित करता है
- स्क्वैश मर्ज — ब्रांच के सभी कमिट को एक में संपीड़ित करता है, फ़ीचर इतिहास खोता है
- कॉन्फ़्लिक्ट समान पंक्तियाँ बदलने पर उत्पन्न होते हैं और मैन्युअल हल किए जाते हैं
- मर्ज रीबेस से भिन्न: पहला ब्रांचिंग संरक्षित करता है, दूसरा इतिहास को रैखिक बनाता है
- सार्वजनिक ब्रांच के लिए --no-ff के साथ मर्ज अनुशंसित, व्यक्तिगत के लिए — रीबेस या स्क्वैश
हम एक मोबाइल एप्लिकेशन टर्नकी विकसित करेंगे
IT Sectr 2017 से स्टार्टअप और व्यवसायों के लिए iOS और Android एप्लिकेशन बनाता है। हम आपको सलाह देंगे और सर्वोत्तम समाधान प्रस्तावित करेंगे।
यह भी पढ़ें