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 میں چار اہم اجزاء ہوتے ہیں: تبدیلیوں کے سیاق و سباق کے ساتھ وضاحت، commits کی فہرست، کوڈ کا فرق (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 کلیدی الفاظ کے ذریعے انضمام پر issues کے خودکار بندش کی حمایت کرتا ہے۔

# .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 کی حالت خودکار طور پر اپ ڈیٹ کرتا ہے: نئے commits کے 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 ایک علیحدہ انضمام commit بناتا ہے، پوری فیچر برانچ تاریخ کو محفوظ رکھتا ہے۔ Squash تمام برانچ commits کو ہدف برانچ پر ایک commit میں یکجا کرتا ہے۔ Fast-Forward انضمام commit کے بغیر commits کو خطی طور پر لاگو کرتا ہے۔

GitLab Docs, 2025 کے مطابق، زیادہ commit کثافت والے منصوبوں (ایک فیچر برانچ میں 20+ commits) کے لیے Squash ترجیح دی جاتی ہے۔ Fast-Forward Trunk-Based Development کے لیے لازمی ہے۔ Merge Commit Git Flow میں برانچنگ کے معنی کو محفوظ رکھنے کے لیے استعمال ہوتا ہے۔

• Merge Commit — تاریخ محفوظ رکھتا ہے، انضمام commit بناتا ہے، Git Flow کے لیے موزوں
• Squash — تمام commits کو ایک میں یکجا کرتا ہے، صاف تاریخ، درمیانی commits کھو دیتا ہے
• Fast-Forward — انضمام commit کے بغیر خطی تاریخ، TBD میں لازمی

بہترین طریقے: اچھا MR کیسے لکھیں

ایک معیاری Merge Request (MR) جائزے کا وقت اور غلطیوں کی تعداد کم کرتا ہے۔ پہلا اصول یہ ہے کہ ایک MR ایک کام حل کرتا ہے۔ اگر تبدیلیاں متعدد غیر متعلقہ خصوصیات کو متاثر کرتی ہیں تو انہیں علیحدہ MRs میں تقسیم کیا جانا چاہیے۔ دوسرا، 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 — ایک کام: بڑی تبدیلیوں کو کئی چھوٹے MRs میں تقسیم کریں
• سانچے کے ساتھ وضاحت: یکسانیت کے لیے .gitlab/merge_request_templates استعمال کریں
• سائز 400 سطور تک: بڑے MRs کا جائزہ آہستہ اور زیادہ غلطیوں کے ساتھ لیا جاتا ہے
• ٹیسٹ لازمی ہیں: نئی خصوصیات کو یونٹ ٹیسٹ سے ڈھانپنا چاہیے

MR وضاحت کے سانچے

GitLab .gitlab/merge_request_templates/ فائلوں کے ذریعے Merge Request سانچوں کی حمایت کرتا ہے۔ سانچے میں حصے شامل ہیں: کیا کیا گیا، کیسے جانچنا ہے، متعلقہ کام اور چیک لسٹ۔ سانچوں کا استعمال MR بنانے کو تیز کرتا ہے اور یقینی بناتا ہے کہ ڈویلپر اہم معلومات شامل کرنا نہ بھولیں۔ MR کی وضاحت میں، انضمام پر کاموں کے خودکار بندش کے لیے متعلقہ issues (Closes #N) متعین کیے جانے چاہئیں۔