Merge Request (MR): यह क्या है, कैसे बनाएं और समीक्षा प्रक्रिया

Merge Request (MR) क्या है?

Merge Request (MR) — एक Git ब्रांच से दूसरी में बदलावों को एकीकृत करने का अनुरोध, जो कोड समीक्षा और स्वचालित जाँच की प्रक्रिया शुरू करता है। कंसोल के माध्यम से सीधे मर्ज करने के विपरीत, MR एक औपचारिक प्रक्रिया बनाता है: डेवलपर बदलावों का वर्णन करता है, समीक्षक निर्धारित करता है, CI/CD शुरू करता है, और बदलाव लागू होने से पहले प्रतिक्रिया प्राप्त करता है। यह GitLab का एक प्रमुख तत्व है, लेकिन GitHub में समान तंत्र को Pull Request (PR) कहा जाता है।

GitLab Documentation, 2026 के अनुसार, GitLab में प्रतिवर्ष 80 मिलियन से अधिक Merge Requests बनाए जाते हैं। प्रत्येक MR में चार मुख्य घटक होते हैं: बदलावों के संदर्भ के साथ विवरण, कमिट्स की सूची, कोड अंतर (diff), और चर्चा (चर्चा सूत्र)। इनमें से एक तत्व के बिना, MR अधूरा माना जाता है।

Merge Request (MR) तीन कार्यों को हल करता है: संरक्षित ब्रांचों (main, develop) में सीधे बदलावों को रोकता है, समीक्षा के माध्यम से गुणवत्ता नियंत्रण प्रदान करता है, और भविष्य के डेवलपर्स के लिए चर्चा इतिहास संरक्षित करता है। GitLab में, MR की स्थिति इंटरफ़ेस में रंग संकेतकों के साथ प्रदर्शित होती है: Draft के लिए ग्रे, लंबित के लिए नारंगी, Approved के लिए हरा, Merged के लिए बैंगनी और Closed के लिए लाल।

शब्दावली: MR, PR और CR

विभिन्न Git प्लेटफ़ॉर्मों पर, Merge Request को अलग-अलग नामों से पुकारा जाता है। GitLab “Merge Request” (MR) का उपयोग करता है, GitHub “Pull Request” (PR) का उपयोग करता है। Gerrit में Change Request (CR) समान है। तीनों एक ही प्रक्रिया को दर्शाते हैं: कोड समीक्षा के माध्यम से बदलावों को एकीकृत करने का अनुरोध। शब्द का चयन केवल परियोजना में उपयोग किए जाने वाले प्लेटफ़ॉर्म पर निर्भर करता है।

# बदलावों के साथ ब्रांच बनाएं
git checkout -b feature/add-auth
git commit -m "Add OAuth2 authentication flow"
git push origin feature/add-auth

# आप GitLab/GitHub UI या CLI के माध्यम से MR बना सकते हैं:
gh pr create --title "Add OAuth2 authentication flow" \
  --body "Implements OAuth2 with Google and Apple providers" \
  --reviewer "team-lead"

MR बनाम PR: GitLab और GitHub में क्या अंतर है

GitLab में Merge Request और GitHub में Pull Request कार्यात्मक रूप से समान तंत्र हैं जिनके अलग-अलग नाम हैं। अंतर इतिहास के कारण है: GitLab ने मूल रूप से खुद को GitHub के Self-Hosted विकल्प के रूप में स्थापित किया और मर्ज प्रक्रिया के लिए “merge request” शब्द चुना। GitHub, जो पहले लॉन्च हुआ, ने “pull request” का उपयोग किया — मुख्य ब्रांच में बदलावों को “खींचने” (pull) का अनुरोध।

GitHub Docs, 2024 के अनुसार, दोनों उपकरण समान सुविधाओं का समर्थन करते हैं: Markdown विवरण, समीक्षक निर्धारण, कोड की विशिष्ट पंक्तियों पर टिप्पणी, जाँच स्थितियाँ और शर्तें पूरी होने पर स्वचालित मर्ज। अंतर इंटरफ़ेस और अतिरिक्त क्षमताओं से संबंधित हैं।

Merge Request कैसे बनाएं: चरण-दर-चरण मार्गदर्शिका

Merge Request (MR) बनाना रिमोट रिपॉजिटरी में बदलावों वाली ब्रांच प्रकाशित करने से शुरू होता है। GitLab या GitHub में push करने के बाद, इंटरफ़ेस में “Create Merge Request” या “Compare & Pull Request” बटन दिखाई देता है। डेवलपर विवरण भरता है, लक्ष्य ब्रांच (आमतौर पर develop या main) निर्दिष्ट करता है, समीक्षक निर्धारित करता है और लेबल संलग्न करता है।

GitLab Documentation, 2025 के अनुसार, एक मानक MR में 72 वर्णों तक का शीर्षक, एक टेम्पलेट के साथ विवरण और कार्य (issue) का लिंक होता है। विवरण को प्रश्नों का उत्तर देना चाहिए: क्या किया गया, क्यों, कैसे परीक्षण किया गया। GitLab Closes, Fixes, Resolves कीवर्ड के माध्यम से मर्ज पर कार्यों के स्वत:-समापन का समर्थन करता है।

# .gitlab/merge_request_templates/default.md टेम्पलेट का उदाहरण
## What does this MR do?

[परिवर्तनों का संक्षिप्त विवरण: क्या और क्यों]

## How to test

1. चलाएं ./gradlew test
2. जांचें LoginActivity टेस्ट टोकन के साथ
3. सुनिश्चित करें कि AuthManager

## Related issues

Closes #142

MR जीवनचक्र: Draft से Merged तक

Merge Request (MR) GitLab में पाँच स्थितियों से गुज़रता है। पहला Draft (मसौदा) है, जिसे शीर्षक में “Draft:” उपसर्ग से चिह्नित किया जाता है, जो मर्ज को अवरुद्ध करता है। तैयार होने पर, डेवलपर Draft हटाता है, और MR Opened स्थिति में आ जाता है — कोड समीक्षा शुरू होती है और CI/CD पाइपलाइन शुरू होती है।

GitLab Docs, 2024 के अनुसार, Opened स्थिति में, समीक्षक diff की जाँच करते हैं, टिप्पणियाँ छोड़ते हैं, और Resolve Threads के माध्यम से बदलाव का अनुरोध करते हैं। जब सभी सूत्र हल हो जाते हैं और CI/CD सफलतापूर्वक पास हो जाता है, तो जिम्मेदार डेवलपर Approve सेट करता है। उसके बाद, MR को Merge बटन का उपयोग करके मर्ज किया जा सकता है, या स्वचालित मर्ज (Auto-merge) की प्रतीक्षा की जा सकती है।

GitLab तीन अंतिम स्थिति विकल्पों का समर्थन करता है: Merged (सफलतापूर्वक मर्ज), Closed (बिना मर्ज बंद, जैसे किसी सुविधा को छोड़ने पर), और Reopened (बंद करने के बाद पुनः खोलना)। ऑडिट के लिए प्रत्येक स्थिति MR गतिविधि समयरेखा में लॉग की जाती है।

स्वचालित स्थितियाँ और ट्रिगर

GitLab घटनाओं पर Merge Request स्थिति को स्वचालित रूप से अपडेट करता है: नए कमिट्स push करने पर Approvals रीसेट हो जाती हैं, सफल CI पाइपलाइन पर स्थिति Pipeline passed हो जाती है, विफलता पर — Pipeline failed (मर्ज अवरुद्ध हो जाता है)। Auto-merge कॉन्फ़िगर किया जा सकता है: सफल CI और सभी आवश्यक अनुमोदन प्राप्त करने के बाद MR स्वचालित रूप से मर्ज हो जाता है।

• Draft — मसौदा, CI चलता है लेकिन मर्ज अवरुद्ध है
• Opened — समीक्षा के लिए तैयार, समीक्षक निर्धारित, पाइपलाइन सक्रिय
• Approved — आवश्यक संख्या में अनुमोदन प्राप्त हुए
• Merged — बदलाव लक्ष्य ब्रांच में मर्ज हो गए
• Closed — बिना मर्ज बंद

Merge Request में कोड समीक्षा के नियम

Merge Request (MR) में कोड समीक्षा अधिकांश वाणिज्यिक परियोजनाओं में एक अनिवार्य चरण है। SmartBear, 2023 के शोध के अनुसार, MR के साथ कोड समीक्षा दोषों की संख्या को 30–60% तक कम करती है और नए डेवलपर्स के ऑनबोर्डिंग को तेज़ करती है। मुख्य नियम यह है कि प्रत्येक MR की जाँच कम से कम एक, अधिमानतः दो डेवलपर्स द्वारा की जाए जिन्होंने कोड लिखने में भाग नहीं लिया।

MR समीक्षा में पाँच मानदंड शामिल हैं: तार्किक शुद्धता, कोड शैली अनुपालन, परीक्षण कवरेज, सुरक्षा और प्रदर्शन। GitLab में, Required Approvals कॉन्फ़िगर की जा सकती हैं — मर्ज से पहले अनिवार्य अनुमोदनों की संख्या, उदाहरण के लिए main के लिए 2 अनुमोदन और develop के लिए 1।

MR में चर्चा Threads में आयोजित की जाती है — कोड की विशिष्ट पंक्तियों पर टिप्पणियाँ। मर्ज से पहले प्रत्येक सूत्र को हल किया जाना चाहिए। समीक्षाओं को गति देने के लिए, MR आकार को सीमित करने की अनुशंसा की जाती है: 200–400 पंक्तियाँ। Google Research (2022) के अनुसार, 400 पंक्तियों से बड़े MR की समीक्षा 30% कम प्रभावी ढंग से की जाती है।

Merge Request में CI/CD पाइपलाइन

Merge Request (MR) बनने पर, CI/CD पाइपलाइन स्वचालित रूप से शुरू होती है। GitLab में यह .gitlab-ci.yml फ़ाइल के माध्यम से होता है, GitHub में GitHub Actions वर्कफ़्लो के माध्यम से। पाइपलाइन में प्रोजेक्ट बिल्ड, यूनिट टेस्ट, लिंटर्स, स्थैतिक विश्लेषण (SAST) और कोड कवरेज जाँच शामिल है।

GitLab Blog, 2024 के अनुसार, पाइपलाइन की स्थिति सीधे MR में प्रदर्शित होती है: हरा चेकमार्क (passed), लाल क्रॉस (failed), या पीला वृत्त (running)। यदि पाइपलाइन विफल होती है, तो GitLab ठीक होने तक Merge बटन को अवरुद्ध करता है। सेटिंग्स में, “Merge when pipeline succeeds” सक्षम किया जा सकता है — सफल पाइपलाइन के बाद स्वचालित मर्ज।

# .gitlab-ci.yml — Android प्रोजेक्ट के लिए उदाहरण
test:
  stage: test
  script:
    - ./gradlew ktlintCheck
    - ./gradlew testDebugUnitTest
  only:
    - merge_requests

build:
  stage: build
  script:
    - ./gradlew assembleDebug
  only:
    - merge_requests

मर्ज विधियाँ: Squash, Merge Commit, Fast-Forward

GitLab और GitHub Merge Request के लिए तीन मर्ज विधियाँ प्रदान करते हैं। चुनाव टीम की नीति और वांछित इतिहास की सफाई पर निर्भर करता है। Merge Commit एक अलग मर्ज कमिट बनाता है, जो पूरी सुविधा ब्रांच इतिहास को संरक्षित करता है। Squash सभी ब्रांच कमिट्स को लक्ष्य ब्रांच पर एक कमिट में जोड़ता है। Fast-Forward बिना मर्ज कमिट के कमिट्स को रैखिक रूप से लागू करता है।

GitLab Docs, 2025 के अनुसार, उच्च कमिट घनत्व वाली परियोजनाओं (एक सुविधा ब्रांच में 20+ कमिट) के लिए Squash पसंद किया जाता है। Trunk-Based Development के लिए Fast-Forward अनिवार्य है। Git Flow में शाखाकरण शब्दार्थ को संरक्षित करने के लिए Merge Commit का उपयोग किया जाता है।

• Merge Commit — इतिहास संरक्षित करता है, मर्ज कमिट बनाता है, Git Flow के लिए उपयुक्त
• Squash — सभी कमिट्स को एक में जोड़ता है, साफ इतिहास, मध्यवर्ती कमिट्स खो देता है
• Fast-Forward — बिना मर्ज कमिट के रैखिक इतिहास, TBD में अनिवार्य

सर्वोत्तम अभ्यास: अच्छा MR कैसे लिखें

एक गुणवत्तापूर्ण Merge Request (MR) समीक्षा समय और त्रुटियों की संख्या को कम करता है। पहला नियम है एक MR एक कार्य हल करता है। यदि बदलाव कई असंबंधित सुविधाओं को प्रभावित करते हैं, तो उन्हें अलग-अलग MR में विभाजित किया जाना चाहिए। दूसरा, MR शीर्षक सूचनाप्रद होना चाहिए: “Fix stuff” या “Update code” के बजाय “Add OAuth2 authentication with Google provider”।

Google Engineering Practices, 2024 के अनुसार, एक अच्छे MR में संदर्भ विवरण होता है: बदलाव क्यों आवश्यक हैं, उनका परीक्षण कैसे किया गया, और क्या जोखिम मौजूद हैं। MR का आकार 400 पंक्तियों से अधिक नहीं होना चाहिए। यदि मात्रा बड़ी है, तो कार्य को उप-कार्यों में विभाजित करने की आवश्यकता है। दस्तावेज़ीकरण और परीक्षणों के लिए, अपवाद स्वीकार्य हैं लेकिन स्पष्टीकरण के साथ।

Merge Request (MR) में नई कार्यक्षमता के लिए स्वचालित परीक्षण शामिल होने चाहिए। GitLab में, Coverage Check नीति कॉन्फ़िगर की जा सकती है — यदि कोड कवरेज एक सीमा (जैसे 80%) से नीचे गिरता है तो MR स्वचालित रूप से अवरुद्ध हो जाता है। यह सुनिश्चित करता है कि नई कार्यक्षमता समग्र परियोजना गुणवत्ता को कम न करे।

• एक MR — एक कार्य: बड़े बदलावों को कई छोटे MR में विभाजित करें
• टेम्पलेट के साथ विवरण: एकरूपता के लिए .gitlab/merge_request_templates का उपयोग करें
• आकार 400 पंक्तियों तक: बड़े MR धीमी गति से और अधिक त्रुटियों के साथ समीक्षित होते हैं
• परीक्षण अनिवार्य: नई सुविधाओं को यूनिट परीक्षणों द्वारा कवर किया जाना चाहिए

MR विवरण टेम्पलेट

GitLab .gitlab/merge_request_templates/ फ़ाइलों के माध्यम से Merge Request टेम्पलेट का समर्थन करता है। टेम्पलेट में खंड शामिल हैं: क्या किया गया, कैसे परीक्षण करें, संबंधित कार्य और चेकलिस्ट। टेम्पलेट का उपयोग MR निर्माण को गति देता है और सुनिश्चित करता है कि डेवलपर्स महत्वपूर्ण जानकारी शामिल करना न भूलें। MR विवरण में, मर्ज पर कार्यों के स्वत:-समापन के लिए संबंधित issues (Closes #N) निर्दिष्ट किए जाने चाहिए।