'\" t
.\" Title: git-rebase
.\" Author: [FIXME: author] [see http://www.docbook.org/tdg5/en/html/author]
.\" Generator: DocBook XSL Stylesheets vsnapshot
.\" Date: 2026-06-29
.\" Manual: Git Manual
.\" Source: Git 2.55.0
.\" Language: Persian
.\"
.TH "GIT\-REBASE" "1" "2026\-06\-29" "Git 2\&.55\&.0" "Git Manual"
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.ie \n(.g .ds Aq \(aq
.el .ds Aq '
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH "نام (NAME)"
git-rebase \- بازاعمال کامیتها بر روی سرشاخه جدید
.SH "خلاصه دستور (SYNOPSIS)"
.sp
.nf
\fIgit rebase\fR [\-i | \-\-interactive] [] [\-\-exec ]
[\-\-onto | \-\-keep\-base] [ []]
\fIgit rebase\fR [\-i | \-\-interactive] [] [\-\-exec ] [\-\-onto ]
\-\-root []
\fIgit rebase\fR (\-\-continue|\-\-skip|\-\-abort|\-\-quit|\-\-edit\-todo|\-\-show\-current\-patch)
.fi
.sp
.SH "توضیحات (DESCRIPTION)"
.sp
پیوند زدن مجموعهای از کامیتها بر روی یک نقطه شروع متفاوت\&. همچنین میتوانید از \fBgit\fR \fBrebase\fR برای بازآرایی یا ترکیب کامیتها استفاده کنید: برای چگونگی انجام این کار، بخش INTERACTIVE MODE در زیر را مشاهده کنید\&.
.sp
برای مثال، فرض کنید در این تاریخچه روی شاخه \fBtopic\fR کار میکردهاید و میخواهید کارهای انجامشده روی شاخه \fBmaster\fR را دریافت کرده و همگام شوید\&.
.sp
.if n \{\
.RS 4
.\}
.nf
A\-\-\-B\-\-\-C topic
/
D\-\-\-E\-\-\-F\-\-\-G master
.fi
.if n \{\
.RE
.\}
.sp
.sp
شما میخواهید کامیتهایی را که از زمان جدا شدن \fBtopic\fR از \fBmaster\fR ایجاد کردهاید (یعنی A، B و C)، بر روی نوک شاخه فعلی \fBmaster\fR منتقل کنید\&. این کار را میتوانید با اجرای \fBgit\fR \fBrebase\fR \fBmaster\fR در زمانی که شاخه \fBtopic\fR بررسی (checkout) شده است انجام دهید\&. اگر میخواهید \fBtopic\fR را زمانی که روی شاخه دیگری هستید بازاعمال کنید، دستور \fBgit\fR \fBrebase\fR \fBmaster\fR \fBtopic\fR یک میانبر برای \fBgit\fR \fBcheckout\fR \fBtopic\fR && \fBgit\fR \fBrebase\fR \fBmaster\fR است\&.
.sp
.if n \{\
.RS 4
.\}
.nf
A\*(Aq\-\-B\*(Aq\-\-C\*(Aq topic
/
D\-\-\-E\-\-\-F\-\-\-G master
.fi
.if n \{\
.RE
.\}
.sp
.sp
اگر در حین این فرآیند با یک تعارض ادغام مواجه شوید، \fBgit\fR \fBrebase\fR در اولین کامیت دارای مشکل متوقف شده و نشانگرهای تعارض را باقی میگذارد\&. در این حالت میتوانید یکی از این کارها را انجام دهید:
.sp
.RS 4
.ie n \{\
\h'-04' 1.\h'+01'\c
.\}
.el \{\
.sp -1
.IP " 1." 4.2
.\}
حل کردن تعارض\&. میتوانید از
\fBgit\fR
\fBdiff\fR
برای یافتن نشانگرها (<<<<<<) و اعمال تغییرات جهت رفع تعارض استفاده کنید\&. برای هر فایلی که ویرایش میکنید، باید به گیت اعلام کنید که تعارض رفع شده است\&. میتوانید تعارض را با
\fBgit\fR
\fBadd\fR
\fI\fR
به عنوان حلشده علامتگذاری کنید\&. پس از حل تمام تعارضها، میتوانید فرآیند بازاعمال را با دستور زیر ادامه دهید
.sp
.if n \{\
.RS 4
.\}
.nf
git rebase \-\-continue
.fi
.if n \{\
.RE
.\}
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 2.\h'+01'\c
.\}
.el \{\
.sp -1
.IP " 2." 4.2
.\}
متوقف کردن
\fBgit\fR
\fBrebase\fR
و بازگرداندن شاخه خود به وضعیت اولیهاش با
.sp
.if n \{\
.RS 4
.\}
.nf
git rebase \-\-abort
.fi
.if n \{\
.RE
.\}
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 3.\h'+01'\c
.\}
.el \{\
.sp -1
.IP " 3." 4.2
.\}
صرفنظر کردن از کامیتی که باعث ایجاد تعارض ادغام شد با
.sp
.if n \{\
.RS 4
.\}
.nf
git rebase \-\-skip
.fi
.if n \{\
.RE
.\}
.RE
.sp
اگر شاخه بالادستی \fI\fR را برای بازاعمال بر روی آن تعیین نکنید، بالادست پیکربندیشده در گزینههای \fBbranch\&.\fR\fI\fR\fB\&.remote\fR و \fBbranch\&.\fR\fI\fR\fB\&.merge\fR استفاده خواهد شد (برای جزئیات به \fBgit-config\fR(1) رجوع کنید) و گزینه \fB\-\-fork\-point\fR فرض میشود\&. اگر هماکنون روی هیچ شاخهای قرار ندارید یا اگر شاخه فعلی بالادست پیکربندیشدهای ندارد، عملیات بازاعمال لغو خواهد شد\&.
.sp
در اینجا شرح سادهشدهای از عملکرد \fBgit\fR \fBrebase\fR \fI\fR آورده شده است:
.sp
.RS 4
.ie n \{\
\h'-04' 1.\h'+01'\c
.\}
.el \{\
.sp -1
.IP " 1." 4.2
.\}
تهیه فهرستی از تمام کامیتهای شاخه فعلی شما از زمان انشعاب آن از
\fI\fR
که کامیت معادلی در
\fI\fR
ندارند\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 2.\h'+01'\c
.\}
.el \{\
.sp -1
.IP " 2." 4.2
.\}
استخراج (checkout)
\fI\fR
با معادل
\fBgit\fR
\fBcheckout\fR
\fB\-\-detach\fR
\fI\fR\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 3.\h'+01'\c
.\}
.el \{\
.sp -1
.IP " 3." 4.2
.\}
اعمال مجدد کامیتها، یک به یک، به ترتیب\&. این شبیه به اجرای
\fBgit\fR
\fBcherry\-pick\fR
\fI\fR
برای هر کامیت است\&. برای نحوه رسیدگی به ادغامها به REBASING MERGES مراجعه کنید\&.
.RE
.sp
.RS 4
.ie n \{\
\h'-04' 4.\h'+01'\c
.\}
.el \{\
.sp -1
.IP " 4." 4.2
.\}
بهروزرسانی شاخه شما تا با معادل
\fBgit\fR
\fBcheckout\fR
\fB\-B\fR
\fI\fR
به کامیت نهایی اشاره کند\&.
.RE
.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
هنگام آغاز بازاعمال، \fBORIG_HEAD\fR طوری تنظیم میشود که به کامیت رأس شاخهای که قرار است بازاعمال شود اشاره کند\&. با این وجود، تضمینی نیست که در پایان بازاعمال نیز \fBORIG_HEAD\fR همچنان به آن کامیت اشاره داشته باشد، در صورتی که دستورات دیگری که \fBORIG_HEAD\fR را تغییر میدهند (مانند \fBgit\fR \fBreset\fR) در طول بازاعمال استفاده شوند\&. با این حال، رأس قبلی شاخه با استفاده از reflog شاخه فعلی (یعنی \fB@\fR{1}، به \fBgitrevisions\fR(7) مراجعه کنید) در دسترس است\&.
.sp .5v
.RE
.SH "انتقال یک شاخه موضوعی با استفاده از \-\-ONTO (TRANSPLANTING A TOPIC BRANCH WITH \-\-ONTO)"
.sp
در اینجا نحوه انتقال یک شاخه موضوعی مبتنی بر یک شاخه به شاخهای دیگر با استفاده از \fBrebase\fR \fB\-\-onto\fR آورده شده است، تا وانمود شود که شاخه موضوعی را از شاخه دومی منشعب کردهاید\&.
.sp
ابتدا فرض کنیم شاخه \fItopic\fR شما مبتنی بر شاخه \fInext\fR است\&. برای مثال، قابلیتی که در \fItopic\fR توسعه داده شده به عملکردی وابسته است که در \fInext\fR وجود دارد\&.
.sp
.if n \{\
.RS 4
.\}
.nf
o\-\-\-o\-\-\-o\-\-\-o\-\-\-o master
\e
o\-\-\-o\-\-\-o\-\-\-o\-\-\-o next
\e
o\-\-\-o\-\-\-o topic
.fi
.if n \{\
.RE
.\}
.sp
.sp
ما میخواهیم کاری کنیم که \fItopic\fR از شاخه \fImaster\fR منشعب شود؛ مثلاً به این دلیل که عملکردی که \fItopic\fR به آن وابسته است در شاخه پایدارتر \fImaster\fR ادغام شده است\&. میخواهیم درخت ما به این شکل باشد:
.sp
.if n \{\
.RS 4
.\}
.nf
o\-\-\-o\-\-\-o\-\-\-o\-\-\-o master
| \e
| o\*(Aq\-\-o\*(Aq\-\-o\*(Aq topic
\e
o\-\-\-o\-\-\-o\-\-\-o\-\-\-o next
.fi
.if n \{\
.RE
.\}
.sp
.sp
میتوانیم با استفاده از دستور زیر به این نتیجه برسیم:
.sp
.if n \{\
.RS 4
.\}
.nf
git rebase \-\-onto master next topic
.fi
.if n \{\
.RE
.\}
.sp
مثال دیگری از گزینه \-\-onto بازاعمال بخشی از یک شاخه است\&. اگر وضعیت زیر را داشته باشیم:
.sp
.if n \{\
.RS 4
.\}
.nf
H\-\-\-I\-\-\-J topicB
/
E\-\-\-F\-\-\-G topicA
/
A\-\-\-B\-\-\-C\-\-\-D master
.fi
.if n \{\
.RE
.\}
.sp
.sp
در این صورت دستور
.sp
.if n \{\
.RS 4
.\}
.nf
git rebase \-\-onto master topicA topicB
.fi
.if n \{\
.RE
.\}
.sp
نتیجه زیر را در پی خواهد داشت:
.sp
.if n \{\
.RS 4
.\}
.nf
H\*(Aq\-\-I\*(Aq\-\-J\*(Aq topicB
/
| E\-\-\-F\-\-\-G topicA
|/
A\-\-\-B\-\-\-C\-\-\-D master
.fi
.if n \{\
.RE
.\}
.sp
.sp
این حالت زمانی مفید است که topicB به topicA وابسته نباشد\&.
.sp
همچنین میتوان محدودهای از کامیتها را با بازاعمال حذف کرد\&. اگر وضعیت زیر را داشته باشیم:
.sp
.if n \{\
.RS 4
.\}
.nf
E\-\-\-F\-\-\-G\-\-\-H\-\-\-I\-\-\-J topicA
.fi
.if n \{\
.RE
.\}
.sp
.sp
در این صورت دستور
.sp
.if n \{\
.RS 4
.\}
.nf
git rebase \-\-onto topicA~5 topicA~3 topicA
.fi
.if n \{\
.RE
.\}
.sp
منجر به حذف کامیتهای F و G خواهد شد:
.sp
.if n \{\
.RS 4
.\}
.nf
E\-\-\-H\*(Aq\-\-\-I\*(Aq\-\-\-J\*(Aq topicA
.fi
.if n \{\
.RE
.\}
.sp
.sp
این کار زمانی مفید است که F و G به گونهای دارای ایراد باشند، یا نباید بخشی از topicA باشند\&. توجه داشته باشید که آرگومان \fB\-\-onto\fR و پارامتر \fI\fR میتوانند هر شبهکامیت (commit\-ish) معتبری باشند\&.
.SH "گزینههای حالت (MODE OPTIONS)"
.sp
گزینههای این بخش نمیتوانند همراه با هیچ گزینه دیگری استفاده شوند، از جمله نه با یکدیگر:
.PP
\-\-continue
.RS 4
فرآیند بازاعمال را پس از رفع تعارض ادغام از سر میگیرد\&.
.RE
.PP
\-\-skip
.RS 4
فرآیند بازاعمال را با رد کردن وصله فعلی از سر میگیرد\&.
.RE
.PP
\-\-abort
.RS 4
عملیات بازاعمال را لغو کرده و HEAD را به شاخه اصلی بازنشانی میکند\&. اگر
\fI\fR
مشخص شده باشد زمانی که عملیات بازاعمال آغاز شد، آنگاه
\fBHEAD\fR
به
\fI\fR
بازنشانی خواهد شد\&. در غیر این صورت
\fBHEAD\fR
به جایی که در زمان آغاز عملیات بازاعمال قرار داشت بازنشانی میشود\&.
.RE
.PP
\-\-quit
.RS 4
عملیات بازاعمال را لغو میکند، اما
\fBHEAD\fR
به شاخه اصلی بازگردانده نمیشود\&. در نتیجه، نمایه و درخت کاری نیز بدون تغییر باقی میمانند\&. اگر یک مدخل اندوخته (stash) موقت با استفاده از
\fB\-\-autostash\fR
ایجاد شده باشد، در فهرست اندوخته ذخیره خواهد شد\&.
.RE
.PP
\-\-edit\-todo
.RS 4
ویرایش فهرست کارهای انجامدادنی (todo) در طول یک بازاعمال تعاملی\&.
.RE
.PP
\-\-show\-current\-patch
.RS 4
نمایش وصله فعلی در یک بازاعمال تعاملی یا زمانی که بازاعمال به دلیل تعارضها متوقف شده است\&. این معادل
\fBgit\fR
\fBshow\fR
\fBREBASE_HEAD\fR
است\&.
.RE
.SH "گزینهها (OPTIONS)"
.PP
\-\-onto
.RS 4
نقطه شروعی که کامیتهای جدید در آنجا ایجاد میشوند\&. اگر گزینه
\fB\-\-onto\fR
مشخص نشده باشد، نقطه شروع
\fI\fR
خواهد بود\&. میتواند هر کامیت معتبری باشد، و نه فقط نام یک شاخه موجود\&.
.sp
در یک حالت خاص، در صورتی که دقیقاً یک پایه ادغام (merge base) وجود داشته باشد، میتوانید از "A\&.\&.\&.B" به عنوان میانبری برای پایه ادغام A و B استفاده کنید\&. میتوانید حداکثر یکی از A یا B را حذف کنید، که در این حالت مقدار پیشفرض آن HEAD خواهد بود\&.
.RE
.sp
برای مثالها، بخش TRANSPLANTING A TOPIC BRANCH WITH \-\-ONTO در بالا را ببینید\&.
.PP
\-\-keep\-base
.RS 4
نقطه شروع برای ایجاد کامیتهای جدید را روی پایه ادغام (merge base)
\fI\fR
و
\fI\fR
تنظیم میکند\&. اجرای
\fBgit\fR
\fBrebase\fR
\fB\-\-keep\-base\fR
\fI\fR
\fI\fR
معادل اجرای
\fBgit\fR
\fBrebase\fR
\fB\-\-reapply\-cherry\-picks\fR
\fB\-\-no\-fork\-point\fR
\fB\-\-onto\fR
\fI\fR\fB\&.\&.\&.\fR\fI\fR
\fI\fR
\fI\fR
است\&.
.sp
این گزینه در مواردی مفید است که در حال توسعه یک قابلیت بر روی یک شاخه بالادست هستید\&. در حالی که روی این قابلیت کار میشود، شاخه بالادست ممکن است جلو برود و بازپایهریزی مداوم روی سرشاخه بالادست ایده چندان مناسبی نباشد، بلکه حفظ کامیت پایه همانطور که هست ترجیح داده شود\&. از آنجا که کامیت پایه بدون تغییر باقی میماند، این گزینه برای جلوگیری از گم شدن کامیتها به طور ضمنی
\fB\-\-reapply\-cherry\-picks\fR
را فعال میکند\&.
.sp
اگرچه هم این گزینه و هم
\fB\-\-fork\-point\fR
پایه ادغام میان
\fI\fR
و
\fI\fR
را پیدا میکنند، اما این گزینه از پایه ادغام به عنوان
\fIنقطه شروع\fR
که کامیتهای جدید روی آن ایجاد خواهند شد استفاده میکند، در حالی که
\fB\-\-fork\-point\fR
از پایه ادغام برای تعیین
\fIمجموعه کامیتهایی\fR
که بازپایهریزی خواهند شد بهره میگیرد\&.
.sp
همچنین بخش INCOMPATIBLE OPTIONS در ادامه را ببینید\&.
.RE
.PP
.RS 4
شاخه بالادست برای مقایسه با آن\&. میتواند هر کامیت معتبری باشد، و نه فقط نام یک شاخه موجود\&. پیشفرض، شاخه بالادستِ پیکربندیشده برای شاخه فعلی است\&.
.RE
.PP
.RS 4
شاخه کاری؛ پیشفرض
\fBHEAD\fR
است\&.
.RE
.PP
\-\-apply
.RS 4
استفاده از راهبردهای اعمال (apply) برای بازپایهریزی (با فراخوانی درونی
\fBgit\-am\fR)\&.
این گزینه ممکن است در آینده، زمانی که بکاند merge بتواند همه کارهای بکاند apply را انجام دهد، به یک دستور بیاثر (no\-op) تبدیل شود\&.
.sp
همچنین بخش INCOMPATIBLE OPTIONS در ادامه را ببینید\&.
.RE
.PP
\-\-empty=(drop|keep|stop)
.RS 4
نحوه برخورد با کامیتهایی که در ابتدا خالی نیستند و گلچینهای تمیز (clean cherry\-picks) هیچ کامیت بالادستی نیز محسوب نمیشوند، اما پس از بازپایهریزی خالی میشوند (زیرا شامل زیرمجموعهای از تغییرات از پیش موجود در بالادست هستند):
.PP
\fBdrop\fR
.RS 4
کامیت کنار گذاشته میشود\&. این رفتار پیشفرض است\&.
.RE
.PP
\fBkeep\fR
.RS 4
کامیت نگه داشته میشود\&. این گزینه در صورت تعیین
\fB\-\-exec\fR
به طور ضمنی فعال است، مگر آنکه
\fB\-i\fR/\fB\-\-interactive\fR
نیز مشخص شده باشد\&.
.RE
.PP
\fBstop\fR, \fBask\fR
.RS 4
عملیات بازپایهریزی با اعمال شدن کامیت متوقف میشود و به شما امکان میدهد انتخاب کنید که آیا آن را کنار بگذارید، فایلهای بیشتری را ویرایش کنید، یا صرفاً تغییرات خالی را کامیت نمایید\&. این گزینه در صورت تعیین
\fB\-i\fR/\fB\-\-interactive\fR
به طور ضمنی فعال است\&.
\fBask\fR
یک نام مترادف قدیمی و منسوخشده برای
\fBstop\fR
است\&.
.RE
.sp
توجه داشته باشید کامیتهایی که از ابتدا خالی هستند حفظ میشوند (مگر اینکه
\fB\-\-no\-keep\-empty\fR
مشخص شده باشد)، و کامیتهایی که گلچینهای تمیز هستند (همانطور که توسط
\fBgit\fR
\fBlog\fR
\fB\-\-cherry\-mark\fR
\&.\&.\&. تعیین میشود) در یک مرحله اولیه شناسایی شده و کنار گذاشته میشوند (مگر اینکه
\fB\-\-reapply\-cherry\-picks\fR
یا
\fB\-\-keep\-base\fR
ارسال شده باشد)\&.
.sp
همچنین بخش INCOMPATIBLE OPTIONS در ادامه را ببینید\&.
.RE
.PP
\-\-no\-keep\-empty, \-\-keep\-empty
.RS 4
کامیتهایی را که قبل از بازپایهریزی خالی شروع شدهاند (یعنی هیچ تغییری نسبت به والد خود ایجاد نمیکنند) در نتیجه نهایی نگه ندار\&. حالت پیشفرض حفظ کامیتهایی است که خالی شروع میشوند، زیرا ایجاد چنین کامیتهایی نیازمند ارسال فلگ لغوکننده
\fB\-\-allow\-empty\fR
به
\fBgit\fR
\fBcommit\fR
است، که نشان میدهد کاربر کاملاً آگاهانه چنین کامیتی را ایجاد کرده و بنابراین مایل است آن را حفظ کند\&.
.sp
استفاده از این فلگ احتمالاً به ندرت پیش خواهد آمد، زیرا میتوانید صرفاً با شروع یک بازپایهریزی تعاملی و حذف خطوط مربوط به کامیتهایی که نمیخواهید، از شر کامیتهایی که خالی شروع میشوند خلاص شوید\&. این فلگ به عنوان یک میانبر آسان وجود دارد، مثلاً برای مواردی که ابزارهای خارجی کامیتهای خالی متعددی تولید کردهاند و شما میخواهید همه آنها حذف شوند\&.
.sp
برای کامیتهایی که خالی شروع نمیشوند اما پس از بازپایهریزی خالی میگردند، فلگ
\fB\-\-empty\fR
را ببینید\&.
.sp
همچنین بخش INCOMPATIBLE OPTIONS در ادامه را ببینید\&.
.RE
.PP
\-\-reapply\-cherry\-picks, \-\-no\-reapply\-cherry\-picks
.RS 4
تمام گلچینهای تمیز (clean cherry\-picks) هر کامیت بالادست را به جای کنار گذاشتن پیشدستانه آنها، مجدداً اعمال کن\&. (اگر این کامیتها پس از بازپایهریزی خالی شوند، به این دلیل که شامل زیرمجموعهای از تغییرات از پیش موجود در بالادست هستند، رفتار نسبت به آنها توسط فلگ
\fB\-\-empty\fR
کنترل میشود\&.)
.sp
در نبود
\fB\-\-keep\-base\fR
(یا در صورتی که
\fB\-\-no\-reapply\-cherry\-picks\fR
داده شده باشد)، این کامیتها به طور خودکار کنار گذاشته میشوند\&. از آنجا که این امر مستلزم خواندن تمام کامیتهای بالادست است، در مخازنی با تعداد بسیار زیادی کامیت بالادست که نیاز به خوانده شدن دارند میتواند فرآیندی پرهزینه باشد\&. هنگام استفاده از بکاند
\fImerge\fR،
برای هر کامیت کنار گذاشتهشده هشدارهایی صادر میشود (مگر اینکه
\fB\-\-quiet\fR
داده شده باشد)\&. همچنین راهنماییهایی ارائه خواهد شد مگر اینکه
\fBadvice\&.skippedCherryPicks\fR
روی false تنظیم شده باشد (به
\fBgit-config\fR(1)
مراجعه کنید)\&.
.sp
گزینه
\fB\-\-reapply\-cherry\-picks\fR
به rebase امکان میدهد از خواندن تمام کامیتهای بالادست صرفنظر کند، که به طور بالقوه موجب بهبود کارایی و عملکرد میشود\&.
.sp
همچنین بخش INCOMPATIBLE OPTIONS در ادامه را ببینید\&.
.RE
.PP
\-\-allow\-empty\-message
.RS 4
بیاثر (No\-op)\&. پیشتر بازپایهریزی کامیتهای دارای پیام خالی با خطا مواجه میشد و این گزینه آن رفتار را لغو میکرد و اجازه میداد کامیتهای دارای پیام خالی بازپایهریزی شوند\&. اکنون کامیتهای دارای پیام خالی مانع ادامه کار بازپایهریزی نمیشوند\&.
.sp
همچنین بخش INCOMPATIBLE OPTIONS در ادامه را ببینید\&.
.RE
.PP
\-m, \-\-merge
.RS 4
استفاده از راهبردهای ادغام برای بازپایهریزی (پیشفرض)\&.
.sp
توجه داشته باشید که بازپایهریزی ادغامی با بازپخش هر کامیت از شاخه کاری بر روی شاخه
\fI\fR
عمل میکند\&. به همین دلیل، هنگام بروز تداخل در ادغام، سمتی که به عنوان
\fIours\fR
گزارش میشود همان سری کامیتهای بازپایهریزیشده تا این لحظه است که با
\fI\fR
شروع میشود، و سمت
\fItheirs\fR
شاخه کاری است\&. به عبارت دیگر، سمتها جابهجا شدهاند\&.
.sp
همچنین بخش INCOMPATIBLE OPTIONS در ادامه را ببینید\&.
.RE
.PP
\-s , \-\-strategy=
.RS 4
استفاده از راهبرد ادغام دادهشده، به جای مقدار پیشفرض
\fBort\fR\&.
این گزینه به طور ضمنی
\fB\-\-merge\fR
را فعال میکند\&.
.sp
از آنجا که
\fBgit\fR
\fBrebase\fR
هر کامیت از شاخه کاری را بر روی شاخه
\fI\fR
با استفاده از راهبرد دادهشده بازپخش میکند، استفاده از راهبرد
\fBours\fR
صرفاً تمام وصلهها را از
\fI\fR
خالی میکند، که این کار چندان منطقی نیست\&.
.sp
همچنین بخش INCOMPATIBLE OPTIONS در ادامه را ببینید\&.
.RE
.PP
\-X , \-\-strategy\-option=
.RS 4
ارسال به راهبرد ادغام\&. این گزینه به طور ضمنی
\fB\-\-merge\fR
و در صورتی که هیچ راهبردی مشخص نشده باشد،
\fB\-s\fR
\fBort\fR
را فعال میکند\&. به جابهجا شدن
\fIours\fR
و
\fItheirs\fR
همانطور که در بالا برای گزینه
\fB\-m\fR
ذکر شد توجه کنید\&.
.sp
همچنین بخش INCOMPATIBLE OPTIONS در ادامه را ببینید\&.
.RE
.PP
\fB\-\-rerere\-autoupdate\fR, \fB\-\-no\-rerere\-autoupdate\fR
.RS 4
پس از آنکه سازوکار rerere از یک راهحل ثبتشده برای تداخل فعلی جهت بهروزرسانی فایلها در درخت کاری استفاده کرد، به آن اجازه میدهد تا نمایه (index) را نیز با نتیجه حل تداخل بهروزرسانی کند\&. گزینه
\fB\-\-no\-rerere\-autoupdate\fR
راه خوبی برای بررسی مجدد اقدام انجامشده توسط
\fBgit-rerere\fR(1)
و شناسایی ادغامهای نادرست احتمالی است، پیش از آنکه نتیجه با یک دستور جداگانه
\fBgit-add\fR(1)
در نمایه کامیت شود\&.
.RE
.PP
\-S[], \-\-gpg\-sign[=], \-\-no\-gpg\-sign
.RS 4
امضای کامیتها با GPG\&. آرگومان
\fBkeyid\fR
اختیاری است و پیشفرض آن هویت کامیتکننده است؛ در صورت تعیین، باید بدون هیچ فاصلهای به گزینه بچسبد\&.
\fB\-\-no\-gpg\-sign\fR
برای باطل کردن هم متغیر پیکربندی
\fBcommit\&.gpgSign\fR
و هم گزینه قبلی
\fB\-\-gpg\-sign\fR
مفید است\&.
.RE
.PP
\-q, \-\-quiet
.RS 4
حالت بیصدا\&. به طور ضمنی
\fB\-\-no\-stat\fR
را فعال میکند\&.
.RE
.PP
\-v, \-\-verbose
.RS 4
نمایش با جزئیات کامل\&. به طور ضمنی
\fB\-\-stat\fR
را فعال میکند\&.
.RE
.PP
\-\-stat
.RS 4
نمایش گزارش آماری تغییرات (diffstat) از آنچه در بالادست پس از آخرین بازپایهریزی تغییر کرده است\&. این diffstat همچنین توسط گزینه پیکربندی rebase\&.stat کنترل میشود\&.
.RE
.PP
\-n, \-\-no\-stat
.RS 4
گزارش آماری تغییرات (diffstat) را به عنوان بخشی از فرآیند بازپایهریزی نشان نده\&.
.RE
.PP
\-\-no\-verify
.RS 4
این گزینه قلاب pre\-rebase را دور میزند\&. همچنین به
\fBgithooks\fR(5)
مراجعه کنید\&.
.RE
.PP
\-\-verify
.RS 4
اجازه اجرای قلاب pre\-rebase را میدهد، که رفتار پیشفرض است\&. این گزینه میتواند برای باطل کردن
\fB\-\-no\-verify\fR
استفاده شود\&. همچنین به
\fBgithooks\fR(5)
مراجعه کنید\&.
.RE
.PP
\-C
.RS 4
اطمینان از اینکه حداقل
\fI\fR
خط از زمینه (context) پیرامونی قبل و بعد از هر تغییر مطابقت داشته باشد\&. وقتی خطوط کمتری از زمینه پیرامونی وجود دارد، همگی آنها باید مطابقت داشته باشند\&. به طور پیشفرض هیچ زمینهای نادیده گرفته نمیشود\&. به طور ضمنی
\fB\-\-apply\fR
را فعال میکند\&.
.sp
همچنین بخش INCOMPATIBLE OPTIONS در ادامه را ببینید\&.
.RE
.PP
\-\-no\-ff, \-\-force\-rebase, \-f
.RS 4
اجرای مجدد تکتک تمام کامیتهای بازپایهریزیشده به جای فستفوروارد (fast\-forward) روی موارد بدون تغییر\&. این کار تضمین میکند که کل تاریخچه شاخه بازپایهریزیشده از کامیتهای جدید تشکیل شود\&.
.sp
ممکن است پس از بازگردانی ادغام یک شاخه موضوعی (topic branch)، این گزینه برایتان مفید باشد؛ زیرا این گزینه شاخه موضوعی را با کامیتهای تازه بازسازی میکند تا بتوان آن را بدون نیاز به «بازگردانیِ بازگردانی» (revert the reversion) مجدداً با موفقیت ادغام کرد (برای جزئیات به
\m[blue]\fBrevert\-a\-faulty\-merge How\-To\fR\m[]\&\s-2\u[1]\d\s+2
مراجعه کنید)\&.
.RE
.PP
\-\-fork\-point, \-\-no\-fork\-point
.RS 4
استفاده از reflog برای یافتن یک نیای مشترک بهتر میان
\fI\fR
و
\fI\fR
هنگام محاسبه اینکه کدام کامیتها توسط
\fI\fR
معرفی شدهاند\&.
.sp
هنگامی که
\fB\-\-fork\-point\fR
فعال است،
\fIfork_point\fR
به جای
\fI\fR
برای محاسبه مجموعه کامیتها جهت بازپایهریزی استفاده خواهد شد، که در آن
\fIfork_point\fR
نتیجه دستور
\fBgit\fR
\fBmerge\-base\fR
\fB\-\-fork\-point\fR
\fI\fR
\fI\fR
است (به
\fBgit-merge-base\fR(1)
مراجعه کنید)\&. اگر
\fIfork_point\fR
در نهایت خالی باشد،
\fI\fR
به عنوان جایگزین استفاده خواهد شد\&.
.sp
اگر
\fI\fR
یا
\fB\-\-keep\-base\fR
در خط فرمان مشخص شده باشد، حالت پیشفرض
\fB\-\-no\-fork\-point\fR
است، در غیر این صورت پیشفرض
\fB\-\-fork\-point\fR
میباشد\&. همچنین به
\fBrebase\&.forkpoint\fR
در
\fBgit-config\fR(1)
مراجعه کنید\&.
.sp
اگر شاخه شما بر پایه
\fI\fR
بوده باشد، اما
\fI\fR
به عقب بازگردانده شده (rewound) و شاخه شما شامل کامیتهایی باشد که کنار گذاشته شدهاند، این گزینه میتواند به همراه
\fB\-\-keep\-base\fR
برای کنار گذاشتن آن کامیتها از شاخه شما استفاده شود\&.
.sp
همچنین بخش INCOMPATIBLE OPTIONS در ادامه را ببینید\&.
.RE
.PP
\-\-ignore\-whitespace
.RS 4
نادیده گرفتن تفاوتهای فواصل خالی (whitespace) هنگام تلاش برای تطبیق اختلافات\&. در حال حاضر، هر بکاند تقریبی از این رفتار را پیادهسازی میکند:
.PP
بکاند apply
.RS 4
هنگام اعمال یک وصله، تغییرات فواصل خالی در خطوط زمینه را نادیده میگیرد\&. متأسفانه این بدان معناست که اگر خطوط «قدیمی» که توسط وصله جایگزین میشوند فقط در فواصل خالی با فایل موجود تفاوت داشته باشند، به جای اعمال موفقیتآمیز وصله، با یک تداخل ادغام مواجه خواهید شد\&.
.RE
.PP
بکاند merge
.RS 4
هنگام ادغام، خطوطی را که فقط تغییرات فواصل خالی دارند به عنوان بدون تغییر در نظر میگیرد\&. متأسفانه این بدان معناست که هر تکه از وصله (patch hunk) که قصد آن تغییر فواصل خالی و نه هیچ چیز دیگری بوده است کنار گذاشته خواهد شد، حتی اگر طرف دیگر هیچ تغییری که تداخل داشته باشد نداشته باشد\&.
.RE
.RE
.PP
\-\-whitespace=