چطور تعارض (Conflict) در Merge گیت را حل کنیم

وقتی git merge با خط CONFLICT (content): Merge conflict in ... می‌ایستد، فایل خراب نشده — گیت فقط نتوانسته خودش تصمیم بگیرد و آن را به شما سپرده. جواب کوتاه: فایل را باز کنید، بین دو نسخه انتخاب کنید، علامت‌ها را پاک کنید، git add و بعد git commit بزنید.

یک تعارض واقعی

دو شاخه، هر دو یک خط را جور دیگری عوض کرده‌اند:

bash$ git merge feature-a
Auto-merging config.yml
CONFLICT (content): Merge conflict in config.yml
Automatic merge failed; fix conflicts and then commit the result.

فایل الان چه شکلی است

yaml<<<<<<< HEAD
version: 1.5
=======
version: 2.0
>>>>>>> feature-a
name: shop

بین <<<<<<< HEAD و ======= نسخه‌ی شاخه‌ی فعلی شماست؛ بین ======= و >>>>>>> feature-a نسخه‌ی شاخه‌ای که دارید merge می‌کنید. git status هم همین را با کد UU (Unmerged, both modified) نشان می‌دهد.

حل‌کردن یعنی همین سه خط را پاک کنید

تصمیم بگیرید کدام نسخه درست است — یا حتی یک نسخه‌ی سوم بنویسید — و هر سه خط علامت را حذف کنید:

yamlversion: 2.0
name: shop

bashgit add config.yml
git commit --no-edit

بدون -m، گیت یک پیام آماده می‌گذارد: Merge branch 'feature-a'. کامیت نهایی دو والد دارد — هم آخرین کامیت شاخه‌ی شما، هم آخرین کامیت شاخه‌ی merge‌شده — و همین دو-والدی‌بودن است که در git log --graph آن الماس آشنا را می‌سازد.

اگر وسط راه پشیمان شدید

bashgit merge --abort

فایل‌ها را دقیقاً به حالت قبل از شروع merge برمی‌گرداند — انگار هیچ‌وقت merge نزده بودید. تا وقتی commit نهایی را نزده‌اید، این دستور همیشه در دسترس است؛ نگران خراب‌کردن چیزی نباشید.

چند فایل تعارض دارند؟

bashgit status --porcelain | grep '^UU'

هر خطی که با UU شروع شود، هنوز حل نشده. تا این لیست خالی نشود، git commit اصلاً اجازه نمی‌دهد.

اگر می‌دانید کدام نسخه باید کامل برنده شود

گاهی نیازی به ادیت دستی نیست — می‌خواهید یک طرف کامل جای‌گزین شود:

bashgit checkout --theirs config.yml   # نسخه‌ی شاخه‌ای که merge می‌کنید
git checkout --ours config.yml     # نسخه‌ی شاخه‌ی خودتان
git add config.yml

روی همان تعارض بالا، --theirs نسخه‌ی feature-a (یعنی version: 2.0) را کامل جای‌گزین کرد — بدون باز کردن فایل و پاک‌کردن علامت‌ها. برای فایل‌های باینری (مثلاً یک تصویر) که اصلاً نمی‌شود «ادیت دستی» کرد، این تنها راه است.

اگر با کار تیمی روی گیت‌هاب — شاخه‌زدن، pull request، حل تعارض روی پروژه‌ی واقعی — تازه‌کارید، دوره‌ی گیت و گیت‌هاب دقیقاً همین سناریو را چند بار زیر دستتان تمرین می‌دهد.