نام (NAME)

git-merge - ادغام دو یا چند تاریخچه توسعه با یکدیگر

خلاصه دستور (SYNOPSIS)

git merge [-n] [--stat] [--compact-summary] [--no-commit] [--squash] [--[no-]edit]
        [--no-verify] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]]
        [--[no-]allow-unrelated-histories]
        [--[no-]rerere-autoupdate] [-m <msg>] [-F <file>]
        [--into-name <branch>] [<commit>...]
git merge (--continue | --abort | --quit)

توضیحات (DESCRIPTION)

تغییرات مربوط به کامیت‌های نام‌برده‌شده (از زمانی که تاریخچه آن‌ها از شاخه جاری منشعب شد) را در شاخه جاری ادغام می‌کند. این دستور توسط git pull برای اعمال تغییرات از یک مخزن دیگر استفاده می‌شود و همچنین می‌توان از آن به‌صورت دستی برای ادغام تغییرات از یک شاخه به شاخه دیگر استفاده کرد.

فرض کنید تاریخچه زیر وجود دارد و شاخه جاری master است:

      A---B---C topic
     /
D---E---F---G master

سپس دستور git merge topic تغییرات ایجادشده در شاخه topic از زمان انشعاب آن از master (یعنی E) تا کامیت جاری آن (C) را بر روی master بازپخش می‌کند و نتیجه را در یک کامیت جدید به همراه نام دو کامیت والد و یک پیام گزارش از کاربر که تغییرات را توصیف می‌کند ثبت می‌نماید. پیش از این عملیات، ORIG_HEAD روی نوک شاخه جاری (G) تنظیم می‌شود.

      A---B---C topic
     /         \
D---E---F---G---H master

اگر تعارضی وجود داشته باشد که نتوان آن را به‌صورت خودکار حل‌وفصل کرد یا اگر هنگام آغاز ادغام گزینه --no-commit مشخص شده باشد، عملیات ادغام متوقف می‌شود. در آن نقطه می‌توانید git merge --abort یا git merge --continue را اجرا کنید.

دستور git merge --abort فرایند ادغام را لغو کرده و تلاش می‌کند وضعیت پیش از ادغام را بازسازی کند. با این حال، اگر هنگام آغاز ادغام تغییرات ثبت‌نشده‌ای وجود داشته باشد (و به‌ویژه اگر آن تغییرات پس از آغاز ادغام بیشتر دستکاری شده باشند)، در برخی موارد git merge --abort قادر به بازسازی تغییرات اولیه (پیش از ادغام) نخواهد بود. بنابراین:

گزینه‌ها (OPTIONS)

--commit, --no-commit

--edit, -e, --no-edit

--cleanup=<mode>

--ff, --no-ff, --ff-only

-S[<key-id>], --gpg-sign[=<key-id>], --no-gpg-sign

--log[=<n>], --no-log

--signoff, --no-signoff

--stat, -n, --no-stat

--compact-summary

--squash, --no-squash

--verify, --no-verify

-s <strategy>, --strategy=<strategy>

-X <option>, --strategy-option=<option>

--verify-signatures, --no-verify-signatures

--summary, --no-summary

-q, --quiet

-v, --verbose

--progress, --no-progress

--autostash, --no-autostash

--allow-unrelated-histories

-m <msg>

--into-name <branch>

-F <file>, --file=<file>

--rerere-autoupdate, --no-rerere-autoupdate

--overwrite-ignore, --no-overwrite-ignore

--abort

--quit

--continue

<commit>...

پیش‌درآمد (PRE-MERGE CHECKS)

پیش از اعمال تغییرات بیرونی، باید کارهای خود را در وضعیت مناسبی قرار داده و به‌صورت محلی کامیت کنید تا در صورت بروز تعارض‌ها، بازنویسی و تخریب نشوند. همچنین نگاه کنید به git-stash(1). در صورتی که تغییرات محلی کامیت‌نشده با فایل‌هایی که ممکن است نیاز به به‌روزرسانی توسط git pull/git merge داشته باشند هم‌پوشانی داشته باشند، git pull و git merge بدون انجام هیچ کاری متوقف خواهند شد.

برای جلوگیری از ثبت تغییرات نامرتبط در کامیت ادغام، اگر هرگونه تغییری نسبت به کامیت HEAD در نمایه (index) ثبت شده باشد، git pull و git merge نیز عملیات را متوقف (abort) می‌کنند. (بسته به استراتژی ادغام مورد استفاده ممکن است استثناهای محدودی برای این قاعده وجود داشته باشد، اما به‌طور کلی، ایندکس باید با HEAD مطابقت داشته باشد.)

اگر تمام کامیت‌های مشخص‌شده از قبل جزو نیاکان HEAD باشند، git merge بلافاصله با پیام "Already up to date." خارج می‌شود.

ادغام سریع (FAST-FORWARD MERGE)

اغلب سرِ شاخه فعلی، نیای کامیت مشخص‌شده است. این متداول‌ترین حالت است، به‌ویژه زمانی که از طریق git pull فراخوانی می‌شود: شما یک مخزن بالادست را دنبال می‌کنید، هیچ تغییر محلی را کامیت نکرده‌اید، و اکنون می‌خواهید به نسخه بازنگری جدیدتری از بالادست به‌روزرسانی کنید. در این حالت، نیازی به کامیت جدید برای ذخیره تاریخچه ترکیبی نیست؛ در عوض، HEAD (به همراه ایندکس) بدون ایجاد کامیت ادغام اضافی، به‌روزرسانی می‌شود تا به کامیت مشخص‌شده اشاره کند.

این رفتار را می‌توان با گزینه --no-ff غیرفعال کرد.

ادغام واقعی (TRUE MERGE)

به‌جز در حالت ادغام سریع (fast-forward، بالا را ببینید)، شاخه‌هایی که قرار است ادغام شوند باید با یک کامیت ادغام که هر دوی آن‌ها را به‌عنوان والد خود دارد، به یکدیگر متصل گردند.

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

هنگامی که نحوه یکپارچه‌سازی تغییرات مشخص و بدیهی نباشد، موارد زیر رخ می‌دهد:

اگر ادغامی را اجرا کردید که منجر به تعارض‌های پیچیده شد و می‌خواهید دوباره از نو شروع کنید، می‌توانید با استفاده از git merge --abort وضعیت را بازیابی کنید.

ادغام برچسب (MERGING TAG)

هنگام ادغام یک برچسب حاوی توضیح (annotated) (و احتمالاً امضاشده)، گیت همیشه حتی در صورت امکان‌پذیر بودن ادغام سریع، یک کامیت ادغام ایجاد می‌کند و الگوی پیام کامیت با پیام برچسب آماده می‌شود. علاوه بر این، در صورت امضاشده بودن برچسب، نتیجه بررسی امضا به‌صورت یک توضیح در الگوی پیام گزارش می‌شود. همچنین نگاه کنید به git-tag(1).

هنگامی که فقط می‌خواهید کارهای منتهی به کامیتی را که برچسب‌گذاری شده است یکپارچه کنید (مانند همگام‌سازی با یک نقطه انتشار بالادست)، ممکن است نخواهید یک کامیت ادغام غیرضروری ایجاد نمایید.

در چنین حالتی، می‌توانید پیش از ارسال برچسب به git merge، خودتان آن را «باز» (unwrap) کنید یا در صورتی که هیچ تغییر محلی ندارید گزینه --ff-only را مشخص نمایید؛ مانند:

git fetch origin
git merge v1.2.3^0
git merge --ff-only v1.2.3

حل تضادها (HOW CONFLICTS ARE PRESENTED)

در حین یک ادغام، فایل‌های درخت کاری به‌روزرسانی می‌شوند تا نتیجه ادغام را منعکس کنند. از میان تغییرات ایجادشده نسبت به نسخه نیای مشترک، تغییرات غیرهمپوشان (یعنی شما بخشی از فایل را تغییر داده‌اید در حالی که طرف دیگر آن بخش را دست‌نخورده باقی گذاشته است، یا برعکس) عیناً در نتیجه نهایی اعمال می‌شوند. با این حال، هنگامی که هر دو طرف تغییراتی در یک بخش یکسان ایجاد کرده باشند، گیت نمی‌تواند به‌صورت تصادفی یکی از طرفین را بر دیگری ترجیح دهد، و با قرار دادن کارهایی که هر دو طرف در آن بخش انجام داده‌اند، از شما می‌خواهد که آن را حل کنید.

به‌طور پیش‌فرض، گیت برای نمایش چنین قطعه متضادی از همان سبکی استفاده می‌کند که توسط برنامه "merge" از مجموعه ابزار RCS به کار می‌رود، مانند این:

Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed,
or cleanly resolved because both sides changed the same way.
<<<<<<< yours:sample.txt
Conflict resolution is hard;
let's go shopping.
=======
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.

ناحیه‌ای که یک جفت تغییر متضاد در آن رخ داده است، با نشانگرهای <<<<<<<، ======= و >>>>>>> علامت‌گذاری می‌شود. بخش پیش از ======= معمولاً سمت شماست، و بخش پس از آن معمولاً سمت طرف مقابل است.

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

می‌توان با تنظیم متغیر پیکربندی merge.conflictStyle روی diff3 یا zdiff3، از یک سبک جایگزین استفاده کرد. در سبک diff3، تضاد بالا ممکن است به این شکل باشد:

Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed,
<<<<<<< yours:sample.txt
or cleanly resolved because both sides changed the same way.
Conflict resolution is hard;
let's go shopping.
||||||| base:sample.txt
or cleanly resolved because both sides changed identically.
Conflict resolution is hard.
=======
or cleanly resolved because both sides changed the same way.
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.

در حالی که در سبک zdiff3، ممکن است به این شکل باشد:

Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed,
or cleanly resolved because both sides changed the same way.
<<<<<<< yours:sample.txt
Conflict resolution is hard;
let's go shopping.
||||||| base:sample.txt
or cleanly resolved because both sides changed identically.
Conflict resolution is hard.
=======
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.

علاوه بر نشانگرهای <<<<<<<، ======= و >>>>>>>، از نشانگر دیگری به نام ||||||| استفاده می‌کند که متن اصلی به دنبال آن می‌آید. می‌توانید متوجه شوید که نسخه اصلی تنها یک واقعیت را بیان کرده بود، و سمت شما صرفاً تسلیم آن اظهار نظر شده و دست کشیده است، در حالی که طرف مقابل تلاش کرده تا نگرش مثبت‌تری داشته باشد. گاهی اوقات با مشاهده متن اصلی می‌توانید به راه‌حل بهتری برسید.

نحوه حل تضادها (HOW TO RESOLVE CONFLICTS)

پس از مشاهده تضاد، می‌توانید دو کار انجام دهید:

می‌توانید با استفاده از ابزارهای مختلفی تضادها را حل کنید:

مثال‌ها (EXAMPLES)

$ git merge fixes enhancements

$ git merge -s ours obsolete

$ git merge --no-commit maint

راهبردهای ادغام (MERGE STRATEGIES)

سازوکار ادغام (دستورات git merge و git pull) امکان انتخاب استراتژی‌های ادغام پس‌زمینه را با گزینه -s فراهم می‌کند. برخی از استراتژی‌ها همچنین می‌توانند گزینه‌های ویژه خود را دریافت کنند که می‌توان آن‌ها را با دادن آرگومان‌های -X<option> به git merge و/یا git pull ارسال کرد.

ort

recursive

resolve

octopus

ours

subtree

در استراتژی‌هایی که از ادغام ۳-طرفه استفاده می‌کنند (از جمله گزینه پیش‌فرض، ort)، اگر تغییری در هر دو شاخه ایجاد شود اما بعداً در یکی از شاخه‌ها بازگردانی (revert) شود، آن تغییر در نتیجه ادغام وجود خواهد داشت؛ برخی این رفتار را گیج‌کننده می‌دانند. این حالت رخ می‌دهد زیرا هنگام انجام ادغام، فقط سرشاخه‌ها و پایه ادغام (merge base) در نظر گرفته می‌شوند، نه تک‌تک کامیت‌ها. بنابراین الگوریتم ادغام، تغییر بازگردانده‌شده را اصلاً به‌عنوان هیچ تغییری در نظر نمی‌گیرد و در عوض نسخه تغییریافته را جایگزین می‌کند.

پیکربندی (CONFIGURATION)

branch.<name>.mergeOptions

تمام موارد بالاتر از این خط در این بخش، از مستندات git-config(1) برگرفته نشده‌اند. محتوایی که در ادامه می‌آید همان چیزی است که در آنجا یافت می‌شود:

merge.conflictStyle

merge.defaultToUpstream

merge.ff

merge.verifySignatures

merge.branchdesc

merge.log

merge.suppressDest

merge.renameLimit

merge.renames

merge.directoryRenames

merge.renormalize

merge.stat

merge.autoStash

merge.tool

merge.guitool

merge.verbosity

merge.<driver>.name

merge.<driver>.driver

merge.<driver>.recursive

همچنین ببینید (SEE ALSO)

git-fmt-merge-msg(1), git-pull(1), gitattributes(5), git-reset(1), git-diff(1), git-ls-files(1), git-add(1), git-rm(1), git-mergetool(1)

گیت (GIT)

بخشی از مجموعه git(1)