نام (NAME)

git-rebase - بازاعمال کامیت‌ها بر روی سرشاخه جدید

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

git rebase [-i | --interactive] [<options>] [--exec <cmd>]
        [--onto <newbase> | --keep-base] [<upstream> [<branch>]]
git rebase [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>]
        --root [<branch>]
git rebase (--continue|--skip|--abort|--quit|--edit-todo|--show-current-patch)

توضیحات (DESCRIPTION)

پیوند زدن مجموعه‌ای از کامیت‌ها بر روی یک نقطه شروع متفاوت. همچنین می‌توانید از git rebase برای بازآرایی یا ترکیب کامیت‌ها استفاده کنید: برای چگونگی انجام این کار، بخش INTERACTIVE MODE در زیر را مشاهده کنید.

برای مثال، فرض کنید در این تاریخچه روی شاخه topic کار می‌کرده‌اید و می‌خواهید کارهای انجام‌شده روی شاخه master را دریافت کرده و همگام شوید.

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

شما می‌خواهید کامیت‌هایی را که از زمان جدا شدن topic از master ایجاد کرده‌اید (یعنی A، B و C)، بر روی نوک شاخه فعلی master منتقل کنید. این کار را می‌توانید با اجرای git rebase master در زمانی که شاخه topic بررسی (checkout) شده است انجام دهید. اگر می‌خواهید topic را زمانی که روی شاخه دیگری هستید بازاعمال کنید، دستور git rebase master topic یک میانبر برای git checkout topic && git rebase master است.

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

اگر در حین این فرآیند با یک تعارض ادغام مواجه شوید، git rebase در اولین کامیت دارای مشکل متوقف شده و نشانگرهای تعارض را باقی می‌گذارد. در این حالت می‌توانید یکی از این کارها را انجام دهید:

git rebase --continue

git rebase --abort

git rebase --skip

اگر شاخه بالادستی <upstream> را برای بازاعمال بر روی آن تعیین نکنید، بالادست پیکربندی‌شده در گزینه‌های branch.<name>.remote و branch.<name>.merge استفاده خواهد شد (برای جزئیات به git-config(1) رجوع کنید) و گزینه --fork-point فرض می‌شود. اگر هم‌اکنون روی هیچ شاخه‌ای قرار ندارید یا اگر شاخه فعلی بالادست پیکربندی‌شده‌ای ندارد، عملیات بازاعمال لغو خواهد شد.

در اینجا شرح ساده‌شده‌ای از عملکرد git rebase <upstream> آورده شده است:

انتقال یک شاخه موضوعی با استفاده از --ONTO (TRANSPLANTING A TOPIC BRANCH WITH --ONTO)

در اینجا نحوه انتقال یک شاخه موضوعی مبتنی بر یک شاخه به شاخه‌ای دیگر با استفاده از rebase --onto آورده شده است، تا وانمود شود که شاخه موضوعی را از شاخه دومی منشعب کرده‌اید.

ابتدا فرض کنیم شاخه topic شما مبتنی بر شاخه next است. برای مثال، قابلیتی که در topic توسعه داده شده به عملکردی وابسته است که در next وجود دارد.

o---o---o---o---o  master
     \
      o---o---o---o---o  next
                       \
                        o---o---o  topic

ما می‌خواهیم کاری کنیم که topic از شاخه master منشعب شود؛ مثلاً به این دلیل که عملکردی که topic به آن وابسته است در شاخه پایدارتر master ادغام شده است. می‌خواهیم درخت ما به این شکل باشد:

o---o---o---o---o  master
    |            \
    |             o'--o'--o'  topic
     \
      o---o---o---o---o  next

می‌توانیم با استفاده از دستور زیر به این نتیجه برسیم:

git rebase --onto master next topic

مثال دیگری از گزینه --onto بازاعمال بخشی از یک شاخه است. اگر وضعیت زیر را داشته باشیم:

                        H---I---J topicB
                       /
              E---F---G  topicA
             /
A---B---C---D  master

در این صورت دستور

git rebase --onto master topicA topicB

نتیجه زیر را در پی خواهد داشت:

             H'--I'--J'  topicB
            /
            | E---F---G  topicA
            |/
A---B---C---D  master

این حالت زمانی مفید است که topicB به topicA وابسته نباشد.

همچنین می‌توان محدوده‌ای از کامیت‌ها را با بازاعمال حذف کرد. اگر وضعیت زیر را داشته باشیم:

E---F---G---H---I---J  topicA

در این صورت دستور

git rebase --onto topicA~5 topicA~3 topicA

منجر به حذف کامیت‌های F و G خواهد شد:

E---H'---I'---J'  topicA

این کار زمانی مفید است که F و G به گونه‌ای دارای ایراد باشند، یا نباید بخشی از topicA باشند. توجه داشته باشید که آرگومان --onto و پارامتر <upstream> می‌توانند هر شبه‌کامیت (commit-ish) معتبری باشند.

گزینه‌های حالت (MODE OPTIONS)

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

--continue

--skip

--abort

--quit

--edit-todo

--show-current-patch

گزینه‌ها (OPTIONS)

--onto <newbase>

برای مثال‌ها، بخش TRANSPLANTING A TOPIC BRANCH WITH --ONTO در بالا را ببینید.

--keep-base

<upstream>

<branch>

--apply

--empty=(drop|keep|stop)

--no-keep-empty, --keep-empty

--reapply-cherry-picks, --no-reapply-cherry-picks

--allow-empty-message

-m, --merge

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

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

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

-S[<keyid>], --gpg-sign[=<keyid>], --no-gpg-sign

-q, --quiet

-v, --verbose

--stat

-n, --no-stat

--no-verify

--verify

-C<n>

--no-ff, --force-rebase, -f

--fork-point, --no-fork-point

--ignore-whitespace

--whitespace=<option>

--committer-date-is-author-date

--ignore-date, --reset-author-date

--signoff

--trailer=<trailer>

-i, --interactive

-r, --rebase-merges[=(rebase-cousins|no-rebase-cousins)], --no-rebase-merges

-x <cmd>, --exec <cmd>

git rebase -i --exec "cmd1 && cmd2 && ..."

git rebase -i --exec "cmd1" --exec "cmd2" --exec ...

--root

--autosquash, --no-autosquash

--autostash, --no-autostash

--reschedule-failed-exec, --no-reschedule-failed-exec

--update-refs, --no-update-refs

گزینه‌های ناسازگار (INCOMPATIBLE OPTIONS)

گزینه‌های زیر:

با گزینه‌های زیر ناسازگار هستند:

علاوه بر این، جفت‌گزینه‌های زیر ناسازگار هستند:

تفاوت‌های رفتاری (BEHAVIORAL DIFFERENCES)

git rebase دارای دو بک‌اند اصلی است: apply و merge. (بک‌اند apply پیش‌تر به عنوان بک‌اند am شناخته می‌شد، اما این نام باعث سردرگمی بود زیرا به جای یک اسم شبیه به یک فعل به نظر می‌رسید. همچنین بک‌اند merge پیش‌تر به عنوان بک‌اند تعاملی (interactive) شناخته می‌شد، اما اکنون برای موارد غیرتعاملی نیز استفاده می‌شود. هر دو بر اساس عملکردهای سطح پایین‌تری که زیربنای هر یک بود تغییر نام یافتند.) تفاوت‌های ظریفی در نحوه رفتار این دو بک‌اند وجود دارد:

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

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

ort

recursive

resolve

octopus

ours

subtree

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

نکات (NOTES)

شما باید پیامدهای استفاده از git rebase را بر روی مخزنی که به اشتراک می‌گذارید درک کنید. همچنین به بخش RECOVERING FROM UPSTREAM REBASE در ادامه مراجعه فرمایید.

هنگامی که rebase اجرا می‌شود، در صورت وجود ابتدا یک قلاب pre-rebase را اجرا می‌کند. می‌توانید از این قلاب برای بررسی‌های صحت‌سنجی استفاده کنید و در صورت نامناسب بودن، rebase را رد نمایید. لطفاً برای مشاهده یک مثال به اسکریپت الگوی قلاب pre-rebase مراجعه کنید.

پس از تکمیل، <branch> شاخه جاری خواهد بود.

حالت تعاملی (INTERACTIVE MODE)

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

حالت تعاملی برای این نوع جریان کاری در نظر گرفته شده است:

که در آن مورد ۲ شامل چندین نمونه از این موارد است:

الف) استفاده معمول

ب) اصلاح مستقل (fixup)

گاهی موردی که در ب.۲. رفع شده است را نمی‌توان به کامیت نه‌چندان کاملی که آن را اصلاح می‌کند الحاق (amend) کرد، زیرا آن کامیت در اعماق یک سری وصله قرار گرفته است. این دقیقاً همان چیزی است که بازپایه‌ریزی تعاملی برای آن در نظر گرفته شده است: استفاده از آن پس از تعداد زیادی «الف» و «ب»، با بازآرایی و ویرایش کامیت‌ها، و ادغام (squash) چندین کامیت در یک کامیت واحد.

آن را با آخرین کامیتی که می‌خواهید به همین شکل باقی بماند شروع کنید:

git rebase -i <after-this-commit>

یک ویرایشگر همراه با تمام کامیت‌های شاخه فعلی شما (با صرف‌نظر از کامیت‌های ادغام) که پس از کامیت ارائه‌شده آمده‌اند باز خواهد شد. شما می‌توانید تا هر اندازه که مایلید ترتیب کامیت‌ها را در این فهرست تغییر دهید و می‌توانید آن‌ها را حذف کنید. این فهرست کم‌وبیش به این صورت است:

pick deadbee The oneline of this commit
pick fa1afe1 The oneline of the next commit
...

توضیحات تک‌خطی صرفاً برای راحتی شما هستند؛ دستور git rebase به آن‌ها نگاه نمی‌کند بلکه به نام‌های کامیت توجه می‌کند (در این مثال "deadbee" و "fa1afe1")، بنابراین نام‌ها را حذف یا ویرایش نکنید.

با جایگزین کردن دستور "pick" با دستور "edit"، می‌توانید به git rebase بگویید که پس از اعمال آن کامیت متوقف شود، تا بتوانید فایل‌ها و/یا پیام کامیت را ویرایش کنید، کامیت را اصلاح (amend) نمایید و به بازپایه‌ریزی ادامه دهید.

برای ایجاد وقفه در بازپایه‌ریزی (دقیقاً همان‌طور که دستور "edit" عمل می‌کند، اما بدون گلچین‌کردن (cherry-pick) هیچ کامیتی پیش از آن)، از دستور "break" استفاده کنید.

اگر فقط می‌خواهید پیام یک کامیت را ویرایش کنید، دستور "pick" را با دستور "reword" جایگزین نمایید.

برای دور انداختن یک کامیت، دستور "pick" را با "drop" جایگزین کنید، یا به سادگی خط مربوط به آن را حذف نمایید.

اگر می‌خواهید دو یا چند کامیت را در یک کامیت ادغام (fold) کنید، دستور "pick" را برای کامیت دوم و کامیت‌های بعدی با "squash" یا "fixup" جایگزین کنید. اگر کامیت‌ها نویسندگان متفاوتی داشته باشند، کامیت ادغام‌شده به نویسنده کامیت نخست نسبت داده خواهد شد. پیام کامیت پیشنهادی برای کامیت ادغام‌شده، الحاق پیام کامیت نخست با پیام‌های مشخص‌شده توسط دستورهای "squash" است، با حذف پیام‌های کامیت‌هایی که با دستورهای "fixup" مشخص شده‌اند، مگر اینکه از "fixup -c" استفاده شود. در این صورت، پیام کامیت پیشنهادی فقط پیام کامیت "fixup -c" خواهد بود و یک ویرایشگر باز می‌شود که به شما اجازه می‌دهد پیام را ویرایش کنید. محتویات (وصله) کامیت "fixup -c" همچنان در کامیت ادغام‌شده گنجانده می‌شود. اگر بیش از یک کامیت "fixup -c" وجود داشته باشد، پیام مربوط به آخرین مورد استفاده خواهد شد. همچنین می‌توانید از "fixup -C" استفاده کنید تا همان رفتار "fixup -c" را داشته باشید با این تفاوت که ویرایشگری باز نمی‌شود.

دستور git rebase هنگامی که "pick" با "edit" جایگزین شده باشد یا زمانی که دستوری به دلیل خطاهای ادغام شکست بخورد متوقف خواهد شد. هنگامی که ویرایش و/یا حل تعارض‌ها را به پایان رساندید، می‌توانید با git rebase --continue ادامه دهید.

به عنوان مثال، اگر می‌خواهید ۵ کامیت آخر را به گونه‌ای بازآرایی کنید که آنچه قبلاً HEAD~4 بود به HEAD جدید تبدیل شود. برای رسیدن به این منظور، git rebase را به این صورت فراخوانی می‌کنید:

$ git rebase -i HEAD~5

و نخستین وصله را به انتهای فهرست منتقل می‌کنید.

ممکن است بخواهید کامیت‌های ادغام را دوباره ایجاد کنید، برای مثال اگر چنین تاریخچه‌ای داشته باشید:

           X
            \
         A---M---B
        /
---o---O---P---Q

فرض کنید می‌خواهید شاخه فرعی را که از "A" آغاز می‌شود بر روی "Q" بازپایه‌ریزی کنید. مطمئن شوید که HEAD فعلی "B" است، و این دستور را فراخوانی کنید:

$ git rebase -i -r --onto Q O

بازآرایی و ویرایش کامیت‌ها معمولاً مراحل میانی آزمایش‌نشده‌ای ایجاد می‌کند. شاید بخواهید با اجرای یک آزمون، یا حداقل کامپایل مجدد در نقاط میانی تاریخچه با استفاده از دستور "exec" (میانبر "x") بررسی کنید که ویرایش تاریخچه شما چیزی را خراب نکرده باشد. می‌توانید این کار را با ایجاد یک فهرست کارها (todo list) مانند این انجام دهید:

pick deadbee Implement feature XXX
fixup f1a5c00 Fix to feature XXX
exec make
pick c0ffeee The oneline of the next commit
edit deadbab The oneline of the commit after
exec cd subdir; make test
...

بازپایه‌ریزی تعاملی در صورت شکست یک دستور (یعنی خروج با وضعیتی غیر از ۰) متوقف می‌شود تا به شما فرصت رفع مشکل را بدهد. می‌توانید با git rebase --continue ادامه دهید.

دستور "exec" فرمان را در یک پوسته (پوسته پیش‌فرض، معمولاً ‎/bin/sh) اجرا می‌کند، بنابراین می‌توانید از ویژگی‌های پوسته (مانند "cd"، ">"، ";" و ...) استفاده کنید. این فرمان از ریشه درخت کاری اجرا می‌شود.

$ git rebase -i --exec "make test"

این دستور به شما امکان می‌دهد بررسی کنید که کامیت‌های میانی قابل کامپایل هستند. فهرست کارها به این شکل درمی‌آید:

pick 5928aea one
exec make test
pick 04d0fda two
exec make test
pick ba46169 three
exec make test
pick f4593f9 four
exec make test

تقسیم کامیت‌ها (SPLITTING COMMITS)

در حالت تعاملی، می‌توانید کامیت‌ها را با عملیات "edit" علامت‌گذاری کنید. با این حال، این لزوماً به این معنی نیست که git rebase انتظار دارد نتیجه این ویرایش دقیقاً یک کامیت باشد. در واقع، می‌توانید کامیت را لغو (undo) کنید یا کامیت‌های دیگری اضافه نمایید. از این قابلیت می‌توان برای تقسیم یک کامیت به دو کامیت استفاده کرد:

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

بازیابی پس از ریبیس بالادست (RECOVERING FROM UPSTREAM REBASE)

ریبیس کردن (یا هر شکل دیگری از بازنویسی) شاخه‌ای که دیگران کار خود را بر پایه آن بنا نهاده‌اند، ایده بدی است: هر کسی در پایین‌دست (downstream) آن مجبور می‌شود تاریخچه خود را به‌صورت دستی اصلاح کند. این بخش توضیح می‌دهد که چگونه این اصلاح را از دیدگاه پایین‌دست انجام دهید. با این حال، راه‌حل واقعی این است که در وهله اول از ریبیس کردن شاخه بالادست (upstream) خودداری شود.

برای مثال، فرض کنید در موقعیتی هستید که شخصی یک شاخه subsystem را توسعه می‌دهد، و شما در حال کار بر روی شاخه topic هستید که به این subsystem وابسته است. ممکن است به تاریخچه‌ای مانند زیر برسید:

o---o---o---o---o---o---o---o  master
     \
      o---o---o---o---o  subsystem
                       \
                        *---*---*  topic

اگر subsystem نسبت به master ریبیس شود، اتفاق زیر رخ می‌دهد:

o---o---o---o---o---o---o---o  master
     \                       \
      o---o---o---o---o       o'--o'--o'--o'--o'  subsystem
                       \
                        *---*---*  topic

حال اگر به توسعه مثل همیشه ادامه دهید و در نهایت topic را در subsystem ادغام (merge) کنید، کامیت‌های شاخه subsystem برای همیشه تکراری باقی خواهند ماند:

o---o---o---o---o---o---o---o  master
     \                       \
      o---o---o---o---o       o'--o'--o'--o'--o'--M  subsystem
                       \                         /
                        *---*---*-..........-*--*  topic

چنین موارد تکراری معمولاً ناپسند شمرده می‌شوند چرا که تاریخچه را شلوغ و نامرتب کرده و دنبال کردن آن را سخت‌تر می‌کنند. برای پاک‌سازی، لازم است کامیت‌های روی topic را به نوک جدید subsystem پیوند بزنید، یعنی topic را ریبیس کنید. این موضوع اثری موجی (ripple effect) به همراه دارد: هر کسی در پایین‌دست topic نیز مجبور می‌شود ریبیس کند و همین‌طور الی آخر!

دو نوع راه‌حل اصلاحی وجود دارد که در زیربخش‌های زیر بررسی می‌شوند:

حالت ساده: تغییرات دقیقاً همان هستند.

حالت پیچیده: تغییرات یکسان نیستند.

$ git rebase subsystem

o---o---o---o---o---o---o  master
                             \
                              o'--o'--o'--o'--o'  subsystem
                                               \
                                                *---*---*  topic

$ git rebase --onto subsystem subsystem@{1}

ریبیس کردن ادغام‌ها (REBASING MERGES)

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

با این حال، دلایل موجهی وجود دارد که چرا یک توسعه‌دهنده ممکن است بخواهد کامیت‌های ادغام را دوباره ایجاد کند: برای حفظ ساختار شاخه (یا «توپولوژی کامیت») هنگام کار بر روی چندین شاخه مرتبط با یکدیگر.

در مثال زیر، توسعه‌دهنده روی یک شاخه موضوعی کار می‌کند که شیوه تعریف دکمه‌ها را بازسازی می‌کند، و روی شاخه موضوعی دیگری که از آن بازسازی برای پیاده‌سازی دکمه «گزارش باگ» استفاده می‌کند. خروجی git log --graph --format=%s -5 ممکن است شبیه این باشد:

*   Merge branch 'report-a-bug'
|\
| * Add the feedback button
* | Merge branch 'refactor-button'
|\ \
| |/
| * Use the Button class for all buttons
| * Extract a generic Button class from the DownloadButton one

توسعه‌دهنده ممکن است بخواهد در حین حفظ توپولوژی شاخه، آن کامیت‌ها را روی یک شاخه جدیدتر master ریبیس کند، به عنوان مثال هنگامی که انتظار می‌رود شاخه موضوعی اول بسیار زودتر از شاخه دوم در master ادغام شود، مثلاً برای رفع تداخل‌های ادغام با تغییرات اعمال‌شده در کلاس DownloadButton که وارد master شده‌اند.

این ریبیس را می‌توان با استفاده از گزینه --rebase-merges انجام داد. این گزینه یک فهرست کارها (todo list) مانند زیر تولید خواهد کرد:

label onto
# Branch: refactor-button
reset onto
pick 123456 Extract a generic Button class from the DownloadButton one
pick 654321 Use the Button class for all buttons
label refactor-button
# Branch: report-a-bug
reset refactor-button # Use the Button class for all buttons
pick abcdef Add the feedback button
label report-a-bug
reset onto
merge -C a1b2c3 refactor-button # Merge 'refactor-button'
merge -C 6f5e4d report-a-bug # Merge 'report-a-bug'

برخلاف یک ریبیس تعاملی معمولی، علاوه بر دستورهای pick، دستورهای label، reset و merge نیز وجود دارند.

دستور label هنگامی که آن دستور اجرا می‌شود، یک برچسب (label) را به HEAD فعلی مرتبط می‌کند. این برچسب‌ها به عنوان ارجاع‌های محلی درخت کاری (refs/rewritten/<label>) ایجاد می‌شوند که پس از پایان ریبیس حذف خواهند شد. به این ترتیب، عملیات ریبیس در چندین درخت کاری متصل به یک مخزن مشترک، با یکدیگر تداخل پیدا نمی‌کنند. اگر دستور label با شکست مواجه شود، بلافاصله همراه با پیامی مفید درباره نحوه ادامه کار، مجدداً زمان‌بندی می‌شود.

دستور reset، اشاره‌گر HEAD، نمایه (index) و درخت کاری (worktree) را به بازبینی مشخص‌شده بازنشانی می‌کند. این دستور شبیه به exec git reset --hard <label> عمل می‌کند، اما از بازنویسی فایل‌های ردیابی‌نشده خودداری می‌کند. اگر دستور reset ناموفق باشد، بلافاصله همراه با یک پیام راهنما درباره نحوه ویرایش فهرست کارها، مجدداً زمان‌بندی می‌شود (این اتفاق معمولاً زمانی رخ می‌دهد که دستور reset به صورت دستی در فهرست کارها درج شده باشد و حاوی غلط املایی باشد).

دستور merge بازبینی(های) مشخص‌شده را در هر آنچه در آن زمان HEAD است ادغام خواهد کرد. با گزینه -C <original-commit>، پیام کامیت مربوط به کامیت ادغام مشخص‌شده استفاده خواهد شد. هنگامی که -C به حرف کوچک -c تبدیل شود، پیام پس از یک ادغام موفق در ویرایشگری باز می‌شود تا کاربر بتواند آن پیام را ویرایش کند.

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

به طور پیش‌فرض، دستور merge از راهبرد ادغام ort برای ادغام‌های عادی و از octopus برای ادغام‌های اختاپوسی استفاده خواهد کرد. کاربر می‌تواند با استفاده از آرگومان --strategy هنگام فراخوانی rebase یک راهبرد پیش‌فرض برای تمامی ادغام‌ها تعیین کند، یا با استفاده از یک دستور exec برای فراخوانی صریح git merge همراه با آرگومان --strategy، ادغام‌های خاصی را در فهرست تعاملی دستورات بازنویسی و لغو کند. توجه داشته باشید که هنگام فراخوانی صریح git merge به این شکل، می‌توانید از این واقعیت بهره ببرید که برچسب‌ها ارجاع‌های محلی درخت کاری هستند (برای مثال، ارجاع refs/rewritten/onto متناظر با برچسب onto خواهد بود) تا به شاخه‌هایی که می‌خواهید ادغام کنید ارجاع دهید.

نکته: دستور اول (label onto) بازبینی‌ای را برچسب‌گذاری می‌کند که کامیت‌ها بر روی آن ریبیس می‌شوند؛ نام onto صرفاً یک قرارداد و اشاره‌ای به گزینه --onto است.

همچنین می‌توان کامیت‌های ادغام کاملاً جدید را از ابتدا با افزودن دستوری به فرم merge <merge-head> معرفی کرد. این فرم یک پیام کامیت موقت ایجاد می‌کند و همیشه ویرایشگری را باز می‌کند تا به کاربر اجازه دهد آن را ویرایش نماید. این قابلیت می‌تواند مفید باشد، برای مثال هنگامی که معلوم می‌شود یک شاخه موضوعی به بیش از یک هدف یا دغدغه پرداخته است و باید به دو یا چند شاخه موضوعی تفکیک شود. این فهرست کارها (todo list) را در نظر بگیرید:

pick 192837 Switch from GNU Makefiles to CMake
pick 5a6c7e Document the switch to CMake
pick 918273 Fix detection of OpenSSL in CMake
pick afbecd http: add support for TLS v1.3
pick fdbaec Fix detection of cURL in CMake on Windows

تنها کامیتی که در این فهرست ارتباطی با CMake ندارد، ممکن است بسیار محتمل باشد که انگیزه‌اش از کار روی رفع باگ‌های ناشی از تغییر به CMake نشأت گرفته باشد، اما به موضوع متفاوتی می‌پردازد. برای تقسیم این شاخه به دو شاخه موضوعی، می‌توان فهرست کارها را به این شکل ویرایش کرد:

label onto
pick afbecd http: add support for TLS v1.3
label tlsv1.3
reset onto
pick 192837 Switch from GNU Makefiles to CMake
pick 918273 Fix detection of OpenSSL in CMake
pick fdbaec Fix detection of cURL in CMake on Windows
pick 5a6c7e Document the switch to CMake
label cmake
reset onto
merge tlsv1.3
merge cmake

پیکربندی (CONFIGURATION)

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

rebase.backend

rebase.stat

rebase.autoSquash

rebase.autoStash

rebase.updateRefs

rebase.missingCommitsCheck

rebase.instructionFormat

rebase.abbreviateCommands

p deadbee The oneline of the commit
p fa1afe1 The oneline of the next commit
...

pick deadbee The oneline of the commit
pick fa1afe1 The oneline of the next commit
...

rebase.rescheduleFailedExec

rebase.forkPoint

rebase.rebaseMerges

rebase.maxLabelLength

sequence.editor

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

git-am(1)، git-merge(1)، git-cherry-pick(1)

گیت (GIT)

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

نکات (NOTES)

1.

راهنمای revert-a-faulty-merge How-To

2.

filter-repo