در اغلب پروژه‌های تیمی، برنچ اصلی (معمولاً master یا main) هسته اصلی توسعه محسوب می‌شود و برای جلوگیری از خطاهای ناخواسته باید روی آن محدودیت‌هایی اعمال شود. در حالتی که هیچگونه محافظتی برای این برنچ فعال نشده باشد، هر یک از اعضای تیم می‌توانند بدون هیچ کنترلی مستقیم روی آن Push یا Merge انجام دهند، حتی بدون استفاده از Pull Request. علاوه بر این، امکان حذف برنچ‌ها یا ایجاد تغییرات ناخواسته نیز وجود دارد.
در پروژه‌های کوچک و خصوصی که تعداد اعضای تیم کم است شاید در ابتدا مشکلی دیده نشود، اما با افزایش تعداد اعضا احتمال بروز خطا و ایجاد دردسر بسیار بیشتر خواهد شد. بنابراین استفاده از قابلیت Branch Protection در گیت‌هاب یکی از اقدامات ضروری برای مدیریت صحیح پروژه است.
دسترسی اعضای تیم
در پروژه‌های Private فقط اعضای تیم امکان دسترسی و ایجاد تغییرات را دارند، اما همین افراد نیز می‌توانند به صورت ناخواسته یا اشتباهی روی برنچ‌های اصلی Push یا Merge انجام دهند. بنابراین بهتر است از ابتدا محدودیت‌هایی برای برنچ‌های حساس ایجاد شود تا عملیات مهم فقط از طریق PR و تأیید اعضا انجام شود
قابلیت Branch Protection در گیت‌هاب
گیت‌هاب این امکان را فراهم کرده که برای هر برنچ قوانین محافظتی تعریف کنید. این قوانین می‌توانند شامل موارد مختلفی مانند محدودسازی مرج فقط از طریق Pull Request یا الزام دریافت تأیید از اعضای تیم باشند.
برای تنظیم این قابلیت باید وارد بخش Settings ریپازیتوری شوید و سپس از قسمت Branches گزینه‌های مربوط به Branch Protection را مشاهده کنید.
در این بخش پیغامی نمایش داده می‌شود مبنی بر اینکه تاکنون هیچ گونه محافظتی برای برنچ‌های این ریپازیتوری فعال نشده است.
گیت‌هاب برای اعمال محافظت از برنچ‌ها دو روش ارائه کرده است:
۱. روش کلاسیک (Classic)
این روش از نسخه‌های قدیمی گیت‌هاب باقی مانده و تنظیمات ساده‌تری دارد. پس از انتخاب این روش، برنچ موردنظر (مثلاً master) انتخاب می‌شود و سپس می‌توان محدودیت‌های موردنظر را فعال کرد.
یکی از مهم‌ترین گزینه‌ها در این بخش مربوط به الزام استفاده از Pull Request برای انجام Merge است. با فعال‌سازی این گزینه، هیچ‌کس نمی‌تواند بدون ارسال Pull Request و طی شدن مراحل بررسی و تأیید، کُدی را روی برنچ اصلی مرج کند.
در ادامه می‌توان مشخص کرد چه تعداد از اعضای تیم باید Pull Request را تأیید (Approve) کنند تا امکان Merge وجود داشته باشد. معمولاً در پروژه‌های اپن‌سورس یا تیم‌های بزرگ تعداد این تأییدکننده‌ها بیشتر تعیین می‌شود، اما بسته به اندازه تیم قابل تنظیم است.
۲. روش جدید (New Rules)
در روش جدید امکانات بیشتری ارائه شده است. هنگام ایجاد Rule می‌توانید نام برنچ هدف را مشخص کنید و گزینه‌های متعددی از جمله موارد زیر را فعال کنید:
الزام Merge فقط از طریق Pull Request
تعداد تأییدکنندگان (Approvers)
اجازه یا عدم اجازه برای Bypass توسط Admin
سایر تنظیمات کنترلی و امنیتی
محدودیت استفاده در پروژه‌های Private
یک نکته بسیار مهم این است که برخی از این تنظیمات فقط در صورت استفاده از پلن Team یا Enterprise در گیت‌هاب قابل‌اعمال هستند. در پروژه‌های خصوصی (Private) اگر روی اکانت رایگان باشید، پس از ایجاد Rule پیغامی نمایش داده می‌شود که می‌گوید:
این تنظیمات تنها در صورتی اعمال می‌شوند که پلن شما به حالت Team یا Enterprise ارتقا داده شود.
پلن Team در حال حاضر هزینه‌ای حدود ۴ دلار در ماه دارد و برای فعال کردن این امکانات روی ریپازیتوری‌های خصوصی لازم است.
برای پرداخت این مبالغ می‌توانید از روش‌های مختلف مانند خرید کارت‌های اعتباری بین‌المللی، استفاده از سایت‌های پرداخت ارزی یا سپردن اطلاعات اکانت گیت‌هاب به شرکت‌های واسطه مثل ایرانی‌کارت استفاده کنید.
تبدیل پروژه Private به Public برای فعال شدن تنظیمات
اگر ریپازیتوری شما Public باشد، محدودیتی برای استفاده از Branch Protection وجود ندارد و Ruleهای ایجادشده بلافاصله فعال می‌شوند. بنابراین اگر پروژه برای‌تان اپن‌سورس بودن مشکلی ایجاد نمی‌کند، می‌توانید از قسمت Settings ریپازیتوری را به حالت Public تغییر دهید و از امکانات محافظت بدون نیاز به ارتقای پلن استفاده کنید.
پس از پابلیک شدن ریپازیتوری، تنظیماتی که قبلاً ایجاد کرده‌اید فعال خواهند شد و برنچ موردنظر تحت حفاظت قرار می‌گیرد.
نتیجه‌گیری:
برای استفاده از قابلیت‌های پیشرفته محافظت از برنچ برای پروژه‌های Private، ساده‌ترین راه تهیه اشتراک Team گیت‌هاب با هزینه ماهانه ۴ دلار است. اگرچه ترفندهایی برای جلوگیری از مرج شدن بدون PR خارج از گیت‌هاب نیز وجود دارد، اما دردسرهای زیادی دارد و راه‌حل رسمی و ساده‌تر همان خرید اشتراک است.
برای افزودن دیدگاه خود، نیاز است ابتدا وارد حساب کاربری‌تان شوید