Pull Request چیست و چه تفاوتی با Merge Request دارد؟

وقتی کسی می‌گوید «PR بزن» یا «MR باز کن»، معمولاً یک کار را می‌خواهد: تغییرات روی یک Branch را پیشنهاد بده تا قبل از ورود به شاخهٔ اصلی، دیده، بحث و در صورت نیاز تست شود. نام‌ها از دو اکوسیستم آمده‌اند — Pull Request بیشتر با GitHub، Merge Request با GitLab — اما ایدهٔ هسته‌ای یکی است.

گیج شدن روی واژه‌ها طبیعی است؛ به‌خصوص اگر تیم بین GitHub و GitLab جابه‌جا شود یا مستندات قدیمی هر دو را مخلوط کرده باشد. این مقاله تعریف عملی هر دو، شباهت جریان کار، تفاوت‌های واقعی پلتفرم، و معیار تصمیم را جمع می‌کند تا روی نام گیر نکنید و روی کیفیت همکاری تمرکز کنید.

پیش‌نیاز مفید: آشنایی با Branch و Merge (مقالات ۰۷۶ و ۰۷۷). اگر هنوز Git را از صفر مرور نکرده‌اید، مقالهٔ ۰۷۲ نقطهٔ شروع بهتری است.

پاسخ کوتاه

Pull Request (PR) در GitHub پیشنهادی برای ادغام تغییرات یک Branch در Branch دیگر است؛ فضایی برای توضیح، بررسی فایل‌ها، کامنت، بررسی خودکار (Checks) و تصمیم ادغام. Merge Request (MR) در GitLab همان نقش را دارد: پیشنهاد ادغام از Source Branch به Target Branch با توضیح، بررسی خط‌به‌خط، پایپ‌لاین CI/CD و بحث تیمی.

از نظر مفهوم همکاری، PR و MR تقریباً مترادف‌اند. تفاوت معنادار معمولاً در نام‌گذاری پلتفرم، جزئیات UI، قوانین Approval، و ادغام با بقیهٔ ابزار همان محصول است — نه در «ایدهٔ پیشنهاد قبل از Merge». اگر تیم روی GitHub است بگویید PR؛ اگر روی GitLab است بگویید MR؛ جریان ذهنی یکی است.

PR/MR ابزار ادغام کور نیست؛ توقفگاه کوتاهی است تا تغییر دیده شود قبل از اینکه تاریخچهٔ مشترک را عوض کند.

Pull Request در GitHub دقیقاً چیست؟

طبق مستندات رسمی GitHub، Pull Request پیشنهادی برای ادغام تغییرات کد در پروژه است و ویژگی کلیدی همکاری: بحث و بررسی قبل از Merge تا تیم با هم کار کند، زود مشکل ببیند و کیفیت را نگه دارد. PR فقط دکمهٔ Merge نیست؛ بسته‌ای از زمینه است.

در رابط رایج GitHub، تب‌ها معمولاً این‌ها را جدا می‌کنند: Conversation (توضیح، تایم‌لاین، کامنت و Review)، Commits (مسیر تغییر Branch)، Checks (تست و Build خودکار)، Files changed (diff برای Reviewer)، و در صورت فعال بودن قابلیت‌ها، یافته‌های بررسی خودکار مثل هشدارهای code scanning. وضعیت Merge نشان می‌دهد چه چیزی هنوز مانع ادغام است — مثل Approval کم یا Check ناموفق.

Draft Pull Request

می‌توانید PR را به‌صورت Draft بسازید. Draft قابل Merge نیست و معمولاً Code Ownerها به‌صورت خودکار برای Review فراخوانده نمی‌شوند. برای اشتراک کارِ در حال انجام بدون درخواست رسمی Review مفید است. وقتی آماده شدید، آن را Ready for review می‌کنید.

دو مدل همکاری رایج

• Shared repository: همکاران به یک مخزن مشترک Push دارند و Topic Branch می‌سازند؛ PR برای Review قبل از ورود به شاخهٔ اصلی است — رایج در تیم‌های داخلی.
• Fork and pull: فرد مخزن را Fork می‌کند، روی Fork کار می‌کند و به Upstream درخواست می‌دهد — رایج در Open Source. محتوای آپلودشده به Fork از منظر دادهٔ Git با Upstream مرتبط است؛ حساسیت Secret اینجا هم مهم است.

Merge Request در GitLab چیست؟

طبق مستندات GitLab، Merge Request محل مرکزی برای Review کد، بحث و ردیابی تغییرات است. می‌توانید MR را به Issue وصل کنید تا پس از Merge، Issue بسته شود (اگر بستن خودکار فعال باشد). هدف صریح: متخصص موضوع تغییر را ببیند و الزامات امنیتی سازمان قبل از ورود به شاخهٔ هدف رعایت شود.

در صفحهٔ MR معمولاً توضیح درخواست، تغییرات کد و Review درون‌خطی، اطلاعات پایپ‌لاین CI/CD، گزارش‌های Mergeability، کامنت‌ها و فهرست Commitها دیده می‌شود. نقش‌ها اغلب به Assignee (مالک پیشرفت MR، معمولاً نویسنده) و Reviewer (بازخورد و در صورت صلاحیت Approve) تقسیم می‌شوند.

GitLab روی «زود باز کردن MR» تأکید دارد تا باگ و مشکل کیفیت زودتر دیده شود — همان پیام فرهنگی که تیم‌های سالم روی GitHub با Draft یا PR کوچک دنبال می‌کنند.

جدول مقایسهٔ عملی

این جدول برای ترجمهٔ واژه‌هاست، نه ادعای برتری یک پلتفرم. قابلیت‌های دقیق به طرح، نسخه و تنظیمات سازمان بستگی دارد.

چه چیزهایی واقعاً فرق می‌کنند؟

اگر فقط یک توسعه‌دهنده باشید که هر دو UI را دیده، تفاوت روزمره بیشتر واژگانی و جای دکمه‌هاست. وقتی تیم بزرگ می‌شود، تفاوت در «قوانین اجباری» دیده می‌شود: Protected Branch، تعداد Approve لازم، CODEOWNERS، اتصال اجباری به Pipeline سبز، و سیاست Bypass.

از دید صاحب محصول: PR/MR همان «درِ ورودی کیفیت» است. بدون آن، Merge مستقیم به main یعنی هر اشتباه تایپی یا Secret وارد تاریخچهٔ مشترک می‌شود. با آن، حداقل یک جفت چشم یا یک Check خودکار فرصت اعتراض دارد.

• نام را با ابزار تیم یکی کنید تا در Standup و تیکت ابهام نماند.
• اندازهٔ PR/MR را کوچک نگه دارید؛ Review سنگین‌ترین هزینهٔ پنهان است.
• توضیح «چرا» را بنویسید، نه فقط «چه فایلی عوض شد».
• CI قرمز را قبل از درخواست Review جدی بگیرید مگر اینکه خودِ موضوعِ PR تعمیر CI باشد.

جریان پیشنهادی برای تیم کوچک

1. از main (یا develop) یک Branch با نام معنادار بسازید.
2. Commitهای کوچک و خوانا بزنید؛ Secret داخل Commit نگذارید.
3. Push کنید و PR/MR باز کنید — اگر نیمه‌کاره است Draft.
4. توضیح، لینک Issue، و نحوهٔ تست دستی را بنویسید.
5. حداقل یک Reviewer بگیرید؛ برای مسیرهای حساس Approve اجباری بگذارید.
6. بعد از سبز شدن Checkها و رفع کامنت‌ها Merge کنید؛ Branch را پاک کنید اگر سیاست تیم اجازه می‌دهد.

این جریان جایگزین Git Flow کامل نیست؛ حداقلِ همکاری حرفه‌ای است. جزئیات Branch و Merge را در مقالات قبلی همین سری ببینید.

اشتباه‌های رایج

• باز کردن PR هزارخطی در آخر Sprint و انتظار Review باکیفیت.
• Merge کردن بدون نگاه به Files changed چون «فقط یک خط بود».
• استفاده از Force-push روی Branch مشترک بدون هماهنگی.
• گذاشتن کلید یا dump دیتابیس در Commit و امید به اینکه Private بودن مخزن کافی است.
• در نظر گرفتن Approve به‌عنوان تعارف اجتماعی، نه بررسی واقعی.

Code Review موضوع مقالهٔ بعدی (۰۷۹) است؛ اینجا فقط این را ثبت کنیم که PR/MR بدون فرهنگ Review، به فرم خالی تبدیل می‌شود.

برای مدیر غیرتکنیکال چه معنایی دارد؟

وقتی تیم می‌گوید «هنوز Merge نشده، روی PR است»، یعنی کار نوشته شده اما وارد نسخهٔ مشترک پایدار نشده. این وضعیت معمولاً سالم است: کنترل کیفیت، نه کندی بی‌دلیل. فشار برای «مستقیم روی main بزن» هزینهٔ باگ و گاهی نشت Secret را جابه‌جا می‌کند، نه اینکه حذف کند.

معیار دیده‌بانی ساده: میانگین عمر PR، درصد PRهایی که بدون Comment Merge می‌شوند، و تعداد Rollback بعد از Merge. اگر عمر PR هفته‌هاست، مشکل ابزار نیست؛ مشکل اولویت یا اندازهٔ تغییر است.

جمع‌بندی برای تصمیم

Pull Request و Merge Request دو نام برای یک الگوی همکاری‌اند: پیشنهاد ادغام همراه با زمینه، Review و معمولاً بررسی خودکار. GitHub واژهٔ PR را رایج کرده؛ GitLab واژهٔ MR را. برای کار روزمره، روی کوچک بودن تغییر، وضوح توضیح، و جدی گرفتن Review تمرکز کنید — نه روی اینکه کدام مخفف «درست‌تر» است.

اگر این هفته یک عادت بسازید: هیچ تغییری به شاخهٔ اصلی بدون PR/MR نرود، مگر hotfix مستند با قواعد از پیش‌تأییدشده.

PR/MR و کیفیت محصول از دید غیرمهندس

برای مدیر محصول، PR باز یعنی کار در صف اعتبارسنجی است نه در صف فراموشی. اگر کارت Kanban روی Done می‌رود ولی PR هنوز Merge نشده، وضعیت واقعی Done نیست. هم‌تراز کردن برد کار با وضعیت PR جلوی جشن زودهنگام انتشار را می‌گیرد.

شاخص‌های ساده بدون ابزار پیچیده: تعداد PRهای بازِ قدیمی‌تر از سه روز، میانگین خطوط خالص هر PR، و درصد PRهایی که بعد از Merge باعث Hotfix شده‌اند. اگر PRها هفته‌ها باز می‌مانند، یا Scope خیلی بزرگ است یا Review گلوگاه است — ابزار GitHub یا GitLab مقصر اول نیست.

ارتباط با Issue و ردیابی کار

هم GitHub و هم GitLab تشویق می‌کنند PR یا MR را به Issue وصل کنید تا بعد از Merge، حلقهٔ کار بسته شود. این کار برای حسابرسی «این تغییر برای کدام نیاز بود؟» حیاتی است. توضیح PR باید به زبان محصول بگوید چه رفتاری عوض می‌شود، نه فقط فهرست فایل‌ها.

اگر تیم از User Story و Acceptance Criteria استفاده می‌کند، لینک آن‌ها داخل توضیح PR همان پلی است که Reviewر غیرنویسنده را سریع هم‌زمینه می‌کند. بدون این پیوند، Review به سلیقهٔ زیباشناسی سقوط می‌کند.

اندازهٔ تغییر و استراتژی Branch

PR کوچک یعنی Review واقعی ممکن است. اگر فیچر بزرگ است، آن را به چند PR پشت‌سرهم بشکنید: اول زیرساخت بی‌رفتار، بعد API، بعد UI. Draft برای نشان دادن مسیر مفید است، ولی ده Draft بدون برنامه فقط نویز نوتیفیکیشن می‌سازد.

Branch بلندعمر که هر روز از main عقب می‌افتد هزینهٔ Merge را تصاعدی می‌کند. ادغام مکرر از main به Topic Branch، یا کوتاه‌کردن عمر Branch، بخشی از بهداشت PR است — نه وسواس Git.

اتوماسیون کنار انسان

Checks سبز به‌معنی درست بودن محصول نیست؛ یعنی حداقل توافق‌شدهٔ ماشین پاس شده است. تیم بالغ تست واحد، Lint و در صورت نیاز Smoke را اجباری می‌کند تا Reviewر وقتش را روی دامنه بگذارد. اگر CI قرمز را با بعداً درست می‌کنیم Merge کنید، PR به‌تدریج بی‌معنا می‌شود.

Code owners و قوانین Protected Branch تصمیم‌های سازمانی‌اند: چه کسی باید برای مسیرهای حساس Approve بدهد. این‌ها را در سند کوتاه تیمی بنویسید تا بحث هر PR تکرار نشود.

مهاجرت بین GitHub و GitLab

اگر سازمان ابزار را عوض می‌کند، بزرگ‌ترین اصطکاک واژه‌ها و عادت‌های نوتیفیکیشن است نه مفهوم. یک صفحهٔ ترجمهٔ داخلی هزینهٔ آموزش را کم می‌کند. روی قابلیت‌های منحصربه‌فرد قفل نشوید تا وقتی واقعاً به آن‌ها نیاز دارید.

از نظر امنیتی، هر دو طرف باید Secret را از تاریخچه دور نگه دارید. تعویض پلتفرم مجوز hard-code نمی‌دهد.

جمع‌بندی عملی یک‌هفته‌ای

روز اول: هیچ Merge مستقیمی به main بدون PR یا MR. روز دوم: قالب توضیح PR را با بخش چرا و چگونه تست ثابت کنید. روز سوم: یک قانون Approve برای مسیرهای حساس. روز چهارم: اندازهٔ متوسط PR را اندازه بگیرید و هدف کاهش بگذارید. این‌ها بیشتر از بحث بی‌پایان روی نام PR در برابر MR ارزش دارند.

منابع و مراجع

• GitHub Docs — About pull requests — https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests
• GitHub Docs — About pull request reviews — https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews
• GitLab Docs — Merge requests — https://docs.gitlab.com/user/project/merge_requests/

برای عمق بیشتر روی کیفیت بررسی، مقالهٔ Code Review را بلافاصله بعد از این صفحه بخوانید.