مقدمه
تاکنون چرخه کامل کار روی یک برنچ ایزوله و بحث و بازبینی آن در یک Pull Request را یاد
گرفته‌ایم. آخرین و رضایت‌بخش‌ترین مرحله این چرخه، بازگرداندن تغییرات تکمیل‌شده به خط اصلی توسعه
است. این فرآیند ادغام یا Merge نام دارد.
ادغام، عمل ترکیب تاریخچه‌های مستقل دو برنچ و ایجاد یک تاریخچه واحد و یکپارچه است. در جریان کاری
گیت‌هاب، این عمل تقریباً همیشه با کلیک روی دکمه سبز رنگ «Merge pull request» انجام می‌شود. اما
گیت‌هاب گزینه‌های مختلفی برای نحوه انجام این ادغام در اختیار شما قرار می‌دهد که هر کدام مزایا و
معایب خود را دارند.
گزینه‌های ادغام در گیت‌هاب
وقتی آماده ادغام یک Pull Request هستید، گیت‌هاب معمولاً سه استراتژی اصلی را به شما
پیشنهاد می‌دهد. انتخاب بین این گزینه‌ها به سیاست و ترجیحات تیم شما بستگی دارد.
۱. ایجاد یک کامیت ادغام (Create a Merge Commit)
این گزینه پیش‌فرض و رایج‌ترین استراتژی است. در این روش، گیت تمام کامیت‌های موجود در برنچ شما را
گرفته و آن‌ها را با یک کامیت جدید و ویژه به نام «کامیت ادغام» (Merge
Commit) به برنچ اصلی متصل می‌کند. این کامیت ادغام دو والد دارد: آخرین کامیت برنچ اصلی و
آخرین کامیت برنچ شما.
- مزایا: این روش تمام تاریخچه برنچ شما را به طور کامل و دست‌نخورده حفظ
می‌کند. با نگاه به گراف تاریخچه، به وضوح می‌توان دید که یک برنچ چه زمانی جدا شده و چه زمانی
دوباره ادغام شده است. این قابلیت ردیابی عالی است.
- معایب: در پروژه‌های بزرگ با فعالیت زیاد، این روش می‌تواند منجر به یک تاریخچه گراف
بسیار شلوغ و پر از شاخه‌های متقاطع شود که خوانایی آن در نگاه اول دشوار است.
۲. ادغام فشرده (Squash and Merge)
این استراتژی، تمام کامیت‌های ریز و درشت برنچ شما (مانند «work in progress»، «fix typo» و...) را
برداشته و همه آن‌ها را در یک کامیت واحد و تمیز فشرده می‌کند. سپس فقط همین یک
کامیت به برنچ اصلی اضافه می‌شود. گیت‌هاب به شما اجازه می‌دهد تا پیام این کامیت نهایی را قبل از
ادغام ویرایش کنید.
- مزایا: این روش یک تاریخچه بسیار تمیز و خطی برای برنچ اصلی ایجاد
می‌کند. تاریخچه شما به لیستی خوانا از قابلیت‌ها و اصلاحات تبدیل می‌شود، نه مجموعه‌ای از
کامیت‌های کاری کوچک.
- معایب: شما جزئیات و تاریخچه مرحله به مرحله توسعه آن قابلیت را از دست می‌دهید. تمام
کامیت‌های میانی حذف می‌شوند.
۳. ادغام با Rebase (Rebase and Merge)
این روش پیشرفته‌ترین و شاید تمیزترین نتیجه را دارد. در این استراتژی، گیت تمام کامیت‌های برنچ شما
را برداشته و آن‌ها را یک به یک روی آخرین نسخه برنچ اصلی «بازپخش» (Replay) می‌کند. در
نتیجه، به نظر می‌رسد که تمام کار شما پس از آخرین تغییرات برنچ اصلی انجام شده است. سپس اشاره‌گر
برنچ اصلی به جلو حرکت می‌کند تا این کامیت‌ها را شامل شود، بدون اینکه هیچ کامیت ادغامی ایجاد شود.
- مزایا: این روش یک تاریخچه کاملاً خطی و بدون هیچ شاخه اضافی ایجاد
می‌کند. انگار تمام توسعه پروژه در یک خط مستقیم اتفاق افتاده است.
- معایب: این عمل تاریخچه کامیت‌های برنچ شما را بازنویسی می‌کند (هش
آن‌ها تغییر می‌کند) که می‌تواند کمی گیج‌کننده باشد. همچنین درک اینکه یک مجموعه از کامیت‌ها
در ابتدا به کدام برنچ تعلق داشته‌اند، دشوارتر می‌شود.
کدام روش را انتخاب کنیم؟
هیچ پاسخ واحدی برای این سوال وجود ندارد و انتخاب آن کاملاً به فرهنگ تیم شما بستگی دارد.
- Merge Commit: برای تیم‌هایی که می‌خواهند تاریخچه دقیق و کامل هر برنچ را حفظ کنند
(بسیاری از پروژه‌های متن‌باز از این روش استفاده می‌کنند).
- Squash and Merge: گزینه‌ای بسیار محبوب برای تیم‌هایی که خوانایی و تمیزی تاریخچه برنچ
اصلی را به جزئیات برنچ‌های کاری ترجیح می‌دهند.
- Rebase and Merge: برای تیم‌هایی که به داشتن یک تاریخچه کاملاً خطی وسواس دارند و با
مفهوم rebase راحت هستند.
اما گاهی اوقات، گیت نمی‌تواند این ادغام را به صورت خودکار انجام دهد. اینجاست که با یکی از
ترسناک‌ترین مفاهیم برای تازه‌کاران روبرو می‌شویم: تداخل در ادغام، که موضوع درس بعدی ماست.