'\" t
.\" Title: git-merge
.\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
.\" Generator: DocBook XSL Stylesheets vsnapshot \fR] [\fB\-X\fR \fI\fR] [\fB\-S\fR[\fI\fR]]
[\fB\-\-\fR[\fBno\-\fR]\fBallow\-unrelated\-histories\fR]
[\fB\-\-\fR[\fBno\-\fR]\fBrerere\-autoupdate\fR] [\fB\-m\fR \fI\fR] [\fB\-F\fR \fI\fR]
[\fB\-\-into\-name\fR \fI\fR] [\fI\fR\&...]
\fBgit\fR \fBmerge\fR (\fB\-\-continue\fR | \fB\-\-abort\fR | \fB\-\-quit\fR)
.fi
.sp
.SH "توضیحات (DESCRIPTION)"
.sp
تغییرات مربوط به کامیت‌های نام‌برده‌شده (از زمانی که تاریخچه آن‌ها از شاخه جاری منشعب شد) را در شاخه جاری ادغام می‌کند\&. این دستور توسط \fBgit\fR \fBpull\fR برای اعمال تغییرات از یک مخزن دیگر استفاده می‌شود و همچنین می‌توان از آن به‌صورت دستی برای ادغام تغییرات از یک شاخه به شاخه دیگر استفاده کرد\&.
.sp
فرض کنید تاریخچه زیر وجود دارد و شاخه جاری \fBmaster\fR است:
.sp
.if n \{\
.RS 4
.\}
.nf
A\-\-\-B\-\-\-C topic
/
D\-\-\-E\-\-\-F\-\-\-G master
.fi
.if n \{\
.RE
.\}
.sp
.sp
سپس دستور \fBgit\fR \fBmerge\fR \fBtopic\fR تغییرات ایجادشده در شاخه \fBtopic\fR از زمان انشعاب آن از \fBmaster\fR (یعنی \fBE\fR) تا کامیت جاری آن (\fBC\fR) را بر روی \fBmaster\fR بازپخش می‌کند و نتیجه را در یک کامیت جدید به همراه نام دو کامیت والد و یک پیام گزارش از کاربر که تغییرات را توصیف می‌کند ثبت می‌نماید\&. پیش از این عملیات، \fBORIG_HEAD\fR روی نوک شاخه جاری (\fBG\fR) تنظیم می‌شود\&.
.sp
.if n \{\
.RS 4
.\}
.nf
A\-\-\-B\-\-\-C topic
/ \e
D\-\-\-E\-\-\-F\-\-\-G\-\-\-H master
.fi
.if n \{\
.RE
.\}
.sp
.sp
اگر تعارضی وجود داشته باشد که نتوان آن را به‌صورت خودکار حل‌وفصل کرد یا اگر هنگام آغاز ادغام گزینه \fB\-\-no\-commit\fR مشخص شده باشد، عملیات ادغام متوقف می‌شود\&. در آن نقطه می‌توانید \fBgit\fR \fBmerge\fR \fB\-\-abort\fR یا \fBgit\fR \fBmerge\fR \fB\-\-continue\fR را اجرا کنید\&.
.sp
دستور \fBgit\fR \fBmerge\fR \fB\-\-abort\fR فرایند ادغام را لغو کرده و تلاش می‌کند وضعیت پیش از ادغام را بازسازی کند\&. با این حال، اگر هنگام آغاز ادغام تغییرات ثبت‌نشده‌ای وجود داشته باشد (و به‌ویژه اگر آن تغییرات پس از آغاز ادغام بیشتر دستکاری شده باشند)، در برخی موارد \fBgit\fR \fBmerge\fR \fB\-\-abort\fR قادر به بازسازی تغییرات اولیه (پیش از ادغام) نخواهد بود\&. بنابراین:
.if n \{\
.sp
.\}
.RS 4
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
.ps +1
\fBهشدار\fR
.ps -1
.br
.sp
اجرای \fBgit\fR \fBmerge\fR همراه با تغییرات ثبت‌نشدهٔ مهم توصیه نمی‌شود: هرچند این کار امکان‌پذیر است، اما در صورت بروز تعارض ممکن است شما را در وضعیتی قرار دهد که بازگشت از آن دشوار باشد\&.
.sp .5v
.RE
.SH "گزینه‌ها (OPTIONS)"
.PP
\fB\-\-commit\fR, \fB\-\-no\-commit\fR
.RS 4
ادغام را انجام داده و نتیجه را کامیت می‌کند\&. از این گزینه می‌توان برای لغو اثر
\fB\-\-no\-commit\fR
استفاده کرد\&.
.sp
با
\fB\-\-no\-commit\fR
ادغام را انجام داده و درست پیش از ایجاد کامیت ادغام متوقف می‌شود، تا به کاربر فرصت بازبینی و اصلاح بیشتر نتیجه ادغام پیش از کامیت کردن داده شود\&.
.sp
توجه داشته باشید که به‌روزرسانی‌های فست‌فوروارد (fast\-forward) کامیت ادغام ایجاد نمی‌کنند و بنابراین راهی برای متوقف کردن این ادغام‌ها با
\fB\-\-no\-commit\fR
وجود ندارد\&. از این رو، اگر می‌خواهید مطمئن شوید که شاخه شما توسط دستور ادغام تغییر نکرده یا به‌روزرسانی نمی‌شود، از
\fB\-\-no\-ff\fR
همراه با
\fB\-\-no\-commit\fR
استفاده کنید\&.
.RE
.PP
\fB\-\-edit\fR, \fB\-e\fR, \fB\-\-no\-edit\fR
.RS 4
پیش از کامیت کردن یک ادغام مکانیکی موفق، ویرایشگری را فراخوانی می‌کند تا پیام ادغام تولیدشده به‌طور خودکار ویرایش شود، تا کاربر بتواند ادغام را توضیح داده و توجیه کند\&. گزینه
\fB\-\-no\-edit\fR
می‌تواند برای پذیرش پیام تولیدشده به‌طور خودکار استفاده شود (این کار عموماً توصیه نمی‌شود)\&. گزینه
\fB\-\-edit\fR
(یا
\fB\-e\fR)
همچنان زمانی کاربرد دارد که یک پیام پیش‌نویس را با گزینه
\fB\-m\fR
از خط فرمان داده باشید و بخواهید آن را در ویرایشگر ویرایش کنید\&.
.sp
اسکریپت‌های قدیمی‌تر ممکن است به رفتار تاریخی عدم اجازه به کاربر برای ویرایش پیام لاگ ادغام وابسته باشند\&. آن‌ها هنگام اجرای
\fBgit\fR
\fBmerge\fR
باز شدن یک ویرایشگر را مشاهده خواهند کرد\&. برای آسان‌تر کردن تطبیق چنین اسکریپت‌هایی با رفتار به‌روزرسانی‌شده، متغیر محیطی
\fBGIT_MERGE_AUTOEDIT\fR
می‌تواند در ابتدای آن‌ها روی
\fBno\fR
تنظیم شود\&.
.RE
.PP
\fB\-\-cleanup=\fR\fI\fR
.RS 4
این گزینه تعیین می‌کند که پیام ادغام پیش از کامیت چگونه پاکسازی شود\&. برای جزئیات بیشتر
\fBgit-commit\fR(1)
را ببینید\&. علاوه بر این، اگر به
\fI\fR
مقدار
\fBscissors\fR
داده شود، در صورت بروز تداخل ادغام، خط قیچی (scissors) پیش از ارسال به سازوکار کامیت به
\fBMERGE_MSG\fR
اضافه خواهد شد\&.
.RE
.PP
\fB\-\-ff\fR, \fB\-\-no\-ff\fR, \fB\-\-ff\-only\fR
.RS 4
مشخص می‌کند در صورتی که تاریخچه ادغام‌شده از قبل از نوادگان تاریخچه کنونی باشد، ادغام چگونه مدیریت شود\&.
\fB\-\-ff\fR
حالت پیش‌فرض است مگر اینکه یک برچسب (tag) دارای یادداشت (و احتمالاً امضاشده) ادغام شود که در جایگاه طبیعی خود در سلسله‌مراتب
\fBrefs/tags/\fR
ذخیره نشده است، که در این حالت
\fB\-\-no\-ff\fR
فرض می‌شود\&.
.sp
با
\fB\-\-ff\fR،
در صورت امکان، ادغام را به‌صورت فست‌فوروارد حل می‌کند (تنها اشاره‌گر شاخه را مطابق با شاخه ادغام‌شده به‌روزرسانی می‌کند؛ کامیت ادغام ایجاد نمی‌کند)\&. در صورت عدم امکان (زمانی که تاریخچه ادغام‌شده از نوادگان تاریخچه کنونی نباشد)، یک کامیت ادغام ایجاد می‌کند\&.
.sp
با
\fB\-\-no\-ff\fR،
در تمام موارد یک کامیت ادغام ایجاد می‌کند، حتی زمانی که ادغام می‌توانست در عوض به‌صورت فست‌فوروارد حل شود\&.
.sp
با
\fB\-\-ff\-only\fR،
در صورت امکان ادغام را به‌صورت فست‌فوروارد حل می‌کند\&. در صورت عدم امکان، از ادغام امتناع کرده و با وضعیت غیرصفر خارج می‌شود\&.
.RE
.PP
\fB\-S\fR[\fI\fR], \fB\-\-gpg\-sign\fR[\fB=\fR\fI\fR], \fB\-\-no\-gpg\-sign\fR
.RS 4
کامیت ادغام حاصل را با GPG امضا می‌کند\&. آرگومان
\fI\fR
اختیاری است و پیش‌فرض آن هویت کامیت‌کننده است؛ در صورت تعیین، باید بدون فاصله به گزینه متصل باشد\&.
\fB\-\-no\-gpg\-sign\fR
برای باطل کردن هم متغیر پیکربندی
\fBcommit\&.gpgSign\fR
و هم گزینه قبلی
\fB\-\-gpg\-sign\fR
مفید است\&.
.RE
.PP
\fB\-\-log\fR[\fB=\fR\fI\fR], \fB\-\-no\-log\fR
.RS 4
علاوه بر نام شاخه‌ها، پیام لاگ را با توضیحات یک‌خطی از حداکثر
\fI\fR
کامیت واقعی که در حال ادغام هستند پر می‌کند\&. همچنین
\fBgit-fmt-merge-msg\fR(1)
را ببینید\&.
.sp
با
\fB\-\-no\-log\fR
توضیحات یک‌خطی کامیت‌های واقعی در حال ادغام را فهرست نمی‌کند\&.
.RE
.PP
\fB\-\-signoff\fR, \fB\-\-no\-signoff\fR
.RS 4
یک دنباله (trailer)
\fBSigned\-off\-by\fR
توسط کامیت‌کننده در انتهای پیام لاگ کامیت اضافه می‌کند\&. معنای signoff به پروژه‌ای که در آن کامیت می‌کنید بستگی دارد\&. برای مثال، ممکن است گواهی دهد که کامیت‌کننده حق ارسال اثر تحت پروانه پروژه را دارد یا با برخی از بیانیه‌های مشارکت‌کنندگان، مانند «گواهی مبدا توسعه‌دهنده» (Developer Certificate of Origin) موافقت می‌کند\&. (برای نمونه مورد استفاده توسط هسته لینوکس و پروژه‌های گیت،
\m[blue]\fBhttps://developercertificate\&.org\fR\m[]
را ببینید\&.) برای درک نحوه استفاده از signoffها در پروژه‌ای که در آن مشارکت می‌کنید، با مستندات یا راهبری آن پروژه مشورت کنید\&.
.sp
گزینه
\fB\-\-no\-signoff\fR
می‌تواند برای باطل کردن گزینه قبلی
\fB\-\-signoff\fR
در خط فرمان استفاده شود\&.
.sp
گیت یک متغیر پیکربندی برای فعال کردن گزینه خط فرمان
\fB\-\-signoff\fR
به صورت پیش‌فرض ندارد (و نخواهد داشت)؛ برای جزئیات بیشتر ورودی
\fBcommit\&.signoff\fR
را در
\fBgitfaq\fR(7)
ببینید\&.
.RE
.PP
\fB\-\-stat\fR, \fB\-n\fR, \fB\-\-no\-stat\fR
.RS 4
یک diffstat در پایان ادغام نمایش می‌دهد\&. این diffstat همچنین توسط گزینه پیکربندی merge\&.stat کنترل می‌شود\&.
.sp
با
\fB\-n\fR
یا
\fB\-\-no\-stat\fR
در پایان ادغام diffstat نشان داده نمی‌شود\&.
.RE
.PP
\fB\-\-compact\-summary\fR
.RS 4
یک خلاصه فشرده (compact\-summary) در پایان ادغام نمایش می‌دهد\&.
.RE
.PP
\fB\-\-squash\fR, \fB\-\-no\-squash\fR
.RS 4
وضعیت درخت کاری و نمایه را به‌گونه‌ای ایجاد می‌کند که گویی یک ادغام واقعی رخ داده است (به‌جز اطلاعات ادغام)، اما در واقع کامیتی ایجاد نمی‌کند،
\fBHEAD\fR
را جابجا نمی‌کند، یا
\fB$GIT_DIR/MERGE_HEAD\fR
را ثبت نمی‌کند (تا باعث شود دستور بعدی
\fBgit\fR
\fBcommit\fR
یک کامیت ادغام ایجاد کند)\&. این به شما امکان می‌دهد تا یک کامیت منفرد بر روی شاخه کنونی بسازید که تأثیر آن همانند ادغام یک شاخه دیگر (یا بیشتر در حالت ادغام چندگانه یا اختاپوس) است\&.
.sp
با
\fB\-\-no\-squash\fR
ادغام را انجام داده و نتیجه را کامیت می‌کند\&. این گزینه می‌تواند برای لغو اثر
\fB\-\-squash\fR
استفاده شود\&.
.sp
با
\fB\-\-squash\fR،
استفاده از
\fB\-\-commit\fR
مجاز نبوده و ناموفق خواهد بود\&.
.RE
.PP
\fB\-\-verify\fR, \fB\-\-no\-verify\fR
.RS 4
به‌طور پیش‌فرض، قلاب‌های pre\-merge و commit\-msg اجرا می‌شوند\&. هنگامی که
\fB\-\-no\-verify\fR
مشخص شود، این قلاب‌ها دور زده می‌شوند\&. همچنین
\fBgithooks\fR(5)
را ببینید\&.
.RE
.PP
\fB\-s\fR \fI\fR, \fB\-\-strategy=\fR\fI\fR
.RS 4
از راهبرد ادغام داده‌شده استفاده می‌کند؛ می‌تواند بیش از یک بار مشخص شود تا به ترتیبی که باید امتحان شوند تعیین گردند\&. اگر گزینه
\fB\-s\fR
مشخص نشود، یک فهرست درونی از راهبردها استفاده می‌شود (\fBort\fR
هنگام ادغام یک سر (head) منفرد، و در غیر این صورت
\fBoctopus\fR)\&.
.RE
.PP
\fB\-X\fR \fI\fR, \fB\-\-strategy\-option=\fR\fI \fR
.RS 4
گزینه خاص راهبرد ادغام را به راهبرد ادغام ارسال می‌کند\&.
.RE
.PP
\fB\-\-verify\-signatures\fR, \fB\-\-no\-verify\-signatures\fR
.RS 4
بررسی و تأیید می‌کند که کامیت رأس شاخه جانبی در حال ادغام با یک کلید معتبر امضا شده باشد، یعنی کلیدی که دارای شناسه کاربری (uid) معتبر است: در مدل اعتماد پیش‌فرض، این بدان معناست که کلید امضاکننده توسط یک کلید مورد اعتماد امضا شده است\&. اگر کامیت رأس شاخه جانبی با کلید معتبر امضا نشده باشد، ادغام لغو می‌شود\&.
.RE
.PP
\fB\-\-summary\fR, \fB\-\-no\-summary\fR
.RS 4
مترادف‌هایی برای
\fB\-\-stat\fR
و
\fB\-\-no\-stat\fR؛
این گزینه‌ها منسوخ شده‌اند و در آینده حذف خواهند شد\&.
.RE
.PP
\fB\-q\fR, \fB\-\-quiet\fR
.RS 4
عملیات را در حالت ساکت انجام می‌دهد\&. این گزینه متضمن
\fB\-\-no\-progress\fR
است\&.
.RE
.PP
\fB\-v\fR, \fB\-\-verbose\fR
.RS 4
با جزئیات کامل اجرا می‌شود\&.
.RE
.PP
\fB\-\-progress\fR, \fB\-\-no\-progress\fR
.RS 4
نمایش پیشرفت را به‌طور صریح فعال یا غیرفعال می‌کند\&. اگر هیچ‌کدام مشخص نشوند، در صورتی که جریان خطای استاندارد به یک ترمینال متصل باشد، پیشرفت نمایش داده می‌شود\&. توجه داشته باشید که ممکن است همه راهبردهای ادغام از گزارش پیشرفت پشتیبانی نکنند\&.
.RE
.PP
\fB\-\-autostash\fR, \fB\-\-no\-autostash\fR
.RS 4
به‌طور خودکار پیش از شروع عملیات یک مدخل اندوخته (stash) موقت ایجاد کرده، آن را در ارجاع
\fBMERGE_AUTOSTASH\fR
ثبت می‌کند و پس از پایان عملیات اعمال می‌نماید\&. این بدان معناست که می‌توانید عملیات را روی یک درخت کاری با تغییرات ذخیره‌نشده (dirty) اجرا کنید\&. با این حال با احتیاط استفاده کنید: اعمال نهایی اندوخته پس از یک ادغام موفق ممکن است به تداخل‌های پیچیده منجر شود\&.
.RE
.PP
\fB\-\-allow\-unrelated\-histories\fR
.RS 4
به‌طور پیش‌فرض، دستور
\fBgit\fR
\fBmerge\fR
از ادغام تاریخچه‌هایی که جد مشترکی ندارند خودداری می‌کند\&. از این گزینه می‌توان برای لغو این تدبیر ایمنی هنگام ادغام تاریخچه‌های دو پروژه‌ای که زندگی خود را به‌طور مستقل آغاز کرده‌اند استفاده کرد\&. از آنجا که این یک رویداد بسیار نادر است، هیچ متغیر پیکربندی برای فعال کردن پیش‌فرض آن وجود ندارد یا افزوده نخواهد شد\&.
.RE
.PP
\fB\-m\fR \fI\fR
.RS 4
پیام کامیت مورد استفاده برای کامیت ادغام را تنظیم می‌کند (در صورتی که ایجاد شود)\&.
.sp
اگر
\fB\-\-log\fR
مشخص شده باشد، یک گزارش کوتاه (shortlog) از کامیت‌های در حال ادغام به پیام مشخص‌شده ضمیمه خواهد شد\&.
.sp
دستور
\fBgit\fR
\fBfmt\-merge\-msg\fR
می‌تواند برای ارائه یک پیش‌فرض مناسب در فراخوانی‌های خودکار
\fBgit\fR
\fBmerge\fR
استفاده شود\&. پیام خودکار می‌تواند شامل توضیحات شاخه باشد\&.
.RE
.PP
\fB\-\-into\-name\fR \fI\fR
.RS 4
پیام ادغام پیش‌فرض را به گونه‌ای آماده می‌کند که گویی ادغام در شاخه
\fI\fR
انجام می‌شود، به جای نام شاخه واقعی که ادغام در آن صورت می‌گیرد\&.
.RE
.PP
\fB\-F\fR \fI\fR, \fB\-\-file=\fR\fI\fR
.RS 4
پیام کامیت مورد استفاده برای کامیت ادغام را می‌خواند (در صورتی که ایجاد شود)\&.
.sp
اگر
\fB\-\-log\fR
مشخص شده باشد، یک گزارش کوتاه (shortlog) از کامیت‌های در حال ادغام به پیام مشخص‌شده ضمیمه خواهد شد\&.
.RE
.PP
\fB\-\-rerere\-autoupdate\fR, \fB\-\-no\-rerere\-autoupdate\fR
.RS 4
پس از اینکه سازوکار rerere از یک راه‌حل ثبت‌شده برای تداخل فعلی جهت به‌روزرسانی فایل‌ها در درخت کاری استفاده کرد، به آن اجازه می‌دهد تا نمایه را نیز با نتیجه حل تداخل به‌روز کند\&. گزینه
\fB\-\-no\-rerere\-autoupdate\fR
راه خوبی برای بررسی مجدد کاری است که
\fBgit-rerere\fR(1)
انجام داده تا خطاهای احتمالی در ادغام را قبل از کامیت کردن نتیجه در نمایه با یک دستور جداگانه
\fBgit-add\fR(1)
شناسایی کند\&.
.RE
.PP
\fB\-\-overwrite\-ignore\fR, \fB\-\-no\-overwrite\-ignore\fR
.RS 4
فایل‌های نادیده‌گرفته‌شده را بی‌صدا با نتیجه ادغام بازنویسی می‌کند\&. این رفتار پیش‌فرض است\&. برای لغو عملیات از
\fB\-\-no\-overwrite\-ignore\fR
استفاده کنید\&.
.RE
.PP
\fB\-\-abort\fR
.RS 4
فرآیند فعلی حل تداخل را لغو کرده و تلاش می‌کند وضعیت پیش از ادغام را بازسازی کند\&. اگر یک مدخل اندوخته خودکار (autostash) وجود داشته باشد، آن را روی درخت کاری اعمال می‌کند\&.
.sp
اگر هنگام شروع ادغام، تغییرات کامیت‌نشده‌ای در درخت کاری وجود داشته باشد، دستور
\fBgit\fR
\fBmerge\fR
\fB\-\-abort\fR
در برخی موارد قادر به بازسازی این تغییرات نخواهد بود\&. بنابراین توصیه می‌شود که همواره پیش از اجرای
\fBgit\fR
\fBmerge\fR،
تغییرات خود را کامیت یا اندوخته (stash) کنید\&.
.sp
دستور
\fBgit\fR
\fBmerge\fR
\fB\-\-abort\fR
هنگامی که
\fBMERGE_HEAD\fR
وجود داشته باشد، معادل دستور
\fBgit\fR
\fBreset\fR
\fB\-\-merge\fR
است، مگر اینکه
\fBMERGE_AUTOSTASH\fR
نیز وجود داشته باشد که در این صورت
\fBgit\fR
\fBmerge\fR
\fB\-\-abort\fR
مدخل اندوخته را روی درخت کاری اعمال می‌کند، در حالی که
\fBgit\fR
\fBreset\fR
\fB\-\-merge\fR
تغییرات اندوخته‌شده را در فهرست اندوخته‌ها ذخیره خواهد کرد\&.
.RE
.PP
\fB\-\-quit\fR
.RS 4
عملیات ادغام جاری در حال انجام را رها می‌کند\&. نمایه و درخت کاری را دست‌نخورده به همان حالت باقی می‌گذارد\&. اگر
\fBMERGE_AUTOSTASH\fR
وجود داشته باشد، مدخل اندوخته در فهرست اندوخته‌ها ذخیره خواهد شد\&.
.RE
.PP
\fB\-\-continue\fR
.RS 4
پس از اینکه یک دستور
\fBgit\fR
\fBmerge\fR
به دلیل تداخل‌ها متوقف شد، می‌توانید با اجرای دستور
\fBgit\fR
\fBmerge\fR
\fB\-\-continue\fR
ادغام را به پایان برسانید (بخش «نحوه حل تضادها (HOW TO RESOLVE CONFLICTS)» در زیر را ببینید)\&.
.RE
.PP
\fI\fR\&.\&.\&.
.RS 4
کامیت‌ها، معمولاً سرِ شاخه‌های دیگر، جهت ادغام در شاخه ما\&. مشخص کردن بیش از یک کامیت، ادغامی با بیش از دو والد ایجاد خواهد کرد (که به اصطلاح ادغام اختاپوسی یا Octopus merge نامیده می‌شود)\&.
.sp
اگر هیچ کامیتی از خط فرمان داده نشود، شاخه‌های ردگیری دوردست را که شاخه جاری برای استفاده از آن‌ها به عنوان بالادست خود پیکربندی شده است، ادغام می‌کند\&. همچنین بخش پیکربندی این صفحه راهنما را ببینید\&.
.sp
هنگامی که
\fBFETCH_HEAD\fR
(و هیچ کامیت دیگری) مشخص شود، شاخه‌های ثبت‌شده در فایل
\fB\&.git/FETCH_HEAD\fR
توسط فراخوانی قبلی
\fBgit\fR
\fBfetch\fR
برای ادغام، در شاخه جاری ادغام می‌شوند\&.
.RE
.SH "پیش‌درآمد (PRE-MERGE CHECKS)"
.sp
پیش از اعمال تغییرات بیرونی، باید کارهای خود را در وضعیت مناسبی قرار داده و به‌صورت محلی کامیت کنید تا در صورت بروز تعارض‌ها، بازنویسی و تخریب نشوند\&. همچنین نگاه کنید به \fBgit-stash\fR(1)\&. در صورتی که تغییرات محلی کامیت‌نشده با فایل‌هایی که ممکن است نیاز به به‌روزرسانی توسط \fBgit\fR \fBpull\fR/\fBgit\fR \fBmerge\fR داشته باشند هم‌پوشانی داشته باشند، \fBgit\fR \fBpull\fR و \fBgit\fR \fBmerge\fR بدون انجام هیچ کاری متوقف خواهند شد\&.
.sp
برای جلوگیری از ثبت تغییرات نامرتبط در کامیت ادغام، اگر هرگونه تغییری نسبت به کامیت \fBHEAD\fR در نمایه (index) ثبت شده باشد، \fBgit\fR \fBpull\fR و \fBgit\fR \fBmerge\fR نیز عملیات را متوقف (abort) می‌کنند\&. (بسته به استراتژی ادغام مورد استفاده ممکن است استثناهای محدودی برای این قاعده وجود داشته باشد، اما به‌طور کلی، ایندکس باید با \fBHEAD\fR مطابقت داشته باشد\&.)
.sp
اگر تمام کامیت‌های مشخص‌شده از قبل جزو نیاکان \fBHEAD\fR باشند، \fBgit\fR \fBmerge\fR بلافاصله با پیام "Already up to date\&." خارج می‌شود\&.
.SH "ادغام سریع (FAST-FORWARD MERGE)"
.sp
اغلب سرِ شاخه فعلی، نیای کامیت مشخص‌شده است\&. این متداول‌ترین حالت است، به‌ویژه زمانی که از طریق \fBgit\fR \fBpull\fR فراخوانی می‌شود: شما یک مخزن بالادست را دنبال می‌کنید، هیچ تغییر محلی را کامیت نکرده‌اید، و اکنون می‌خواهید به نسخه بازنگری جدیدتری از بالادست به‌روزرسانی کنید\&. در این حالت، نیازی به کامیت جدید برای ذخیره تاریخچه ترکیبی نیست؛ در عوض، \fBHEAD\fR (به همراه ایندکس) بدون ایجاد کامیت ادغام اضافی، به‌روزرسانی می‌شود تا به کامیت مشخص‌شده اشاره کند\&.
.sp
این رفتار را می‌توان با گزینه \fB\-\-no\-ff\fR غیرفعال کرد\&.
.SH "ادغام واقعی (TRUE MERGE)"
.sp
به‌جز در حالت ادغام سریع (fast-forward، بالا را ببینید)، شاخه‌هایی که قرار است ادغام شوند باید با یک کامیت ادغام که هر دوی آن‌ها را به‌عنوان والد خود دارد، به یکدیگر متصل گردند\&.
.sp
یک نسخه ادغام‌شده که تغییرات حاصل از تمامی شاخه‌های مورد ادغام را یکپارچه می‌کند کامیت می‌شود، و \fBHEAD\fR، ایندکس و درخت کاری شما مطابق با آن به‌روزرسانی می‌شوند\&. وجود تغییرات در درخت کاری تا زمانی که با تغییرات ادغام هم‌پوشانی نداشته باشند مجاز است؛ عملیات به‌روزرسانی آن‌ها را حفظ خواهد کرد\&.
.sp
هنگامی که نحوه یکپارچه‌سازی تغییرات مشخص و بدیهی نباشد، موارد زیر رخ می‌دهد:
.sp
.RS 4
.ie n \{\
\h'-04' 1.\h'+01'\c
.\}
.el \{\
.sp -1
.IP " 1." 4.2
.\}
اشاره‌گر
\fBHEAD\fR
بدون تغییر باقی می‌ماند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 2.\h'+01'\c
.\}
.el \{\
.sp -1
.IP " 2." 4.2
.\}
ارجاع
\fBMERGE_HEAD\fR
تنظیم می‌شود تا به سرِ شاخه دیگر اشاره کند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 3.\h'+01'\c
.\}
.el \{\
.sp -1
.IP " 3." 4.2
.\}
مسیرهایی که بدون تعارض ادغام شده‌اند، هم در فایل ایندکس و هم در درخت کاری شما به‌روزرسانی می‌شوند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 4.\h'+01'\c
.\}
.el \{\
.sp -1
.IP " 4." 4.2
.\}
برای مسیرهای دارای تعارض، فایل ایندکس حداکثر سه نسخه را ثبت می‌کند: مرحله ۱ نسخه مربوط به جد مشترک را ذخیره می‌کند، مرحله ۲ نسخه مربوط به
\fBHEAD\fR،
و مرحله ۳ نسخه مربوط به
\fBMERGE_HEAD\fR
(می‌توانید این مراحل را با
\fBgit\fR
\fBls\-files\fR
\fB\-u\fR
بررسی کنید)\&. فایل‌های درخت کاری حاوی نتیجه عملیات ادغام خواهند بود؛ یعنی نتایج ادغام ۳\-طرفه با نشانگرهای آشنای تعارض
\fB<<<\fR
\fB===\fR
\fB>>>\fR\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 5.\h'+01'\c
.\}
.el \{\
.sp -1
.IP " 5." 4.2
.\}
یک ارجاع به نام
\fBAUTO_MERGE\fR
نوشته می‌شود که به درختی متناظر با محتوای فعلی درخت کاری اشاره می‌کند (شامل نشانگرهای تعارض برای تعارض‌های متنی)\&. توجه داشته باشید که این ارجاع تنها زمانی نوشته می‌شود که از استراتژی ادغام
\fBort\fR
(پیش‌فرض) استفاده شود\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 6.\h'+01'\c
.\}
.el \{\
.sp -1
.IP " 6." 4.2
.\}
هیچ تغییر دیگری اعمال نمی‌شود\&. به‌ویژه، تغییرات محلی که پیش از شروع ادغام داشته‌اید بدون تغییر باقی می‌مانند و ورودی‌های ایندکس مربوط به آن‌ها همان‌طور که بودند حفظ می‌شوند، یعنی مطابق با
\fBHEAD\fR\&.
.RE
.sp
اگر ادغامی را اجرا کردید که منجر به تعارض‌های پیچیده شد و می‌خواهید دوباره از نو شروع کنید، می‌توانید با استفاده از \fBgit\fR \fBmerge\fR \fB\-\-abort\fR وضعیت را بازیابی کنید\&.
.SH "ادغام برچسب (MERGING TAG)"
.sp
هنگام ادغام یک برچسب حاوی توضیح (annotated) (و احتمالاً امضاشده)، گیت همیشه حتی در صورت امکان‌پذیر بودن ادغام سریع، یک کامیت ادغام ایجاد می‌کند و الگوی پیام کامیت با پیام برچسب آماده می‌شود\&. علاوه بر این، در صورت امضاشده بودن برچسب، نتیجه بررسی امضا به‌صورت یک توضیح در الگوی پیام گزارش می‌شود\&. همچنین نگاه کنید به \fBgit-tag\fR(1)\&.
.sp
هنگامی که فقط می‌خواهید کارهای منتهی به کامیتی را که برچسب‌گذاری شده است یکپارچه کنید (مانند همگام‌سازی با یک نقطه انتشار بالادست)، ممکن است نخواهید یک کامیت ادغام غیرضروری ایجاد نمایید\&.
.sp
در چنین حالتی، می‌توانید پیش از ارسال برچسب به \fBgit\fR \fBmerge\fR، خودتان آن را «باز» (unwrap) کنید یا در صورتی که هیچ تغییر محلی ندارید گزینه \fB\-\-ff\-only\fR را مشخص نمایید؛ مانند:
.sp
.if n \{\
.RS 4
.\}
.nf
git fetch origin
git merge v1\&.2\&.3^0
git merge \-\-ff\-only v1\&.2\&.3
.fi
.if n \{\
.RE
.\}
.sp
.SH "حل تضادها (HOW CONFLICTS ARE PRESENTED)"
.sp
در حین یک ادغام، فایل‌های درخت کاری به‌روزرسانی می‌شوند تا نتیجه ادغام را منعکس کنند\&. از میان تغییرات ایجادشده نسبت به نسخه نیای مشترک، تغییرات غیرهمپوشان (یعنی شما بخشی از فایل را تغییر داده‌اید در حالی که طرف دیگر آن بخش را دست‌نخورده باقی گذاشته است، یا برعکس) عیناً در نتیجه نهایی اعمال می‌شوند\&. با این حال، هنگامی که هر دو طرف تغییراتی در یک بخش یکسان ایجاد کرده باشند، گیت نمی‌تواند به‌صورت تصادفی یکی از طرفین را بر دیگری ترجیح دهد، و با قرار دادن کارهایی که هر دو طرف در آن بخش انجام داده‌اند، از شما می‌خواهد که آن را حل کنید\&.
.sp
به‌طور پیش‌فرض، گیت برای نمایش چنین قطعه متضادی از همان سبکی استفاده می‌کند که توسط برنامه "merge" از مجموعه ابزار RCS به کار می‌رود، مانند این:
.sp
.if n \{\
.RS 4
.\}
.nf
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\*(Aqs go shopping\&.
=======
Git makes conflict resolution easy\&.
>>>>>>> theirs:sample\&.txt
And here is another line that is cleanly resolved or unmodified\&.
.fi
.if n \{\
.RE
.\}
.sp
.sp
ناحیه‌ای که یک جفت تغییر متضاد در آن رخ داده است، با نشانگرهای \fB<<<<<<<\fR، \fB=======\fR و \fB>>>>>>>\fR علامت‌گذاری می‌شود\&. بخش پیش از \fB=======\fR معمولاً سمت شماست، و بخش پس از آن معمولاً سمت طرف مقابل است\&.
.sp
قالب پیش‌فرض نشان نمی‌دهد که متن اصلی در ناحیه متضاد چه بوده است\&. شما نمی‌توانید تشخیص دهید چند خط حذف شده و با اظهار نظر باربی در سمت شما جایگزین شده است\&. تنها چیزی که می‌توانید متوجه شوید این است که سمت شما می‌خواهد بگوید کار سختی است و ترجیح می‌دهید به خرید بروید، در حالی که طرف دیگر ادعا می‌کند آسان است\&.
.sp
می‌توان با تنظیم متغیر پیکربندی
\fBmerge\&.conflictStyle\fR
روی
\fBdiff3\fR
یا
\fBzdiff3\fR،
از یک سبک جایگزین استفاده کرد\&. در سبک
\fBdiff3\fR،
تضاد بالا ممکن است به این شکل باشد:
.sp
.if n \{\
.RS 4
.\}
.nf
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\*(Aqs 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\&.
.fi
.if n \{\
.RE
.\}
.sp
.sp
در حالی که در سبک
\fBzdiff3\fR،
ممکن است به این شکل باشد:
.sp
.if n \{\
.RS 4
.\}
.nf
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\*(Aqs 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\&.
.fi
.if n \{\
.RE
.\}
.sp
.sp
علاوه بر نشانگرهای
\fB<<<<<<<\fR،
\fB=======\fR
و
\fB>>>>>>>\fR،
از نشانگر دیگری به نام
\fB|||||||\fR
استفاده می‌کند که متن اصلی به دنبال آن می‌آید\&. می‌توانید متوجه شوید که نسخه اصلی تنها یک واقعیت را بیان کرده بود، و سمت شما صرفاً تسلیم آن اظهار نظر شده و دست کشیده است، در حالی که طرف مقابل تلاش کرده تا نگرش مثبت‌تری داشته باشد\&. گاهی اوقات با مشاهده متن اصلی می‌توانید به راه‌حل بهتری برسید\&.
.SH "نحوه حل تضادها (HOW TO RESOLVE CONFLICTS)"
.sp
پس از مشاهده تضاد، می‌توانید دو کار انجام دهید:
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
تصمیم به عدم ادغام بگیرید\&. تنها پاک‌سازی‌هایی که نیاز دارید، بازنشانی فایل نمایه به کامیت
\fBHEAD\fR
برای بازگرداندن مورد ۲ و پاکسازی تغییرات درخت کاری ایجادشده توسط موارد ۲ و ۳ است؛
برای این کار می‌توان از
\fBgit\fR
\fBmerge\fR
\fB\-\-abort\fR
استفاده کرد\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
تضادها را حل کنید\&. گیت تضادها را در درخت کاری مشخص می‌کند\&. فایل‌ها را ویرایش و اصلاح کرده و با
\fBgit\fR
\fBadd\fR
آن‌ها را به نمایه اضافه کنید\&. برای نهایی کردن کار از
\fBgit\fR
\fBcommit\fR
یا
\fBgit\fR
\fBmerge\fR
\fB\-\-continue\fR
استفاده کنید\&. دستور دوم پیش از فراخوانی
\fBgit\fR
\fBcommit\fR،
بررسی می‌کند که آیا یک ادغام (متوقف‌شده) در جریان است یا خیر\&.
.RE
.sp
می‌توانید با استفاده از ابزارهای مختلفی تضادها را حل کنید:
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
از یک ابزار ادغام (mergetool) استفاده کنید\&.
دستور
\fBgit\fR
\fBmergetool\fR
برای اجرای یک ابزار گرافیکی حل ادغام است که مراحل ادغام را همراه با شما انجام می‌دهد\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
تفاوت‌ها (diff) را بررسی کنید\&.
دستور
\fBgit\fR
\fBdiff\fR
یک تفاوت سه‌طرفه را نشان می‌دهد و تغییرات هر دو نسخه
\fBHEAD\fR
و
\fBMERGE_HEAD\fR
را برجسته می‌سازد\&.
دستور
\fBgit\fR
\fBdiff\fR
\fBAUTO_MERGE\fR
تغییراتی را نشان می‌دهد که تاکنون برای حل تضادهای متنی اعمال کرده‌اید\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
تفاوت‌های هر شاخه را بررسی کنید\&.
دستور
\fBgit\fR
\fBlog\fR
\fB\-\-merge\fR
\fB\-p\fR
\fI\fR
ابتدا تفاوت‌ها را برای نسخه
\fBHEAD\fR
و سپس برای نسخه
\fBMERGE_HEAD\fR
نشان می‌دهد\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
نسخه‌های اصلی را بررسی کنید\&.
دستور
\fBgit\fR
\fBshow\fR
\fB:1:filename\fR
نسخه نیای مشترک را نشان می‌دهد،
\fBgit\fR
\fBshow\fR
\fB:2:filename\fR
نسخه
\fBHEAD\fR
را نشان می‌دهد، و
\fBgit\fR
\fBshow\fR
\fB:3:filename\fR
نسخه
\fBMERGE_HEAD\fR
را نشان می‌دهد\&.
.RE
.SH "مثال‌ها (EXAMPLES)"
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
ادغام شاخه‌های
\fBfixes\fR
و
\fBenhancements\fR
روی شاخه جاری، با ایجاد یک ادغام هشت‌پا (octopus merge):
.sp
.if n \{\
.RS 4
.\}
.nf
$ git merge fixes enhancements
.fi
.if n \{\
.RE
.\}
.sp
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
ادغام شاخه
\fBobsolete\fR
در شاخه جاری، با استفاده از استراتژی ادغام
\fBours\fR:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git merge \-s ours obsolete
.fi
.if n \{\
.RE
.\}
.sp
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
ادغام شاخه
\fBmaint\fR
در شاخه جاری، اما بدون ایجاد خودکار یک کامیت جدید:
.sp
.if n \{\
.RS 4
.\}
.nf
$ git merge \-\-no\-commit maint
.fi
.if n \{\
.RE
.\}
.sp
از این حالت می‌توان زمانی استفاده کرد که بخواهید تغییرات بیشتری را در ادغام بگنجانید، یا بخواهید پیام کامیت ادغام را خودتان بنویسید\&.
.sp
باید از سوءاستفاده از این گزینه برای وارد کردن مخفیانه تغییرات اساسی به یک کامیت ادغام خودداری کنید\&. اصلاحات جزئی مانند ارتقای نام انتشار/نسخه قابل قبول خواهد بود\&.
.RE
.SH "راهبردهای ادغام (MERGE STRATEGIES)"
.sp
سازوکار ادغام (دستورات \fBgit\fR \fBmerge\fR و \fBgit\fR \fBpull\fR) امکان انتخاب \fIاستراتژی‌های ادغام\fR پس‌زمینه را با گزینه \fB\-s\fR فراهم می‌کند\&. برخی از استراتژی‌ها همچنین می‌توانند گزینه‌های ویژه خود را دریافت کنند که می‌توان آن‌ها را با دادن آرگومان‌های \fB\-X\fR\fI\fR به \fBgit\fR \fBmerge\fR و/یا \fBgit\fR \fBpull\fR ارسال کرد\&.
.PP
\fBort\fR
.RS 4
این استراتژی پیش‌فرض ادغام هنگام دریافت (pull) یا ادغام یک شاخه است\&. این استراتژی فقط می‌تواند دو سرشاخه را با استفاده از الگوریتم ادغام ۳-طرفه حل کند\&. هنگامی که بیش از یک والد مشترک وجود داشته باشد که بتوان برای ادغام ۳-طرفه از آن استفاده کرد، درختی ادغام‌شده از والدین مشترک ایجاد می‌کند و از آن به‌عنوان درخت مرجع برای ادغام ۳-طرفه بهره می‌برد\&. بر اساس آزمایش‌های انجام‌شده روی کامیت‌های ادغام واقعی برگرفته از تاریخچه توسعه هسته لینوکس ۲.۶، گزارش شده است که این روش منجر به تعارض‌های ادغام کمتر بدون ایجاد ادغام‌های نادرست می‌شود\&. علاوه بر این، این استراتژی می‌تواند ادغام‌های شامل تغییر نام را شناسایی و مدیریت کند\&. این استراتژی از کپی‌های شناسایی‌شده استفاده نمی‌کند\&. نام این الگوریتم یک کوته‌نوشت ("Ostensibly Recursive\(cqs Twin") است و از این واقعیت ناشی می‌شود که به‌عنوان جایگزینی برای الگوریتم پیش‌فرض قبلی نوشته شده است:
\fBrecursive\fR\&.
.sp
در حالتی که مسیر مورد نظر یک زیرماژول است، اگر کامیت زیرماژول استفاده‌شده در یک طرف ادغام، نواده (descendant) کامیت زیرماژول استفاده‌شده در طرف دیگر ادغام باشد، گیت تلاش می‌کند تا به آن نواده فست‌فوروارد کند\&. در غیر این صورت، گیت این حالت را به‌عنوان یک تعارض در نظر می‌گیرد و کامیت زیرماژولی را که نواده کامیت‌های دارای تعارض است (در صورت وجود) به‌عنوان راه‌حل پیشنهاد می‌کند\&.
.sp
استراتژی
\fBort\fR
می‌تواند گزینه‌های زیر را بپذیرد:
.PP
\fBours\fR
.RS 4
این گزینه تکه‌های دارای تعارض (conflicting hunks) را مجبور می‌کند تا با اولویت دادن به نسخه
\fIما (our)\fR
به‌طور خودکار و تمیز حل شوند\&. تغییرات درخت دیگر که با طرف ما تعارضی ندارند، در نتیجه ادغام منعکس می‌شوند\&. برای یک فایل باینری، کل محتوا از طرف ما گرفته می‌شود\&.
.sp
این گزینه نباید با استراتژی ادغام
\fBours\fR
اشتباه گرفته شود؛ آن استراتژی اصلاً به آنچه درخت دیگر شامل می‌شود نگاه نمی‌کند و هر کاری را که درخت دیگر انجام داده دور می‌اندازد و اعلام می‌کند که تاریخچه
\fIما\fR
شامل تمام رویدادهایی است که در آن رخ داده است\&.
.RE
.PP
\fBtheirs\fR
.RS 4
این گزینه برعکس
\fBours\fR
است؛ توجه داشته باشید که بر خلاف
\fBours\fR،
هیچ استراتژی ادغامی به نام
\fBtheirs\fR
وجود ندارد که بتوان این گزینه ادغام را با آن اشتباه گرفت\&.
.RE
.PP
\fBignore\-space\-change\fR, \fBignore\-all\-space\fR, \fBignore\-space\-at\-eol\fR, \fBignore\-cr\-at\-eol\fR
.RS 4
خطوطی را که دارای نوع مشخص‌شده تغییرات در فاصله‌های خالی (whitespace) هستند، به منظور ادغام سه‌طرفه به‌عنوان خطوط بدون تغییر در نظر می‌گیرد\&. تغییرات فاصله‌های خالی که با تغییرات دیگر در یک خط ترکیب شده باشند، نادیده گرفته نمی‌شوند\&. همچنین به
\fBgit-diff\fR(1)
\fB\-b\fR،
\fB\-w\fR،
\fB\-\-ignore\-space\-at\-eol\fR
و
\fB\-\-ignore\-cr\-at\-eol\fR
مراجعه کنید\&.
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
اگر نسخه
\fIآن‌ها (their)\fR
فقط تغییرات فاصله خالی را در یک خط ایجاد کرده باشد، از نسخه
\fIما (our)\fR
استفاده می‌شود؛
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
اگر نسخه
\fIما\fR
تغییرات فاصله خالی ایجاد کرده باشد اما نسخه
\fIآن‌ها\fR
شامل یک تغییر اساسی باشد، از نسخه
\fIآن‌ها\fR
استفاده می‌شود؛
.RE
.sp
.RS 4
.ie n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
در غیر این صورت، ادغام به روش معمول پیش می‌رود\&.
.RE
.RE
.PP
\fBrenormalize\fR
.RS 4
این گزینه یک دریافت (check-out) و ثبت (check-in) مجازی از تمام سه مرحله هر فایلی که نیاز به ادغام سه‌طرفه دارد انجام می‌دهد\&. این گزینه برای استفاده هنگام ادغام شاخه‌هایی با فیلترهای پاکسازی متفاوت یا قوانین نرمال‌سازی انتهای خط متفاوت در نظر گرفته شده است\&. برای جزئیات به بخش "Merging branches with differing checkin/checkout attributes" در
\fBgitattributes\fR(5)
مراجعه کنید\&.
.RE
.PP
\fBno\-renormalize\fR
.RS 4
گزینه
\fBrenormalize\fR
را غیرفعال می‌کند\&. این گزینه متغیر پیکربندی
\fBmerge\&.renormalize\fR
را بازنویسی (override) می‌کند\&.
.RE
.PP
\fBfind\-renames\fR[\fB=\fR\fI\fR]
.RS 4
تشخیص تغییر نام را فعال می‌کند و به‌صورت اختیاری آستانه شباهت را تنظیم می‌نماید\&. این حالت پیش‌فرض است\&. این گزینه متغیر پیکربندی
\fBmerge\&.renames\fR
را بازنویسی می‌کند\&. همچنین به
\fBgit-diff\fR(1)
\fB\-\-find\-renames\fR
مراجعه کنید\&.
.RE
.PP
\fBrename\-threshold=\fR\fI\fR
.RS 4
یک مترادف منسوخ‌شده برای
\fBfind\-renames=\fR\fI\fR\&.
.RE
.PP
\fBno\-renames\fR
.RS 4
تشخیص تغییر نام را خاموش می‌کند\&. این گزینه متغیر پیکربندی
\fBmerge\&.renames\fR
را بازنویسی می‌کند\&. همچنین به
\fBgit-diff\fR(1)
\fB\-\-no\-renames\fR
مراجعه کنید\&.
.RE
.PP
\fBhistogram\fR
.RS 4
یک مترادف منسوخ‌شده برای
\fBdiff\-algorithm=histogram\fR\&.
.RE
.PP
\fBpatience\fR
.RS 4
یک مترادف منسوخ‌شده برای
\fBdiff\-algorithm=patience\fR\&.
.RE
.PP
\fBdiff\-algorithm=\fR(\fBhistogram\fR|\fBminimal\fR|\fBmyers\fR|\fBpatience\fR)
.RS 4
از یک الگوریتم تفاضل (diff) متفاوت هنگام ادغام استفاده می‌کند، که می‌تواند به جلوگیری از ادغام‌های نادرست که ناشی از خطوط منطبق کم‌اهمیت هستند (مانند براکت‌های توابع مجزا) کمک کند\&. همچنین به
\fBgit-diff\fR(1)
\fB\-\-diff\-algorithm\fR
مراجعه کنید\&. توجه داشته باشید که
\fBort\fR
به‌طور پیش‌فرض از
\fBdiff\-algorithm=histogram\fR
استفاده می‌کند، در حالی که تفاضل‌های معمولی در حال حاضر به‌طور پیش‌فرض از تنظیمات پیکربندی
\fBdiff\&.algorithm\fR
استفاده می‌نمایند\&.
.RE
.PP
\fBsubtree\fR[\fB=\fR\fI\fR]
.RS 4
این گزینه شکل پیشرفته‌تری از استراتژی
\fIsubtree\fR
است که در آن استراتژی حدس می‌زند دو درخت چگونه باید نسبت به یکدیگر جابجا شوند تا هنگام ادغام با هم تطبیق یابند\&. در عوض، مسیر مشخص‌شده به ابتدای مسیرها اضافه می‌شود (یا از ابتدا حذف می‌شود) تا شکل دو درخت مطابقت پیدا کند\&.
.RE
.RE
.PP
\fBrecursive\fR
.RS 4
این گزینه اکنون مترادفی برای
\fBort\fR
است\&. تا نسخه 2.49.0 یک پیاده‌سازی جایگزین بود، اما در نسخه 2.50.0 تغییر مسیر یافت تا به معنای
\fBort\fR
باشد\&. استراتژی بازگشتی قبلی، استراتژی پیش‌فرض برای حل دو سرشاخه از نسخه v0.99.9k گیت تا نسخه v2.33.0 بود\&.
.RE
.PP
\fBresolve\fR
.RS 4
این استراتژی فقط می‌تواند دو سرشاخه (یعنی شاخه جاری و شاخه دیگری که از آن دریافت کرده‌اید) را با استفاده از یک الگوریتم ادغام ۳-طرفه حل کند\&. این روش تلاش می‌کند تا ابهامات ادغام ضربدری (criss-cross) را با دقت شناسایی کند\&. این استراتژی تغییر نام‌ها را مدیریت نمی‌کند\&.
.RE
.PP
\fBoctopus\fR
.RS 4
این استراتژی موارد با بیش از دو سرشاخه را حل می‌کند، اما از انجام یک ادغام پیچیده که نیاز به حل دستی داشته باشد خودداری می‌ورزد\&. این استراتژی عمدتاً برای دسته‌بندی سرشاخه‌های موضوعی (topic branches) در کنار هم استفاده می‌شود\&. این حالت، استراتژی ادغام پیش‌فرض هنگام دریافت (pull) یا ادغام بیش از یک شاخه است\&.
.RE
.PP
\fBours\fR
.RS 4
این استراتژی هر تعداد سرشاخه را حل می‌کند، اما درخت حاصل از ادغام همیشه همان سرشاخه جاری است و در عمل تمام تغییرات از سایر شاخه‌ها را نادیده می‌گیرد\&. این روش برای جایگزین کردن تاریخچه توسعه قدیمی شاخه‌های فرعی در نظر گرفته شده است\&. توجه داشته باشید که این استراتژی با گزینه
\fB\-Xours\fR
در استراتژی ادغام
\fBort\fR
متفاوت است\&.
.RE
.PP
\fBsubtree\fR
.RS 4
این یک استراتژی اصلاح‌شده از
\fBort\fR
است\&. هنگام ادغام درخت‌های A و B، اگر B متناظر با یک زیردرخت از A باشد، B ابتدا طوری تنظیم می‌شود که با ساختار درختی A مطابقت داشته باشد، به‌جای اینکه درخت‌ها در همان سطح خوانده شوند\&. این تنظیم برای درخت والد مشترک نیز انجام می‌شود\&.
.RE
.sp
در استراتژی‌هایی که از ادغام ۳-طرفه استفاده می‌کنند (از جمله گزینه پیش‌فرض، \fBort\fR)، اگر تغییری در هر دو شاخه ایجاد شود اما بعداً در یکی از شاخه‌ها بازگردانی (revert) شود، آن تغییر در نتیجه ادغام وجود خواهد داشت؛ برخی این رفتار را گیج‌کننده می‌دانند\&. این حالت رخ می‌دهد زیرا هنگام انجام ادغام، فقط سرشاخه‌ها و پایه ادغام (merge base) در نظر گرفته می‌شوند، نه تک‌تک کامیت‌ها\&. بنابراین الگوریتم ادغام، تغییر بازگردانده‌شده را اصلاً به‌عنوان هیچ تغییری در نظر نمی‌گیرد و در عوض نسخه تغییریافته را جایگزین می‌کند\&.
.SH "پیکربندی (CONFIGURATION)"
.PP
\fBbranch\&.\fR\fI\fR\fB\&.mergeOptions\fR
.RS 4
گزینه‌های پیش‌فرض را برای ادغام در شاخه
\fI\fR
تنظیم می‌کند\&. نحو و گزینه‌های پشتیبانی‌شده همانند موارد
\fBgit\fR
\fBmerge\fR
هستند، اما مقادیر گزینه‌های حاوی نویسه‌های فاصله خالی در حال حاضر پشتیبانی نمی‌شوند\&.
.RE
.sp
تمام موارد بالاتر از این خط در این بخش، از مستندات \fBgit-config\fR(1) برگرفته نشده‌اند\&. محتوایی که در ادامه می‌آید همان چیزی است که در آنجا یافت می‌شود:
.PP
\fBmerge\&.conflictStyle\fR
.RS 4
سبکی را مشخص می‌کند که بر اساس آن بخش‌های دارای تداخل (hunks) هنگام ادغام در فایل‌های درخت کاری نوشته می‌شوند\&. مقدار پیش‌فرض "merge" است که یک نشانگر تداخل
\fB<<<<<<<\fR،
تغییرات اعمال‌شده توسط یک طرف، یک نشانگر
\fB=======\fR،
تغییرات اعمال‌شده توسط طرف دیگر، و سپس یک نشانگر
\fB>>>>>>>\fR
را نمایش می‌دهد\&. یک سبک جایگزین، "diff3"، یک نشانگر
\fB|||||||\fR
و متن اصلی را قبل از نشانگر
\fB=======\fR
می‌افزاید\&. سبک "merge" معمولاً ناحیه‌های تداخل کوچک‌تری نسبت به diff3 ایجاد می‌کند، هم به دلیل کنار گذاشتن متن اصلی، و هم به این دلیل که وقتی زیرمجموعه‌ای از خطوط در دو طرف یکسان باشند، صرفاً از ناحیه تداخل خارج می‌شوند\&. سبک جایگزین دیگر، "zdiff3"، شبیه به diff3 است اما خطوط منطبق در دو طرف را از ناحیه تداخل حذف می‌کند زمانی که آن خطوط منطبق در نزدیکی آغاز یا پایان ناحیه تداخل ظاهر شوند\&.
.RE
.PP
\fBmerge\&.defaultToUpstream\fR
.RS 4
اگر merge بدون هیچ آرگومان کامیتی فراخوانی شود، شاخه‌های بالادست پیکربندی‌شده برای شاخه جاری را با استفاده از آخرین مقادیر مشاهده‌شده ذخیره‌شده در شاخه‌های ردیاب دوردست (remote\-tracking) آن‌ها ادغام می‌کند\&. مقادیر
\fBbranch\&.\fR\fB\&.merge\fR
که نام شاخه‌ها را در مخزن دوردستِ مشخص‌شده توسط
\fBbranch\&.\fR\fI\fR\fB\&.remote\fR
تعیین می‌کنند بررسی شده و سپس از طریق
\fBremote\&.\fR\fI\fR\fB\&.fetch\fR
به شاخه‌های ردیاب دوردست متناظر نگاشت می‌شوند و نوک (tip) این شاخه‌های ردیاب ادغام می‌گردند\&. به‌طور پیش‌فرض true است\&.
.RE
.PP
\fBmerge\&.ff\fR
.RS 4
به‌طور پیش‌فرض، گیت هنگام ادغام کامیتی که از نوادگان کامیت جاری است، یک کامیت ادغام اضافی ایجاد نمی‌کند\&. در عوض، نوک شاخه جاری به جلو رانده می‌شود (fast\-forward)\&. هنگامی که روی
\fBfalse\fR
تنظیم شود، این متغیر به گیت اعلام می‌کند که در چنین شرایطی یک کامیت ادغام اضافی ایجاد کند (معادل دادن گزینه
\fB\-\-no\-ff\fR
از خط فرمان)\&. هنگامی که روی
\fBonly\fR
تنظیم شود، تنها چنین ادغام‌های فست‌فوروارد (fast\-forward) مجاز خواهند بود (معادل دادن گزینه
\fB\-\-ff\-only\fR
از خط فرمان)\&.
.RE
.PP
\fBmerge\&.verifySignatures\fR
.RS 4
اگر true باشد، این معادل گزینه خط فرمان
\fB\-\-verify\-signatures\fR
است\&. برای جزئیات به
\fBgit-merge\fR(1)
مراجعه کنید\&.
.RE
.PP
\fBmerge\&.branchdesc\fR
.RS 4
علاوه بر نام شاخه‌ها، پیام لاگ را با متن توضیحات شاخه مرتبط با آن‌ها پر می‌کند\&. به‌طور پیش‌فرض false است\&.
.RE
.PP
\fBmerge\&.log\fR
.RS 4
علاوه بر نام شاخه‌ها، پیام لاگ را با حداکثر تعداد مشخص‌شده از توضیحات یک‌خطی کامیت‌های واقعی در حال ادغام پر می‌کند\&. به‌طور پیش‌فرض false است، و true مترادفی برای 20 می‌باشد\&.
.RE
.PP
\fBmerge\&.suppressDest\fR
.RS 4
با افزودن یک الگوی تطابق (glob) که با نام‌های شاخه‌های یکپارچه‌سازی مطابقت دارد به این متغیر پیکربندی چندمقداری، پیام ادغام پیش‌فرض محاسبه‌شده برای ادغام در این شاخه‌های یکپارچه‌سازی، عبارت "into
\fI\fR"
را از عنوان خود حذف می‌کند\&.
.sp
یک عنصر با مقدار خالی می‌تواند برای پاک کردن فهرست الگوهای انباشته‌شده از مدخل‌های پیکربندی قبلی استفاده شود\&. هنگامی که هیچ متغیر
\fBmerge\&.suppressDest\fR
تعریف نشده باشد، مقدار پیش‌فرض
\fBmaster\fR
برای سازگاری رو به عقب استفاده می‌شود\&.
.RE
.PP
\fBmerge\&.renameLimit\fR
.RS 4
تعداد فایل‌هایی که در بخش جامع تشخیص تغییر نام در طول یک ادغام در نظر گرفته می‌شوند\&. در صورت مشخص نشدن، مقدار پیش‌فرض آن برابر مقدار
\fBdiff\&.renameLimit\fR
است\&. اگر نه
\fBmerge\&.renameLimit\fR
و نه
\fBdiff\&.renameLimit\fR
مشخص نشده باشند، در حال حاضر مقدار پیش‌فرض برابر 7000 است\&. اگر تشخیص تغییر نام غیرفعال باشد، این تنظیم هیچ تأثیری ندارد\&.
.RE
.PP
\fBmerge\&.renames\fR
.RS 4
مشخص می‌کند که آیا گیت تغییر نام‌ها را تشخیص دهد یا خیر\&. اگر روی
\fBfalse\fR
تنظیم شود، تشخیص تغییر نام غیرفعال است\&. اگر روی
\fBtrue\fR
تنظیم شود، تشخیص پایه‌ای تغییر نام فعال است\&. به‌طور پیش‌فرض برابر با مقدار diff\&.renames است\&.
.RE
.PP
\fBmerge\&.directoryRenames\fR
.RS 4
اینکه آیا گیت تغییر نام دایرکتوری‌ها را تشخیص دهد یا خیر، که بر آنچه در زمان ادغام برای فایل‌های جدید اضافه‌شده به یک دایرکتوری در یک طرف تاریخچه روی می‌دهد هنگامی که آن دایرکتوری در طرف دیگر تاریخچه تغییر نام یافته است تأثیر می‌گذارد\&. مقادیر مجاز عبارتند از:
.PP
\fBfalse\fR
.RS 4
تشخیص تغییر نام دایرکتوری غیرفعال است؛ بدین معنا که چنین فایل‌های جدیدی در دایرکتوری قدیمی باقی می‌مانند\&.
.RE
.PP
\fBtrue\fR
.RS 4
تشخیص تغییر نام دایرکتوری فعال است؛ بدین معنا که چنین فایل‌های جدیدی به دایرکتوری جدید منتقل می‌شوند\&.
.RE
.PP
\fBconflict\fR
.RS 4
برای چنین مسیرهایی یک تداخل گزارش خواهد شد\&.
.RE
.sp
اگر
\fBmerge\&.renames\fR
برابر
\fBfalse\fR
باشد،
\fBmerge\&.directoryRenames\fR
نادیده گرفته شده و مانند
\fBfalse\fR
در نظر گرفته می‌شود\&. پیش‌فرض برابر
\fBconflict\fR
است\&.
.RE
.PP
\fBmerge\&.renormalize\fR
.RS 4
به گیت اعلام می‌کند که شکل استاندارد (canonical) فایل‌ها در مخزن در طول زمان تغییر کرده است (به‌عنوان مثال، کامیت‌های قبلی فایل‌های متنی را با انتهای خط
\fICRLF\fR
ثبت کرده‌اند، اما کامیت‌های جدیدتر از انتهای خط
\fILF\fR
استفاده می‌کنند)\&. در چنین مخزنی، برای هر فایلی که در آن به یک ادغام محتوایی سه‌طرفه نیاز است، گیت می‌تواند داده‌های ثبت‌شده در کامیت‌ها را پیش از اجرای ادغام به یک شکل استاندارد تبدیل کند تا تداخل‌های غیرضروری کاهش یابد\&. برای اطلاعات بیشتر، بخش "Merging branches with differing checkin/checkout attributes" در
\fBgitattributes\fR(5)
را ببینید\&.
.RE
.PP
\fBmerge\&.stat\fR
.RS 4
مشخص می‌کند در پایان ادغام، چه چیزی (در صورت وجود) بین
\fBORIG_HEAD\fR
و نتیجه ادغام چاپ شود\&. مقادیر ممکن عبارتند از:
.PP
\fBfalse\fR
.RS 4
هیچ‌چیزی نشان داده نشود\&.
.RE
.PP
\fBtrue\fR
.RS 4
دستور
\fBgit\fR
\fBdiff\fR
\fB\-\-diffstat\fR
\fB\-\-summary\fR
\fBORIG_HEAD\fR
نمایش داده شود\&.
.RE
.PP
\fBcompact\fR
.RS 4
دستور
\fBgit\fR
\fBdiff\fR
\fB\-\-compact\-summary\fR
\fBORIG_HEAD\fR
نمایش داده شود\&.
.RE
.sp
اما هر مقدار ناشناخته (مثلاً مقداری که در نسخه‌های بعدی گیت اضافه شده است) به جای ایجاد خطا، برابر با
\fBtrue\fR
در نظر گرفته می‌شود\&. پیش‌فرض برابر
\fBtrue\fR
است\&.
.RE
.PP
\fBmerge\&.autoStash\fR
.RS 4
هنگامی که روی
\fBtrue\fR
تنظیم شود، پیش از شروع عملیات به‌طور خودکار یک مدخل اندوخته (stash) موقت ایجاد کرده و پس از پایان عملیات آن را اعمال می‌کند\&. این بدان معناست که می‌توانید ادغام را روی یک درخت کاری دارای تغییرات ذخیره‌نشده (dirty) اجرا کنید\&. با این حال، با احتیاط استفاده کنید: اعمال نهایی اندوخته پس از یک ادغام موفق ممکن است به تداخل‌های غیرساده منجر شود\&. این گزینه می‌تواند توسط گزینه‌های
\fB\-\-no\-autostash\fR
و
\fB\-\-autostash\fR
از
\fBgit-merge\fR(1)
بازنویسی شود\&. به‌طور پیش‌فرض برابر
\fBfalse\fR
است\&.
.RE
.PP
\fBmerge\&.tool\fR
.RS 4
کنترل می‌کند که کدام ابزار ادغام توسط
\fBgit-mergetool\fR(1)
استفاده شود\&. فهرست زیر مقادیر معتبر توکار (built\-in) را نشان می‌دهد\&. هر مقدار دیگری به عنوان یک ابزار ادغام سفارشی در نظر گرفته شده و مستلزم آن است که متغیر متناظر
\fBmergetool\&.\fR\fI\fR\fB\&.cmd\fR
تعریف شده باشد\&.
.RE
.PP
\fBmerge\&.guitool\fR
.RS 4
کنترل می‌کند که کدام ابزار ادغام توسط
\fBgit-mergetool\fR(1)
هنگامی که پرچم
\fB\-g\fR/\fB\-\-gui\fR
مشخص شده است استفاده شود\&. فهرست زیر مقادیر معتبر توکار را نشان می‌دهد\&. هر مقدار دیگری به عنوان یک ابزار ادغام سفارشی در نظر گرفته می‌شود و مستلزم آن است که متغیر مربوطهٔ
\fBmergetool\&.\fR\fI\fR\fB\&.cmd\fR
تعریف شده باشد\&.
.PP
\fBaraxis\fR
.RS 4
استفاده از Araxis Merge (نیازمند نشست گرافیکی است)
.RE
.PP
\fBbc\fR
.RS 4
استفاده از Beyond Compare (نیازمند نشست گرافیکی است)
.RE
.PP
\fBbc3\fR
.RS 4
استفاده از Beyond Compare (نیازمند نشست گرافیکی است)
.RE
.PP
\fBbc4\fR
.RS 4
استفاده از Beyond Compare (نیازمند نشست گرافیکی است)
.RE
.PP
\fBcodecompare\fR
.RS 4
استفاده از Code Compare (نیازمند نشست گرافیکی است)
.RE
.PP
\fBdeltawalker\fR
.RS 4
استفاده از DeltaWalker (نیازمند نشست گرافیکی است)
.RE
.PP
\fBdiffmerge\fR
.RS 4
استفاده از DiffMerge (نیازمند نشست گرافیکی است)
.RE
.PP
\fBdiffuse\fR
.RS 4
استفاده از Diffuse (نیازمند نشست گرافیکی است)
.RE
.PP
\fBecmerge\fR
.RS 4
استفاده از ECMerge (نیازمند نشست گرافیکی است)
.RE
.PP
\fBemerge\fR
.RS 4
استفاده از Emerge در Emacs
.RE
.PP
\fBexamdiff\fR
.RS 4
استفاده از ExamDiff Pro (نیازمند نشست گرافیکی است)
.RE
.PP
\fBguiffy\fR
.RS 4
استفاده از ابزار تفاضل Guiffy (نیازمند نشست گرافیکی است)
.RE
.PP
\fBgvimdiff\fR
.RS 4
استفاده از gVim (نیازمند نشست گرافیکی است) با چیدمان سفارشی (بخش
\fBBACKEND\fR
\fBSPECIFIC\fR
\fBHINTS\fR
از
\fBgit\fR
\fBhelp\fR
\fBmergetool\fR
را ببینید)
.RE
.PP
\fBgvimdiff1\fR
.RS 4
استفاده از gVim (نیازمند نشست گرافیکی است) با چیدمان ۲ قاب (LOCAL و REMOTE)
.RE
.PP
\fBgvimdiff2\fR
.RS 4
استفاده از gVim (نیازمند نشست گرافیکی است) با چیدمان ۳ قاب (LOCAL، MERGED و REMOTE)
.RE
.PP
\fBgvimdiff3\fR
.RS 4
استفاده از gVim (نیازمند نشست گرافیکی است) که در آن فقط فایل MERGED نشان داده می‌شود
.RE
.PP
\fBkdiff3\fR
.RS 4
استفاده از KDiff3 (نیازمند نشست گرافیکی است)
.RE
.PP
\fBmeld\fR
.RS 4
استفاده از Meld (نیازمند نشست گرافیکی است) با
\fBauto\fR
\fBmerge\fR
اختیاری (بخش
\fBCONFIGURATION\fR
از
\fBgit\fR
\fBhelp\fR
\fBmergetool\fR
را ببینید)
.RE
.PP
\fBnvimdiff\fR
.RS 4
استفاده از Neovim با چیدمان سفارشی (بخش
\fBBACKEND\fR
\fBSPECIFIC\fR
\fBHINTS\fR
از
\fBgit\fR
\fBhelp\fR
\fBmergetool\fR
را ببینید)
.RE
.PP
\fBnvimdiff1\fR
.RS 4
استفاده از Neovim با چیدمان ۲ قاب (LOCAL و REMOTE)
.RE
.PP
\fBnvimdiff2\fR
.RS 4
استفاده از Neovim با چیدمان ۳ قاب (LOCAL، MERGED و REMOTE)
.RE
.PP
\fBnvimdiff3\fR
.RS 4
استفاده از Neovim که در آن فقط فایل MERGED نشان داده می‌شود
.RE
.PP
\fBopendiff\fR
.RS 4
استفاده از FileMerge (نیازمند نشست گرافیکی است)
.RE
.PP
\fBp4merge\fR
.RS 4
استفاده از HelixCore P4Merge (نیازمند نشست گرافیکی است)
.RE
.PP
\fBsmerge\fR
.RS 4
استفاده از Sublime Merge (نیازمند نشست گرافیکی است)
.RE
.PP
\fBtkdiff\fR
.RS 4
استفاده از TkDiff (نیازمند نشست گرافیکی است)
.RE
.PP
\fBtortoisemerge\fR
.RS 4
استفاده از TortoiseMerge (نیازمند نشست گرافیکی است)
.RE
.PP
\fBvimdiff\fR
.RS 4
استفاده از Vim با چیدمان سفارشی (بخش
\fBBACKEND\fR
\fBSPECIFIC\fR
\fBHINTS\fR
از
\fBgit\fR
\fBhelp\fR
\fBmergetool\fR
را ببینید)
.RE
.PP
\fBvimdiff1\fR
.RS 4
استفاده از Vim با چیدمان ۲ قاب (LOCAL و REMOTE)
.RE
.PP
\fBvimdiff2\fR
.RS 4
استفاده از Vim با چیدمان ۳ قاب (LOCAL، MERGED و REMOTE)
.RE
.PP
\fBvimdiff3\fR
.RS 4
استفاده از Vim که در آن فقط فایل MERGED نشان داده می‌شود
.RE
.PP
\fBvscode\fR
.RS 4
استفاده از Visual Studio Code (نیازمند نشست گرافیکی است)
.RE
.PP
\fBwinmerge\fR
.RS 4
استفاده از WinMerge (نیازمند نشست گرافیکی است)
.RE
.PP
\fBxxdiff\fR
.RS 4
استفاده از xxdiff (نیازمند نشست گرافیکی است)
.RE
.RE
.PP
\fBmerge\&.verbosity\fR
.RS 4
میزان خروجی نشان‌داده‌شده توسط راهبرد ادغام بازگشتی را کنترل می‌کند\&. سطح ۰ هیچ چیزی به جز یک پیام خطای نهایی در صورت شناسایی تعارض‌ها خروجی نمی‌دهد\&. سطح ۱ تنها تعارض‌ها را خروجی می‌دهد، ۲ تعارض‌ها و تغییرات فایل را خروجی می‌دهد\&. سطح ۵ و بالاتر اطلاعات اشکال‌زدایی را خروجی می‌دهد\&. پیش‌فرض، سطح ۲ است\&. می‌تواند توسط متغیر محیطی
\fBGIT_MERGE_VERBOSITY\fR
بازنویسی شود\&.
.RE
.PP
\fBmerge\&.\fR\fI\fR\fB\&.name\fR
.RS 4
یک نام قابل خواندن برای انسان را برای یک درایور ادغام سطح‌پایین سفارشی تعریف می‌کند\&. برای جزئیات به
\fBgitattributes\fR(5)
مراجعه کنید\&.
.RE
.PP
\fBmerge\&.\fR\fI\fR\fB\&.driver\fR
.RS 4
دستوری را که یک درایور ادغام سطح‌پایین سفارشی را پیاده‌سازی می‌کند تعریف می‌نماید\&. برای جزئیات به
\fBgitattributes\fR(5)
مراجعه کنید\&.
.RE
.PP
\fBmerge\&.\fR\fI\fR\fB\&.recursive\fR
.RS 4
نام یک درایور ادغام سطح‌پایین را برای استفاده در هنگام انجام ادغام داخلی میان نیاکان مشترک تعیین می‌کند\&. برای جزئیات به
\fBgitattributes\fR(5)
مراجعه کنید\&.
.RE
.SH "همچنین ببینید (SEE ALSO)"
.sp
\fBgit-fmt-merge-msg\fR(1), \fBgit-pull\fR(1), \fBgitattributes\fR(5), \fBgit-reset\fR(1), \fBgit-diff\fR(1), \fBgit-ls-files\fR(1), \fBgit-add\fR(1), \fBgit-rm\fR(1), \fBgit-mergetool\fR(1)
.SH "گیت (GIT)"
.sp
بخشی از مجموعه \fBgit\fR(1)