ادغام شاخه‌ها — چیست، روش‌های ادغام و حل تعارضات

مرج در Git چیست

مرج در Git — عملیات ترکیب دو یا چند تاریخچه توسعه در یک تاریخچه است. وقتی یک برنامه‌نویس شاخه‌ای را ادغام می‌کند، Git به طور خودکار جد مشترک (base commit) را پیدا می‌کند و یک کامیت ادغام جدید ایجاد می‌کند که شامل تغییرات هر دو شاخه است. Three-way merge — الگوریتم استانداردی که سه حالت را مقایسه می‌کند: جد مشترک، شاخه اول و شاخه دوم.

فرآیند مرج با دستور git merge شروع می‌شود. Git نقطه انشعاب شاخه‌ها را تعیین می‌کند و تغییرات را از شاخه مبدأ به شاخه مقصد به ترتیب اعمال می‌کند. اگر تغییرات تضاد نداشته باشند، Git با توجه به تنظیمات fast-forward را اجرا می‌کند یا یک merge commit ایجاد می‌کند. Fast-forward — سناریویی که در آن شاخه مقصد به سادگی به کامیت‌های شاخه مبدأ منتقل می‌شود.

# به شاخه مقصد سوئیچ کن و ادغام کن
git checkout main
git merge feature/payment-module

# ادغام با no-fast-forward صریح
git merge --no-ff feature/payment-module

# در صورت پیچیدگی بیش از حد تعارضات، ادغام را لغو کن
git merge --abort

پرچم --no-ff (no fast-forward) حتی زمانی که fast-forward ممکن است، به اجبار یک merge commit ایجاد می‌کند. این کار اطلاعات مربوط به انجام تغییرات در یک شاخه جداگانه را حفظ می‌کند. بسیاری از تیم‌ها این رویکرد را برای حفظ انشعاب تاریخچه به صورت آشکار ترجیح می‌دهند.

روش‌های ادغام شاخه‌ها

در Git سه استراتژی اصلی برای ادغام شاخه‌ها وجود دارد که هر کدام برای سناریوی خاصی مناسب هستند. انتخاب استراتژی به فرهنگ تیم و الزامات مربوط به تمیزی تاریخچه پروژه بستگی دارد.

Standard merge یک merge commit با دو والد ایجاد می‌کند. تاریخچه کامل حفظ می‌شود، اما گراف انشعاب پیچیده‌تر می‌شود. Squash merge تمام کامیت‌های شاخه feature را در یک کامیت ترکیب می‌کند و آن را روی شاخه مقصد اعمال می‌کند — تاریخچه خطی و تمیز می‌شود، اما اطلاعات مربوط به مراحل میانی از بین می‌رود.

Rebase، اگرچه یک ادغام کامل نیست، به همان نتیجه می‌رسد — تغییرات از یک شاخه به شاخه دیگر منتقل می‌شوند. تفاوت در این است که تاریخچه بازنویسی می‌شود: کامیت‌های شاخه feature روی آخرین کامیت شاخه مقصد از نو ایجاد می‌شوند. این یک تاریخچه کاملاً خطی ایجاد می‌کند، اما هنگام ارسال نیاز به force push دارد.

چگونه تعارضات را هنگام مرج حل کنیم

تعارض هنگام مرج زمانی رخ می‌دهد که در دو شاخه خطوط یکسانی از یک فایل تغییر کرده باشند. Git نمی‌تواند به طور خودکار تعیین کند کدام نسخه را حفظ کند و نیاز به دخالت برنامه‌نویس دارد. تعارضات در فایل‌ها به صورت نشانگرهای ویژه نمایش داده می‌شوند: <<<<<<<, =======, >>>>>>>.

فرآیند حل تعارض شامل چند مرحله است. ابتدا برنامه‌نویس فایل دارای تعارض را باز می‌کند و به صورت دستی تغییرات مورد نظر را انتخاب می‌کند. مهم است که فقط یکی از نسخه‌ها را انتخاب نکنید، بلکه منطق هر دو تغییر را درک کنید و تصمیم درستی بگیرید. پس از ویرایش فایل، نشانگرهای تعارض حذف می‌شوند و تغییرات از طریق git add به staging area اضافه می‌شوند.

# مشاهده لیست فایل‌های دارای تعارض
git status

# راه‌اندازی mergetool (مثلاً VS Code, IntelliJ)
git mergetool

# پس از حل تمام تعارضات
git add .
git merge --continue

# یا ادغام را به طور کامل لغو کن
git merge --abort

استفاده از ابزارهای بصری merge به طور قابل توجهی حل تعارضات را سرعت می‌بخشد. VS Code، IntelliJ IDEA و GitKraken رابط‌هایی با سه پنل ارائه می‌دهند: شاخه فعلی، شاخه ورودی و نتیجه. ابزار git mergetool به طور خودکار ویرایشگر پیکربندی شده را برای هر فایل دارای تعارض باز می‌کند.

بهترین راه برای جلوگیری از تعارضات پیچیده، همگام‌سازی منظم شاخه feature با شاخه اصلی است. اگر برنامه‌نویس روزی یک بار main را با شاخه خود ادغام کند، تعارضات کوچک و به راحتی قابل حل خواهند بود. انباشت تغییرات به مدت یک هفته، تعارضات پیچیده با خطر بالای خطا را تضمین می‌کند.

کی به جای merge از rebase استفاده کنیم

Rebase و merge — دو روش ترکیب تغییرات هستند و انتخاب بین آنها اغلب در تیم‌ها بحث‌برانگیز است. Rebase کامیت‌ها را از یک شاخه به شاخه دیگر منتقل کرده و تاریخچه را بازنویسی می‌کند. Merge یک کامیت ادغام جدید ایجاد کرده و تاریخچه انشعاب را حفظ می‌کند. هر رویکرد مزایا و محدودیت‌های خود را دارد.

Rebase زمانی مناسب است که برنامه‌نویس در شاخه feature محلی خود کار می‌کند و می‌خواهد قبل از ایجاد Pull Request یک تاریخچه خطی تمیز داشته باشد. پس از rebase، تمام کامیت‌ها به صورت متوالی و بدون merge commit اضافی مرتب می‌شوند. با این حال، rebase نیاز به force push دارد و در شاخه‌هایی که چند نفر همزمان روی آنها کار می‌کنند قابل استفاده نیست.

• Rebase — برای شاخه‌های شخصی feature که نیاز به تاریخچه تمیز دارند
• Merge — برای شاخه‌های مشترک و ثبت لحظه ادغام
• Squash — زمانی که شاخه feature شامل کامیت‌های کوچک کاری متعدد است

قاعده طلایی Git: از rebase روی کامیت‌هایی که قبلاً به مخزن مشترک ارسال شده‌اند استفاده نکنید. این تضمین می‌کند که تاریخچه در شاخه مشترک بدون تغییر باقی می‌ماند و سایر برنامه‌نویسان با کامیت‌های تکراری یا از دست رفته مواجه نخواهند شد. برای ادغام شاخه feature در شاخه اصلی از merge از طریق Pull Request استفاده کنید.

بهترین روش‌های ادغام شاخه‌ها

فرآیند صحیح مرج — اساس توسعه پایدار است. در کار تیمی مدرن، مرج نه از طریق کنسول، بلکه از طریق Pull Request در GitHub یا Merge Request در GitLab انجام می‌شود. PR از بازبینی کد، بررسی‌های خودکار CI عبور می‌کند و تنها پس از آن در شاخه اصلی ادغام می‌شود.

روش اول — فقط پس از گذراندن تمام بررسی‌ها ادغام کنید. CI pipeline باید پروژه را بسازد، تست‌ها را اجرا کند و کیفیت کد را بررسی کند. اگر حتی یک بررسی ناموفق باشد، مرج مسدود می‌شود. پلتفرم‌های مدرن (GitHub, GitLab) دارای حفاظت داخلی هستند: branch protection rules به طور خودکار مرج را در صورت شکست CI مسدود می‌کنند.

روش دوم — هرگز کد خراب را ادغام نکنید. قبل از مرج، برنامه‌نویس باید مطمئن شود که تغییراتش build را خراب نمی‌کند و عملکرد موجود را پسرفت نمی‌دهد. برای این کار تست‌های خودکار و بازبینی کد وجود دارند.

روش سوم — پس از مرج، شاخه‌های feature را پاک کنید. شاخه‌ای که قبلاً ادغام شده باید حذف شود. این کار از سردرگمی و به هم ریختگی مخزن جلوگیری می‌کند. GitHub به طور خودکار پس از مرج PR حذف شاخه را پیشنهاد می‌کند و تنظیمات مخزن را می‌توان برای حذف خودکار پیکربندی کرد.