مقدمه
تاکنون بارها به اصطلاح Pull Request یا به اختصار PR اشاره
کرده‌ایم. اکنون زمان آن رسیده که به صورت عمیق به این مفهوم کلیدی بپردازیم. Pull Request
یک دستور گیت نیست؛ بلکه یک ویژگی و ابداع درخشان از پلتفرم گیت‌هاب (و پلتفرم‌های مشابه) است که
قلب تپنده همکاری تیمی در توسعه نرم‌افزار مدرن محسوب می‌شود.
به زبان ساده، یک Pull Request یک درخواست رسمی برای ادغام کردن تغییرات از
یک برنچ به برنچ دیگر است. شما به نگهدارندگان پروژه می‌گویید: «من این تغییرات را انجام داده‌ام،
لطفاً آن‌ها را بررسی کرده و در صورت تایید، به پروژه اصلی Pull (بکشید) و اضافه
کنید».
یک Pull Request واقعاً چیست؟
یک PR بسیار فراتر از یک درخواست ادغام ساده است. این یک فضای گفتگوی
اختصاصی برای مجموعه‌ای از تغییرات پیشنهادی است. وقتی شما یک PR باز می‌کنید،
گیت‌هاب یک صفحه وب ایجاد می‌کند که در آن می‌توانید:
- تغییرات را به صورت بصری و خط به خط مقایسه کنید (diff).
- در مورد کلیت تغییرات پیشنهادی بحث و گفتگو کنید.
- روی خطوط خاصی از کد کامنت بگذارید و آن را بازبینی (review) کنید.
- وضعیت بررسی‌های خودکار (مانند تست‌ها) را مشاهده نمایید.
هدف از Pull Request چیست؟
استفاده از PRها چندین هدف مهم را دنبال می‌کند که همگی به بهبود کیفیت نهایی نرم‌افزار کمک
می‌کنند.
بهبود کیفیت کد از طریق بازبینی (Code Review)
هدف اصلی یک PR، بازبینی کد است. اینکه یک نفر دیگر از اعضای تیم کد شما را قبل از ادغام شدن
بررسی کند، یکی از بهترین راه‌ها برای پیدا کردن باگ‌ها، مشکلات معماری، و اطمینان از رعایت
استانداردهای کدنویسی تیم است. این کار از ورود کد بی‌کیفیت یا مشکل‌دار به برنچ اصلی جلوگیری
می‌کند.
اشتراک‌گذاری دانش در تیم
وقتی اعضای تیم کد یکدیگر را بازبینی می‌کنند، با بخش‌های مختلف پروژه آشناتر می‌شوند.
توسعه‌دهندگان تازه‌کار از باتجربه‌ها یاد می‌گیرند و توسعه‌دهندگان باتجربه نیز ممکن است
دیدگاه‌های جدیدی دریافت کنند. این فرآیند به طور طبیعی دانش را در سراسر تیم پخش می‌کند و از ایجاد
«سیلوهای دانش» (جایی که فقط یک نفر از یک بخش کد سر در می‌آورد) جلوگیری می‌کند.
ایجاد یک سند تاریخی
یک Pull Request پس از بسته شدن، به یک سند تاریخی ارزشمند تبدیل می‌شود. توضیحات، گفتگوها،
کامنت‌های بازبینی و تصمیمات گرفته شده در آن، همگی ثبت می‌شوند و به روشنی نشان می‌دهند که یک
تغییر چرا و چگونه انجام شده است.
چرخه حیات یک Pull Request معمولی
یک PR معمولاً چرخه زیر را طی می‌کند:
- یک توسعه‌دهنده پس از push کردن برنچ خود، یک PR جدید باز می‌کند.
- یک یا چند نفر از هم‌تیمی‌ها به عنوان بازبین (Reviewer) تعیین می‌شوند.
- بازبین‌ها کد را بررسی کرده و کامنت‌ها یا درخواست‌های تغییر خود را ثبت می‌کنند.
- توسعه‌دهنده اصلی تغییرات درخواستی را روی همان برنچ اعمال کرده و دوباره push می‌کند
(PR به صورت خودکار به‌روز می‌شود).
- این چرخه بحث و اصلاح تا زمانی که همه از نتیجه راضی باشند، ادامه می‌یابد.
- PR یک یا چند تاییدیه (Approval) دریافت می‌کند.
- پس از تایید و پاس شدن تمام تست‌های خودکار، PR در برنچ مقصد ادغام (Merge)
می‌شود.
- معمولاً پس از ادغام، برنچ کاری حذف می‌شود تا مخزن تمیز بماند.