GIT-MERGE(1)                      Git Manual                      GIT-MERGE(1)

نام (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 قادر به
       بازسازی تغییرات اولیه (پیش از ادغام) نخواهد بود. بنابراین:

           هشدار

           اجرای git merge همراه با تغییرات ثبت‌نشدهٔ مهم توصیه نمی‌شود: هرچند
           این کار امکان‌پذیر است، اما در صورت بروز تعارض ممکن است شما را در
           وضعیتی قرار دهد که بازگشت از آن دشوار باشد.

گزینه‌ها (OPTIONS)
       --commit, --no-commit
           ادغام را انجام داده و نتیجه را کامیت می‌کند. از این گزینه می‌توان
           برای لغو اثر --no-commit استفاده کرد.

           با --no-commit ادغام را انجام داده و درست پیش از ایجاد کامیت ادغام
           متوقف می‌شود، تا به کاربر فرصت بازبینی و اصلاح بیشتر نتیجه ادغام پیش
           از کامیت کردن داده شود.

           توجه داشته باشید که به‌روزرسانی‌های فست‌فوروارد (fast-forward) کامیت
           ادغام ایجاد نمی‌کنند و بنابراین راهی برای متوقف کردن این ادغام‌ها با
           --no-commit وجود ندارد. از این رو، اگر می‌خواهید مطمئن شوید که شاخه
           شما توسط دستور ادغام تغییر نکرده یا به‌روزرسانی نمی‌شود، از --no-ff
           همراه با --no-commit استفاده کنید.

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

           اسکریپت‌های قدیمی‌تر ممکن است به رفتار تاریخی عدم اجازه به کاربر برای
           ویرایش پیام لاگ ادغام وابسته باشند. آن‌ها هنگام اجرای git merge باز
           شدن یک ویرایشگر را مشاهده خواهند کرد. برای آسان‌تر کردن تطبیق چنین
           اسکریپت‌هایی با رفتار به‌روزرسانی‌شده، متغیر محیطی GIT_MERGE_AUTOEDIT
           می‌تواند در ابتدای آن‌ها روی no تنظیم شود.

       --cleanup=<mode>
           این گزینه تعیین می‌کند که پیام ادغام پیش از کامیت چگونه پاک‌سازی شود.
           برای جزئیات بیشتر git-commit(1) را ببینید. علاوه بر این، اگر به
           <mode> مقدار scissors داده شود، در صورت بروز تداخل ادغام، خط قیچی
           (scissors) پیش از ارسال به سازوکار کامیت به MERGE_MSG اضافه خواهد
           شد.

       --ff, --no-ff, --ff-only
           مشخص می‌کند در صورتی که تاریخچه ادغام‌شده از قبل از نوادگان تاریخچه
           کنونی باشد، ادغام چگونه مدیریت شود.  --ff حالت پیش‌فرض است مگر اینکه
           یک برچسب (tag) دارای یادداشت (و احتمالاً امضاشده) ادغام شود که در
           جایگاه طبیعی خود در سلسله‌مراتب refs/tags/ ذخیره نشده است، که در این
           حالت --no-ff فرض می‌شود.

           با --ff، در صورت امکان، ادغام را به‌صورت فست‌فوروارد حل می‌کند (تنها
           اشاره‌گر شاخه را مطابق با شاخه ادغام‌شده به‌روزرسانی می‌کند؛ کامیت
           ادغام ایجاد نمی‌کند). در صورت عدم امکان (زمانی که تاریخچه ادغام‌شده
           از نوادگان تاریخچه کنونی نباشد)، یک کامیت ادغام ایجاد می‌کند.

           با --no-ff، در تمام موارد یک کامیت ادغام ایجاد می‌کند، حتی زمانی که
           ادغام می‌توانست در عوض به‌صورت فست‌فوروارد حل شود.

           با --ff-only، در صورت امکان ادغام را به‌صورت فست‌فوروارد حل می‌کند. در
           صورت عدم امکان، از ادغام امتناع کرده و با وضعیت غیرصفر خارج می‌شود.

       -S[<key-id>], --gpg-sign[=<key-id>], --no-gpg-sign
           کامیت ادغام حاصل را با GPG امضا می‌کند. آرگومان <key-id> اختیاری است
           و پیش‌فرض آن هویت کامیت‌کننده است؛ در صورت تعیین، باید بدون فاصله به
           گزینه متصل باشد.  --no-gpg-sign برای باطل کردن هم متغیر پیکربندی
           commit.gpgSign و هم گزینه قبلی --gpg-sign مفید است.

       --log[=<n>], --no-log
           علاوه بر نام شاخه‌ها، پیام لاگ را با توضیحات یک‌خطی از حداکثر <n>
           کامیت واقعی که در حال ادغام هستند پر می‌کند. همچنین git-fmt-merge-
           msg(1) را ببینید.

           با --no-log توضیحات یک‌خطی کامیت‌های واقعی در حال ادغام را فهرست
           نمی‌کند.

       --signoff, --no-signoff
           یک دنباله (trailer) Signed-off-by توسط کامیت‌کننده در انتهای پیام
           لاگ کامیت اضافه می‌کند. معنای signoff به پروژه‌ای که در آن کامیت
           می‌کنید بستگی دارد. برای مثال، ممکن است گواهی دهد که کامیت‌کننده حق
           ارسال اثر تحت پروانه پروژه را دارد یا با برخی از بیانیه‌های
           مشارکت‌کنندگان، مانند «گواهی مبدا توسعه‌دهنده» (Developer Certificate
           of Origin) موافقت می‌کند. (برای نمونه مورد استفاده توسط هسته لینوکس
           و پروژه‌های گیت، https://developercertificate.org را ببینید.) برای
           درک نحوه استفاده از signoffها در پروژه‌ای که در آن مشارکت می‌کنید، با
           مستندات یا راهبری آن پروژه مشورت کنید.

           گزینه --no-signoff می‌تواند برای باطل کردن گزینه قبلی --signoff در
           خط فرمان استفاده شود.

           گیت یک متغیر پیکربندی برای فعال کردن گزینه خط فرمان --signoff به
           صورت پیش‌فرض ندارد (و نخواهد داشت)؛ برای جزئیات بیشتر ورودی
           commit.signoff را در gitfaq(7) ببینید.

       --stat, -n, --no-stat
           یک diffstat در پایان ادغام نمایش می‌دهد. این diffstat همچنین توسط
           گزینه پیکربندی merge.stat کنترل می‌شود.

           با -n یا --no-stat در پایان ادغام diffstat نشان داده نمی‌شود.

       --compact-summary
           یک خلاصه فشرده (compact-summary) در پایان ادغام نمایش می‌دهد.

       --squash, --no-squash
           وضعیت درخت کاری و نمایه را به‌گونه‌ای ایجاد می‌کند که گویی یک ادغام
           واقعی رخ داده است (به‌جز اطلاعات ادغام)، اما در واقع کامیتی ایجاد
           نمی‌کند، HEAD را جابجا نمی‌کند، یا $GIT_DIR/MERGE_HEAD را ثبت نمی‌کند
           (تا باعث شود دستور بعدی git commit یک کامیت ادغام ایجاد کند). این
           به شما امکان می‌دهد تا یک کامیت منفرد بر روی شاخه کنونی بسازید که
           تأثیر آن همانند ادغام یک شاخه دیگر (یا بیشتر در حالت ادغام چندگانه
           یا اختاپوس) است.

           با --no-squash ادغام را انجام داده و نتیجه را کامیت می‌کند. این
           گزینه می‌تواند برای لغو اثر --squash استفاده شود.

           با --squash، استفاده از --commit مجاز نبوده و ناموفق خواهد بود.

       --verify, --no-verify
           به‌طور پیش‌فرض، قلاب‌های pre-merge و commit-msg اجرا می‌شوند. هنگامی که
           --no-verify مشخص شود، این قلاب‌ها دور زده می‌شوند. همچنین githooks(5)
           را ببینید.

       -s <strategy>, --strategy=<strategy>
           از راهبرد ادغام داده‌شده استفاده می‌کند؛ می‌تواند بیش از یک بار مشخص
           شود تا به ترتیبی که باید امتحان شوند تعیین گردند. اگر گزینه -s مشخص
           نشود، یک فهرست درونی از راهبردها استفاده می‌شود (ort هنگام ادغام یک
           سر (head) منفرد، و در غیر این صورت octopus).

       -X <option>, --strategy-option=<option>
           گزینه خاص راهبرد ادغام را به راهبرد ادغام ارسال می‌کند.

       --verify-signatures, --no-verify-signatures
           بررسی و تأیید می‌کند که کامیت رأس شاخه جانبی در حال ادغام با یک کلید
           معتبر امضا شده باشد، یعنی کلیدی که دارای شناسه کاربری (uid) معتبر
           است: در مدل اعتماد پیش‌فرض، این بدان معناست که کلید امضاکننده توسط
           یک کلید مورد اعتماد امضا شده است. اگر کامیت رأس شاخه جانبی با کلید
           معتبر امضا نشده باشد، ادغام لغو می‌شود.

       --summary, --no-summary
           مترادف‌هایی برای --stat و --no-stat؛ این گزینه‌ها منسوخ شده‌اند و در
           آینده حذف خواهند شد.

       -q, --quiet
           عملیات را در حالت ساکت انجام می‌دهد. این گزینه متضمن --no-progress
           است.

       -v, --verbose
           با جزئیات کامل اجرا می‌شود.

       --progress, --no-progress
           نمایش پیشرفت را به‌طور صریح فعال یا غیرفعال می‌کند. اگر هیچ‌کدام مشخص
           نشوند، در صورتی که جریان خطای استاندارد به یک ترمینال متصل باشد،
           پیشرفت نمایش داده می‌شود. توجه داشته باشید که ممکن است همه راهبردهای
           ادغام از گزارش پیشرفت پشتیبانی نکنند.

       --autostash, --no-autostash
           به‌طور خودکار پیش از شروع عملیات یک مدخل اندوخته (stash) موقت ایجاد
           کرده، آن را در ارجاع MERGE_AUTOSTASH ثبت می‌کند و پس از پایان عملیات
           اعمال می‌نماید. این بدان معناست که می‌توانید عملیات را روی یک درخت
           کاری با تغییرات ذخیره‌نشده (dirty) اجرا کنید. با این حال با احتیاط
           استفاده کنید: اعمال نهایی اندوخته پس از یک ادغام موفق ممکن است به
           تداخل‌های پیچیده منجر شود.

       --allow-unrelated-histories
           به‌طور پیش‌فرض، دستور git merge از ادغام تاریخچه‌هایی که جد مشترکی
           ندارند خودداری می‌کند. از این گزینه می‌توان برای لغو این تدبیر ایمنی
           هنگام ادغام تاریخچه‌های دو پروژه‌ای که زندگی خود را به‌طور مستقل آغاز
           کرده‌اند استفاده کرد. از آنجا که این یک رویداد بسیار نادر است، هیچ
           متغیر پیکربندی برای فعال کردن پیش‌فرض آن وجود ندارد یا افزوده نخواهد
           شد.

       -m <msg>
           پیام کامیت مورد استفاده برای کامیت ادغام را تنظیم می‌کند (در صورتی
           که ایجاد شود).

           اگر --log مشخص شده باشد، یک گزارش کوتاه (shortlog) از کامیت‌های در
           حال ادغام به پیام مشخص‌شده ضمیمه خواهد شد.

           دستور git fmt-merge-msg می‌تواند برای ارائه یک پیش‌فرض مناسب در
           فراخوانی‌های خودکار git merge استفاده شود. پیام خودکار می‌تواند شامل
           توضیحات شاخه باشد.

       --into-name <branch>
           پیام ادغام پیش‌فرض را به گونه‌ای آماده می‌کند که گویی ادغام در شاخه
           <branch> انجام می‌شود، به جای نام شاخه واقعی که ادغام در آن صورت
           می‌گیرد.

       -F <file>, --file=<file>
           پیام کامیت مورد استفاده برای کامیت ادغام را می‌خواند (در صورتی که
           ایجاد شود).

           اگر --log مشخص شده باشد، یک گزارش کوتاه (shortlog) از کامیت‌های در
           حال ادغام به پیام مشخص‌شده ضمیمه خواهد شد.

       --rerere-autoupdate, --no-rerere-autoupdate
           پس از اینکه سازوکار rerere از یک راه‌حل ثبت‌شده برای تداخل فعلی جهت
           به‌روزرسانی فایل‌ها در درخت کاری استفاده کرد، به آن اجازه می‌دهد تا
           نمایه را نیز با نتیجه حل تداخل به‌روز کند. گزینه
           --no-rerere-autoupdate راه خوبی برای بررسی مجدد کاری است که git-
           rerere(1) انجام داده تا خطاهای احتمالی در ادغام را قبل از کامیت
           کردن نتیجه در نمایه با یک دستور جداگانه git-add(1) شناسایی کند.

       --overwrite-ignore, --no-overwrite-ignore
           فایل‌های نادیده‌گرفته‌شده را بی‌صدا با نتیجه ادغام بازنویسی می‌کند. این
           رفتار پیش‌فرض است. برای لغو عملیات از --no-overwrite-ignore استفاده
           کنید.

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

           اگر هنگام شروع ادغام، تغییرات کامیت‌نشده‌ای در درخت کاری وجود داشته
           باشد، دستور git merge --abort در برخی موارد قادر به بازسازی این
           تغییرات نخواهد بود. بنابراین توصیه می‌شود که همواره پیش از اجرای git
           merge، تغییرات خود را کامیت یا اندوخته (stash) کنید.

           دستور git merge --abort هنگامی که MERGE_HEAD وجود داشته باشد، معادل
           دستور git reset --merge است، مگر اینکه MERGE_AUTOSTASH نیز وجود
           داشته باشد که در این صورت git merge --abort مدخل اندوخته را روی
           درخت کاری اعمال می‌کند، در حالی که git reset --merge تغییرات
           اندوخته‌شده را در فهرست اندوخته‌ها ذخیره خواهد کرد.

       --quit
           عملیات ادغام جاری در حال انجام را رها می‌کند. نمایه و درخت کاری را
           دست‌نخورده به همان حالت باقی می‌گذارد. اگر MERGE_AUTOSTASH وجود داشته
           باشد، مدخل اندوخته در فهرست اندوخته‌ها ذخیره خواهد شد.

       --continue
           پس از اینکه یک دستور git merge به دلیل تداخل‌ها متوقف شد، می‌توانید
           با اجرای دستور git merge --continue ادغام را به پایان برسانید (بخش
           «نحوه حل تضادها (HOW TO RESOLVE CONFLICTS)» در زیر را ببینید).

       <commit>...
           کامیت‌ها، معمولاً سرِ شاخه‌های دیگر، جهت ادغام در شاخه ما. مشخص کردن
           بیش از یک کامیت، ادغامی با بیش از دو والد ایجاد خواهد کرد (که به
           اصطلاح ادغام اختاپوسی یا Octopus merge نامیده می‌شود).

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

           هنگامی که FETCH_HEAD (و هیچ کامیت دیگری) مشخص شود، شاخه‌های ثبت‌شده
           در فایل .git/FETCH_HEAD توسط فراخوانی قبلی git fetch برای ادغام، در
           شاخه جاری ادغام می‌شوند.

پیش‌درآمد (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، ایندکس و درخت کاری شما مطابق با آن
       به‌روزرسانی می‌شوند. وجود تغییرات در درخت کاری تا زمانی که با تغییرات
       ادغام هم‌پوشانی نداشته باشند مجاز است؛ عملیات به‌روزرسانی آن‌ها را حفظ
       خواهد کرد.

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

        1. اشاره‌گر HEAD بدون تغییر باقی می‌ماند.

        2. ارجاع MERGE_HEAD تنظیم می‌شود تا به سرِ شاخه دیگر اشاره کند.

        3. مسیرهایی که بدون تعارض ادغام شده‌اند، هم در فایل ایندکس و هم در درخت
           کاری شما به‌روزرسانی می‌شوند.

        4. برای مسیرهای دارای تعارض، فایل ایندکس حداکثر سه نسخه را ثبت می‌کند:
           مرحله ۱ نسخه مربوط به جد مشترک را ذخیره می‌کند، مرحله ۲ نسخه مربوط
           به HEAD، و مرحله ۳ نسخه مربوط به MERGE_HEAD (می‌توانید این مراحل را
           با git ls-files -u بررسی کنید). فایل‌های درخت کاری حاوی نتیجه عملیات
           ادغام خواهند بود؛ یعنی نتایج ادغام ۳-طرفه با نشانگرهای آشنای تعارض
           <<< === >>>.

        5. یک ارجاع به نام AUTO_MERGE نوشته می‌شود که به درختی متناظر با محتوای
           فعلی درخت کاری اشاره می‌کند (شامل نشانگرهای تعارض برای تعارض‌های
           متنی). توجه داشته باشید که این ارجاع تنها زمانی نوشته می‌شود که از
           استراتژی ادغام ort (پیش‌فرض) استفاده شود.

        6. هیچ تغییر دیگری اعمال نمی‌شود. به‌ویژه، تغییرات محلی که پیش از شروع
           ادغام داشته‌اید بدون تغییر باقی می‌مانند و ورودی‌های ایندکس مربوط به
           آن‌ها همان‌طور که بودند حفظ می‌شوند، یعنی مطابق با 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)
       پس از مشاهده تضاد، می‌توانید دو کار انجام دهید:

       •   تصمیم به عدم ادغام بگیرید. تنها پاک‌سازی‌هایی که نیاز دارید، بازنشانی
           فایل نمایه به کامیت HEAD برای بازگرداندن مورد ۲ و پاک‌سازی تغییرات
           درخت کاری ایجادشده توسط موارد ۲ و ۳ است؛ برای این کار می‌توان از git
           merge --abort استفاده کرد.

       •   تضادها را حل کنید. گیت تضادها را در درخت کاری مشخص می‌کند. فایل‌ها را
           ویرایش و اصلاح کرده و با git add آن‌ها را به نمایه اضافه کنید. برای
           نهایی کردن کار از git commit یا git merge --continue استفاده کنید.
           دستور دوم پیش از فراخوانی git commit، بررسی می‌کند که آیا یک ادغام
           (متوقف‌شده) در جریان است یا خیر.

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

       •   از یک ابزار ادغام (mergetool) استفاده کنید.  دستور git mergetool
           برای اجرای یک ابزار گرافیکی حل ادغام است که مراحل ادغام را همراه با
           شما انجام می‌دهد.

       •   تفاوت‌ها (diff) را بررسی کنید.  دستور git diff یک تفاوت سه‌طرفه را
           نشان می‌دهد و تغییرات هر دو نسخه HEAD و MERGE_HEAD را برجسته می‌سازد.
           دستور git diff AUTO_MERGE تغییراتی را نشان می‌دهد که تاکنون برای حل
           تضادهای متنی اعمال کرده‌اید.

       •   تفاوت‌های هر شاخه را بررسی کنید.  دستور git log --merge -p <path>
           ابتدا تفاوت‌ها را برای نسخه HEAD و سپس برای نسخه MERGE_HEAD نشان
           می‌دهد.

       •   نسخه‌های اصلی را بررسی کنید.  دستور git show :1:filename نسخه نیای
           مشترک را نشان می‌دهد، git show :2:filename نسخه HEAD را نشان می‌دهد،
           و git show :3:filename نسخه MERGE_HEAD را نشان می‌دهد.

مثال‌ها (EXAMPLES)
       •   ادغام شاخه‌های fixes و enhancements روی شاخه جاری، با ایجاد یک ادغام
           هشت‌پا (octopus merge):

               $ git merge fixes enhancements


       •   ادغام شاخه obsolete در شاخه جاری، با استفاده از استراتژی ادغام
           ours:

               $ git merge -s ours obsolete


       •   ادغام شاخه maint در شاخه جاری، اما بدون ایجاد خودکار یک کامیت جدید:

               $ git merge --no-commit maint

           از این حالت می‌توان زمانی استفاده کرد که بخواهید تغییرات بیشتری را
           در ادغام بگنجانید، یا بخواهید پیام کامیت ادغام را خودتان بنویسید.

           باید از سوءاستفاده از این گزینه برای وارد کردن مخفیانه تغییرات
           اساسی به یک کامیت ادغام خودداری کنید. اصلاحات جزئی مانند ارتقای نام
           انتشار/نسخه قابل قبول خواهد بود.

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

       ort
           این استراتژی پیش‌فرض ادغام هنگام دریافت (pull) یا ادغام یک شاخه است.
           این استراتژی فقط می‌تواند دو سرشاخه را با استفاده از الگوریتم ادغام
           ۳-طرفه حل کند. هنگامی که بیش از یک والد مشترک وجود داشته باشد که
           بتوان برای ادغام ۳-طرفه از آن استفاده کرد، درختی ادغام‌شده از والدین
           مشترک ایجاد می‌کند و از آن به‌عنوان درخت مرجع برای ادغام ۳-طرفه بهره
           می‌برد. بر اساس آزمایش‌های انجام‌شده روی کامیت‌های ادغام واقعی برگرفته
           از تاریخچه توسعه هسته لینوکس ۲.۶، گزارش شده است که این روش منجر به
           تعارض‌های ادغام کمتر بدون ایجاد ادغام‌های نادرست می‌شود. علاوه بر این،
           این استراتژی می‌تواند ادغام‌های شامل تغییر نام را شناسایی و مدیریت
           کند. این استراتژی از کپی‌های شناسایی‌شده استفاده نمی‌کند. نام این
           الگوریتم یک کوته‌نوشت ("Ostensibly Recursive’s Twin") است و از این
           واقعیت ناشی می‌شود که به‌عنوان جایگزینی برای الگوریتم پیش‌فرض قبلی
           نوشته شده است: recursive.

           در حالتی که مسیر مورد نظر یک زیرماژول است، اگر کامیت زیرماژول
           استفاده‌شده در یک طرف ادغام، نواده (descendant) کامیت زیرماژول
           استفاده‌شده در طرف دیگر ادغام باشد، گیت تلاش می‌کند تا به آن نواده
           فست‌فوروارد کند. در غیر این صورت، گیت این حالت را به‌عنوان یک تعارض
           در نظر می‌گیرد و کامیت زیرماژولی را که نواده کامیت‌های دارای تعارض
           است (در صورت وجود) به‌عنوان راه‌حل پیشنهاد می‌کند.

           استراتژی ort می‌تواند گزینه‌های زیر را بپذیرد:

           ours
               این گزینه تکه‌های دارای تعارض (conflicting hunks) را مجبور می‌کند
               تا با اولویت دادن به نسخه ما (our) به‌طور خودکار و تمیز حل شوند.
               تغییرات درخت دیگر که با طرف ما تعارضی ندارند، در نتیجه ادغام
               منعکس می‌شوند. برای یک فایل باینری، کل محتوا از طرف ما گرفته
               می‌شود.

               این گزینه نباید با استراتژی ادغام ours اشتباه گرفته شود؛ آن
               استراتژی اصلاً به آنچه درخت دیگر شامل می‌شود نگاه نمی‌کند و هر
               کاری را که درخت دیگر انجام داده دور می‌اندازد و اعلام می‌کند که
               تاریخچه ما شامل تمام رویدادهایی است که در آن رخ داده است.

           theirs
               این گزینه برعکس ours است؛ توجه داشته باشید که بر خلاف ours، هیچ
               استراتژی ادغامی به نام theirs وجود ندارد که بتوان این گزینه
               ادغام را با آن اشتباه گرفت.

           ignore-space-change, ignore-all-space, ignore-space-at-eol,
           ignore-cr-at-eol
               خطوطی را که دارای نوع مشخص‌شده تغییرات در فاصله‌های خالی
               (whitespace) هستند، به منظور ادغام سه‌طرفه به‌عنوان خطوط بدون
               تغییر در نظر می‌گیرد. تغییرات فاصله‌های خالی که با تغییرات دیگر
               در یک خط ترکیب شده باشند، نادیده گرفته نمی‌شوند. همچنین به git-
               diff(1) -b، -w، --ignore-space-at-eol و --ignore-cr-at-eol
               مراجعه کنید.

               •   اگر نسخه آن‌ها (their) فقط تغییرات فاصله خالی را در یک خط
                   ایجاد کرده باشد، از نسخه ما (our) استفاده می‌شود؛

               •   اگر نسخه ما تغییرات فاصله خالی ایجاد کرده باشد اما نسخه
                   آن‌ها شامل یک تغییر اساسی باشد، از نسخه آن‌ها استفاده می‌شود؛

               •   در غیر این صورت، ادغام به روش معمول پیش می‌رود.

           renormalize
               این گزینه یک دریافت (check-out) و ثبت (check-in) مجازی از تمام
               سه مرحله هر فایلی که نیاز به ادغام سه‌طرفه دارد انجام می‌دهد. این
               گزینه برای استفاده هنگام ادغام شاخه‌هایی با فیلترهای پاکسازی
               متفاوت یا قوانین نرمال‌سازی انتهای خط متفاوت در نظر گرفته شده
               است. برای جزئیات به بخش "Merging branches with differing
               checkin/checkout attributes" در gitattributes(5) مراجعه کنید.

           no-renormalize
               گزینه renormalize را غیرفعال می‌کند. این گزینه متغیر پیکربندی
               merge.renormalize را بازنویسی (override) می‌کند.

           find-renames[=<n>]
               تشخیص تغییر نام را فعال می‌کند و به‌صورت اختیاری آستانه شباهت را
               تنظیم می‌نماید. این حالت پیش‌فرض است. این گزینه متغیر پیکربندی
               merge.renames را بازنویسی می‌کند. همچنین به git-diff(1)
               --find-renames مراجعه کنید.

           rename-threshold=<n>
               یک مترادف منسوخ‌شده برای find-renames=<n>.

           no-renames
               تشخیص تغییر نام را خاموش می‌کند. این گزینه متغیر پیکربندی
               merge.renames را بازنویسی می‌کند. همچنین به git-diff(1)
               --no-renames مراجعه کنید.

           histogram
               یک مترادف منسوخ‌شده برای diff-algorithm=histogram.

           patience
               یک مترادف منسوخ‌شده برای diff-algorithm=patience.

           diff-algorithm=(histogram|minimal|myers|patience)
               از یک الگوریتم تفاضل (diff) متفاوت هنگام ادغام استفاده می‌کند،
               که می‌تواند به جلوگیری از ادغام‌های نادرست که ناشی از خطوط منطبق
               کم‌اهمیت هستند (مانند براکت‌های توابع مجزا) کمک کند. همچنین به
               git-diff(1) --diff-algorithm مراجعه کنید. توجه داشته باشید که
               ort به‌طور پیش‌فرض از diff-algorithm=histogram استفاده می‌کند، در
               حالی که تفاضل‌های معمولی در حال حاضر به‌طور پیش‌فرض از تنظیمات
               پیکربندی diff.algorithm استفاده می‌نمایند.

           subtree[=<path>]
               این گزینه شکل پیشرفته‌تری از استراتژی subtree است که در آن
               استراتژی حدس می‌زند دو درخت چگونه باید نسبت به یکدیگر جابجا شوند
               تا هنگام ادغام با هم تطبیق یابند. در عوض، مسیر مشخص‌شده به
               ابتدای مسیرها اضافه می‌شود (یا از ابتدا حذف می‌شود) تا شکل دو
               درخت مطابقت پیدا کند.

       recursive
           این گزینه اکنون مترادفی برای ort است. تا نسخه 2.49.0 یک پیاده‌سازی
           جایگزین بود، اما در نسخه 2.50.0 تغییر مسیر یافت تا به معنای ort
           باشد. استراتژی بازگشتی قبلی، استراتژی پیش‌فرض برای حل دو سرشاخه از
           نسخه v0.99.9k گیت تا نسخه v2.33.0 بود.

       resolve
           این استراتژی فقط می‌تواند دو سرشاخه (یعنی شاخه جاری و شاخه دیگری که
           از آن دریافت کرده‌اید) را با استفاده از یک الگوریتم ادغام ۳-طرفه حل
           کند. این روش تلاش می‌کند تا ابهامات ادغام ضربدری (criss-cross) را با
           دقت شناسایی کند. این استراتژی تغییر نام‌ها را مدیریت نمی‌کند.

       octopus
           این استراتژی موارد با بیش از دو سرشاخه را حل می‌کند، اما از انجام یک
           ادغام پیچیده که نیاز به حل دستی داشته باشد خودداری می‌ورزد. این
           استراتژی عمدتاً برای دسته‌بندی سرشاخه‌های موضوعی (topic branches) در
           کنار هم استفاده می‌شود. این حالت، استراتژی ادغام پیش‌فرض هنگام دریافت
           (pull) یا ادغام بیش از یک شاخه است.

       ours
           این استراتژی هر تعداد سرشاخه را حل می‌کند، اما درخت حاصل از ادغام
           همیشه همان سرشاخه جاری است و در عمل تمام تغییرات از سایر شاخه‌ها را
           نادیده می‌گیرد. این روش برای جایگزین کردن تاریخچه توسعه قدیمی
           شاخه‌های فرعی در نظر گرفته شده است. توجه داشته باشید که این استراتژی
           با گزینه -Xours در استراتژی ادغام ort متفاوت است.

       subtree
           این یک استراتژی اصلاح‌شده از ort است. هنگام ادغام درخت‌های A و B، اگر
           B متناظر با یک زیردرخت از A باشد، B ابتدا طوری تنظیم می‌شود که با
           ساختار درختی A مطابقت داشته باشد، به‌جای اینکه درخت‌ها در همان سطح
           خوانده شوند. این تنظیم برای درخت والد مشترک نیز انجام می‌شود.

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

پیکربندی (CONFIGURATION)
       branch.<name>.mergeOptions
           گزینه‌های پیش‌فرض را برای ادغام در شاخه <name> تنظیم می‌کند. نحو و
           گزینه‌های پشتیبانی‌شده همانند موارد git merge هستند، اما مقادیر
           گزینه‌های حاوی نویسه‌های فاصله خالی در حال حاضر پشتیبانی نمی‌شوند.

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

       merge.conflictStyle
           سبکی را مشخص می‌کند که بر اساس آن بخش‌های دارای تداخل (hunks) هنگام
           ادغام در فایل‌های درخت کاری نوشته می‌شوند. مقدار پیش‌فرض "merge" است
           که یک نشانگر تداخل <<<<<<<، تغییرات اعمال‌شده توسط یک طرف، یک نشانگر
           =======، تغییرات اعمال‌شده توسط طرف دیگر، و سپس یک نشانگر >>>>>>> را
           نمایش می‌دهد. یک سبک جایگزین، "diff3"، یک نشانگر ||||||| و متن اصلی
           را قبل از نشانگر ======= می‌افزاید. سبک "merge" معمولاً ناحیه‌های
           تداخل کوچک‌تری نسبت به diff3 ایجاد می‌کند، هم به دلیل کنار گذاشتن متن
           اصلی، و هم به این دلیل که وقتی زیرمجموعه‌ای از خطوط در دو طرف یکسان
           باشند، صرفاً از ناحیه تداخل خارج می‌شوند. سبک جایگزین دیگر، "zdiff3"،
           شبیه به diff3 است اما خطوط منطبق در دو طرف را از ناحیه تداخل حذف
           می‌کند زمانی که آن خطوط منطبق در نزدیکی آغاز یا پایان ناحیه تداخل
           ظاهر شوند.

       merge.defaultToUpstream
           اگر merge بدون هیچ آرگومان کامیتی فراخوانی شود، شاخه‌های بالادست
           پیکربندی‌شده برای شاخه جاری را با استفاده از آخرین مقادیر مشاهده‌شده
           ذخیره‌شده در شاخه‌های ردیاب دوردست (remote-tracking) آن‌ها ادغام
           می‌کند. مقادیر branch.<current branch>.merge که نام شاخه‌ها را در
           مخزن دوردستِ مشخص‌شده توسط branch.<current-branch>.remote تعیین
           می‌کنند بررسی شده و سپس از طریق remote.<remote>.fetch به شاخه‌های
           ردیاب دوردست متناظر نگاشت می‌شوند و نوک (tip) این شاخه‌های ردیاب
           ادغام می‌گردند. به‌طور پیش‌فرض true است.

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

       merge.verifySignatures
           اگر true باشد، این معادل گزینه خط فرمان --verify-signatures است.
           برای جزئیات به git-merge(1) مراجعه کنید.

       merge.branchdesc
           علاوه بر نام شاخه‌ها، پیام لاگ را با متن توضیحات شاخه مرتبط با آن‌ها
           پر می‌کند. به‌طور پیش‌فرض false است.

       merge.log
           علاوه بر نام شاخه‌ها، پیام لاگ را با حداکثر تعداد مشخص‌شده از توضیحات
           یک‌خطی کامیت‌های واقعی در حال ادغام پر می‌کند. به‌طور پیش‌فرض false است،
           و true مترادفی برای 20 می‌باشد.

       merge.suppressDest
           با افزودن یک الگوی تطابق (glob) که با نام‌های شاخه‌های یکپارچه‌سازی
           مطابقت دارد به این متغیر پیکربندی چندمقداری، پیام ادغام پیش‌فرض
           محاسبه‌شده برای ادغام در این شاخه‌های یکپارچه‌سازی، عبارت "into
           <branch-name>" را از عنوان خود حذف می‌کند.

           یک عنصر با مقدار خالی می‌تواند برای پاک کردن فهرست الگوهای
           انباشته‌شده از مدخل‌های پیکربندی قبلی استفاده شود. هنگامی که هیچ
           متغیر merge.suppressDest تعریف نشده باشد، مقدار پیش‌فرض master برای
           سازگاری رو به عقب استفاده می‌شود.

       merge.renameLimit
           تعداد فایل‌هایی که در بخش جامع تشخیص تغییر نام در طول یک ادغام در
           نظر گرفته می‌شوند. در صورت مشخص نشدن، مقدار پیش‌فرض آن برابر مقدار
           diff.renameLimit است. اگر نه merge.renameLimit و نه
           diff.renameLimit مشخص نشده باشند، در حال حاضر مقدار پیش‌فرض برابر
           7000 است. اگر تشخیص تغییر نام غیرفعال باشد، این تنظیم هیچ تأثیری
           ندارد.

       merge.renames
           مشخص می‌کند که آیا گیت تغییر نام‌ها را تشخیص دهد یا خیر. اگر روی
           false تنظیم شود، تشخیص تغییر نام غیرفعال است. اگر روی true تنظیم
           شود، تشخیص پایه‌ای تغییر نام فعال است. به‌طور پیش‌فرض برابر با مقدار
           diff.renames است.

       merge.directoryRenames
           اینکه آیا گیت تغییر نام دایرکتوری‌ها را تشخیص دهد یا خیر، که بر آنچه
           در زمان ادغام برای فایل‌های جدید اضافه‌شده به یک دایرکتوری در یک طرف
           تاریخچه روی می‌دهد هنگامی که آن دایرکتوری در طرف دیگر تاریخچه تغییر
           نام یافته است تأثیر می‌گذارد. مقادیر مجاز عبارتند از:

           false
               تشخیص تغییر نام دایرکتوری غیرفعال است؛ بدین معنا که چنین
               فایل‌های جدیدی در دایرکتوری قدیمی باقی می‌مانند.

           true
               تشخیص تغییر نام دایرکتوری فعال است؛ بدین معنا که چنین فایل‌های
               جدیدی به دایرکتوری جدید منتقل می‌شوند.

           conflict
               برای چنین مسیرهایی یک تداخل گزارش خواهد شد.

           اگر merge.renames برابر false باشد، merge.directoryRenames نادیده
           گرفته شده و مانند false در نظر گرفته می‌شود. پیش‌فرض برابر conflict
           است.

       merge.renormalize
           به گیت اعلام می‌کند که شکل استاندارد (canonical) فایل‌ها در مخزن در
           طول زمان تغییر کرده است (به‌عنوان مثال، کامیت‌های قبلی فایل‌های متنی
           را با انتهای خط CRLF ثبت کرده‌اند، اما کامیت‌های جدیدتر از انتهای خط
           LF استفاده می‌کنند). در چنین مخزنی، برای هر فایلی که در آن به یک
           ادغام محتوایی سه‌طرفه نیاز است، گیت می‌تواند داده‌های ثبت‌شده در
           کامیت‌ها را پیش از اجرای ادغام به یک شکل استاندارد تبدیل کند تا
           تداخل‌های غیرضروری کاهش یابد. برای اطلاعات بیشتر، بخش "Merging
           branches with differing checkin/checkout attributes" در
           gitattributes(5) را ببینید.

       merge.stat
           مشخص می‌کند در پایان ادغام، چه چیزی (در صورت وجود) بین ORIG_HEAD و
           نتیجه ادغام چاپ شود. مقادیر ممکن عبارتند از:

           false
               هیچ‌چیزی نشان داده نشود.

           true
               دستور git diff --diffstat --summary ORIG_HEAD نمایش داده شود.

           compact
               دستور git diff --compact-summary ORIG_HEAD نمایش داده شود.

           اما هر مقدار ناشناخته (مثلاً مقداری که در نسخه‌های بعدی گیت اضافه شده
           است) به جای ایجاد خطا، برابر با true در نظر گرفته می‌شود. پیش‌فرض
           برابر true است.

       merge.autoStash
           هنگامی که روی true تنظیم شود، پیش از شروع عملیات به‌طور خودکار یک
           مدخل اندوخته (stash) موقت ایجاد کرده و پس از پایان عملیات آن را
           اعمال می‌کند. این بدان معناست که می‌توانید ادغام را روی یک درخت کاری
           دارای تغییرات ذخیره‌نشده (dirty) اجرا کنید. با این حال، با احتیاط
           استفاده کنید: اعمال نهایی اندوخته پس از یک ادغام موفق ممکن است به
           تداخل‌های غیرساده منجر شود. این گزینه می‌تواند توسط گزینه‌های
           --no-autostash و --autostash از git-merge(1) بازنویسی شود. به‌طور
           پیش‌فرض برابر false است.

       merge.tool
           کنترل می‌کند که کدام ابزار ادغام توسط git-mergetool(1) استفاده شود.
           فهرست زیر مقادیر معتبر توکار (built-in) را نشان می‌دهد. هر مقدار
           دیگری به عنوان یک ابزار ادغام سفارشی در نظر گرفته شده و مستلزم آن
           است که متغیر متناظر mergetool.<tool>.cmd تعریف شده باشد.

       merge.guitool
           کنترل می‌کند که کدام ابزار ادغام توسط git-mergetool(1) هنگامی که
           پرچم -g/--gui مشخص شده است استفاده شود. فهرست زیر مقادیر معتبر
           توکار را نشان می‌دهد. هر مقدار دیگری به عنوان یک ابزار ادغام سفارشی
           در نظر گرفته می‌شود و مستلزم آن است که متغیر مربوطهٔ
           mergetool.<guitool>.cmd تعریف شده باشد.

           araxis
               استفاده از Araxis Merge (نیازمند نشست گرافیکی است)

           bc
               استفاده از Beyond Compare (نیازمند نشست گرافیکی است)

           bc3
               استفاده از Beyond Compare (نیازمند نشست گرافیکی است)

           bc4
               استفاده از Beyond Compare (نیازمند نشست گرافیکی است)

           codecompare
               استفاده از Code Compare (نیازمند نشست گرافیکی است)

           deltawalker
               استفاده از DeltaWalker (نیازمند نشست گرافیکی است)

           diffmerge
               استفاده از DiffMerge (نیازمند نشست گرافیکی است)

           diffuse
               استفاده از Diffuse (نیازمند نشست گرافیکی است)

           ecmerge
               استفاده از ECMerge (نیازمند نشست گرافیکی است)

           emerge
               استفاده از Emerge در Emacs

           examdiff
               استفاده از ExamDiff Pro (نیازمند نشست گرافیکی است)

           guiffy
               استفاده از ابزار تفاضل Guiffy (نیازمند نشست گرافیکی است)

           gvimdiff
               استفاده از gVim (نیازمند نشست گرافیکی است) با چیدمان سفارشی
               (بخش BACKEND SPECIFIC HINTS از git help mergetool را ببینید)

           gvimdiff1
               استفاده از gVim (نیازمند نشست گرافیکی است) با چیدمان ۲ قاب
               (LOCAL و REMOTE)

           gvimdiff2
               استفاده از gVim (نیازمند نشست گرافیکی است) با چیدمان ۳ قاب
               (LOCAL، MERGED و REMOTE)

           gvimdiff3
               استفاده از gVim (نیازمند نشست گرافیکی است) که در آن فقط فایل
               MERGED نشان داده می‌شود

           kdiff3
               استفاده از KDiff3 (نیازمند نشست گرافیکی است)

           meld
               استفاده از Meld (نیازمند نشست گرافیکی است) با auto merge
               اختیاری (بخش CONFIGURATION از git help mergetool را ببینید)

           nvimdiff
               استفاده از Neovim با چیدمان سفارشی (بخش BACKEND SPECIFIC HINTS
               از git help mergetool را ببینید)

           nvimdiff1
               استفاده از Neovim با چیدمان ۲ قاب (LOCAL و REMOTE)

           nvimdiff2
               استفاده از Neovim با چیدمان ۳ قاب (LOCAL، MERGED و REMOTE)

           nvimdiff3
               استفاده از Neovim که در آن فقط فایل MERGED نشان داده می‌شود

           opendiff
               استفاده از FileMerge (نیازمند نشست گرافیکی است)

           p4merge
               استفاده از HelixCore P4Merge (نیازمند نشست گرافیکی است)

           smerge
               استفاده از Sublime Merge (نیازمند نشست گرافیکی است)

           tkdiff
               استفاده از TkDiff (نیازمند نشست گرافیکی است)

           tortoisemerge
               استفاده از TortoiseMerge (نیازمند نشست گرافیکی است)

           vimdiff
               استفاده از Vim با چیدمان سفارشی (بخش BACKEND SPECIFIC HINTS از
               git help mergetool را ببینید)

           vimdiff1
               استفاده از Vim با چیدمان ۲ قاب (LOCAL و REMOTE)

           vimdiff2
               استفاده از Vim با چیدمان ۳ قاب (LOCAL، MERGED و REMOTE)

           vimdiff3
               استفاده از Vim که در آن فقط فایل MERGED نشان داده می‌شود

           vscode
               استفاده از Visual Studio Code (نیازمند نشست گرافیکی است)

           winmerge
               استفاده از WinMerge (نیازمند نشست گرافیکی است)

           xxdiff
               استفاده از xxdiff (نیازمند نشست گرافیکی است)

       merge.verbosity
           میزان خروجی نشان‌داده‌شده توسط راهبرد ادغام بازگشتی را کنترل می‌کند.
           سطح ۰ هیچ چیزی به جز یک پیام خطای نهایی در صورت شناسایی تعارض‌ها
           خروجی نمی‌دهد. سطح ۱ تنها تعارض‌ها را خروجی می‌دهد، ۲ تعارض‌ها و
           تغییرات فایل را خروجی می‌دهد. سطح ۵ و بالاتر اطلاعات اشکال‌زدایی را
           خروجی می‌دهد. پیش‌فرض، سطح ۲ است. می‌تواند توسط متغیر محیطی
           GIT_MERGE_VERBOSITY بازنویسی شود.

       merge.<driver>.name
           یک نام قابل خواندن برای انسان را برای یک درایور ادغام سطح‌پایین
           سفارشی تعریف می‌کند. برای جزئیات به gitattributes(5) مراجعه کنید.

       merge.<driver>.driver
           دستوری را که یک درایور ادغام سطح‌پایین سفارشی را پیاده‌سازی می‌کند
           تعریف می‌نماید. برای جزئیات به gitattributes(5) مراجعه کنید.

       merge.<driver>.recursive
           نام یک درایور ادغام سطح‌پایین را برای استفاده در هنگام انجام ادغام
           داخلی میان نیاکان مشترک تعیین می‌کند. برای جزئیات به
           gitattributes(5) مراجعه کنید.

همچنین ببینید (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)

Git 2.55.0                        2026-06-29                      GIT-MERGE(1)