GIT-REBASE(1) Git Manual GIT-REBASE(1) نام (NAME) git-rebase - بازاعمال کامیت‌ها بر روی سرشاخه جدید خلاصه دستور (SYNOPSIS) git rebase [-i | --interactive] [] [--exec ] [--onto | --keep-base] [ []] git rebase [-i | --interactive] [] [--exec ] [--onto ] --root [] 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 در اولین کامیت دارای مشکل متوقف شده و نشانگرهای تعارض را باقی می‌گذارد. در این حالت می‌توانید یکی از این کارها را انجام دهید: 1. حل کردن تعارض. می‌توانید از git diff برای یافتن نشانگرها (<<<<<<) و اعمال تغییرات جهت رفع تعارض استفاده کنید. برای هر فایلی که ویرایش می‌کنید، باید به گیت اعلام کنید که تعارض رفع شده است. می‌توانید تعارض را با git add به عنوان حل‌شده علامت‌گذاری کنید. پس از حل تمام تعارض‌ها، می‌توانید فرآیند بازاعمال را با دستور زیر ادامه دهید git rebase --continue 2. متوقف کردن git rebase و بازگرداندن شاخه خود به وضعیت اولیه‌اش با git rebase --abort 3. صرف‌نظر کردن از کامیتی که باعث ایجاد تعارض ادغام شد با git rebase --skip اگر شاخه بالادستی را برای بازاعمال بر روی آن تعیین نکنید، بالادست پیکربندی‌شده در گزینه‌های branch..remote و branch..merge استفاده خواهد شد (برای جزئیات به git-config(1) رجوع کنید) و گزینه --fork-point فرض می‌شود. اگر هم‌اکنون روی هیچ شاخه‌ای قرار ندارید یا اگر شاخه فعلی بالادست پیکربندی‌شده‌ای ندارد، عملیات بازاعمال لغو خواهد شد. در اینجا شرح ساده‌شده‌ای از عملکرد git rebase آورده شده است: 1. تهیه فهرستی از تمام کامیت‌های شاخه فعلی شما از زمان انشعاب آن از که کامیت معادلی در ندارند. 2. استخراج (checkout) با معادل git checkout --detach . 3. اعمال مجدد کامیت‌ها، یک به یک، به ترتیب. این شبیه به اجرای git cherry-pick برای هر کامیت است. برای نحوه رسیدگی به ادغام‌ها به REBASING MERGES مراجعه کنید. 4. به‌روزرسانی شاخه شما تا با معادل git checkout -B به کامیت نهایی اشاره کند. نکته هنگام آغاز بازاعمال، ORIG_HEAD طوری تنظیم می‌شود که به کامیت رأس شاخه‌ای که قرار است بازاعمال شود اشاره کند. با این وجود، تضمینی نیست که در پایان بازاعمال نیز ORIG_HEAD همچنان به آن کامیت اشاره داشته باشد، در صورتی که دستورات دیگری که ORIG_HEAD را تغییر می‌دهند (مانند git reset) در طول بازاعمال استفاده شوند. با این حال، رأس قبلی شاخه با استفاده از reflog شاخه فعلی (یعنی @{1}، به gitrevisions(7) مراجعه کنید) در دسترس است. انتقال یک شاخه موضوعی با استفاده از --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 و پارامتر می‌توانند هر شبه‌کامیت (commit-ish) معتبری باشند. گزینه‌های حالت (MODE OPTIONS) گزینه‌های این بخش نمی‌توانند همراه با هیچ گزینه دیگری استفاده شوند، از جمله نه با یکدیگر: --continue فرآیند بازاعمال را پس از رفع تعارض ادغام از سر می‌گیرد. --skip فرآیند بازاعمال را با رد کردن وصله فعلی از سر می‌گیرد. --abort عملیات بازاعمال را لغو کرده و HEAD را به شاخه اصلی بازنشانی می‌کند. اگر مشخص شده باشد زمانی که عملیات بازاعمال آغاز شد، آنگاه HEAD به بازنشانی خواهد شد. در غیر این صورت HEAD به جایی که در زمان آغاز عملیات بازاعمال قرار داشت بازنشانی می‌شود. --quit عملیات بازاعمال را لغو می‌کند، اما HEAD به شاخه اصلی بازگردانده نمی‌شود. در نتیجه، نمایه و درخت کاری نیز بدون تغییر باقی می‌مانند. اگر یک مدخل اندوخته (stash) موقت با استفاده از --autostash ایجاد شده باشد، در فهرست اندوخته ذخیره خواهد شد. --edit-todo ویرایش فهرست کارهای انجام‌دادنی (todo) در طول یک بازاعمال تعاملی. --show-current-patch نمایش وصله فعلی در یک بازاعمال تعاملی یا زمانی که بازاعمال به دلیل تعارض‌ها متوقف شده است. این معادل git show REBASE_HEAD است. گزینه‌ها (OPTIONS) --onto نقطه شروعی که کامیت‌های جدید در آنجا ایجاد می‌شوند. اگر گزینه --onto مشخص نشده باشد، نقطه شروع خواهد بود. می‌تواند هر کامیت معتبری باشد، و نه فقط نام یک شاخه موجود. در یک حالت خاص، در صورتی که دقیقاً یک پایه ادغام (merge base) وجود داشته باشد، می‌توانید از "A...B" به عنوان میان‌بری برای پایه ادغام A و B استفاده کنید. می‌توانید حداکثر یکی از A یا B را حذف کنید، که در این حالت مقدار پیش‌فرض آن HEAD خواهد بود. برای مثال‌ها، بخش TRANSPLANTING A TOPIC BRANCH WITH --ONTO در بالا را ببینید. --keep-base نقطه شروع برای ایجاد کامیت‌های جدید را روی پایه ادغام (merge base) و تنظیم می‌کند. اجرای git rebase --keep-base معادل اجرای git rebase --reapply-cherry-picks --no-fork-point --onto ... است. این گزینه در مواردی مفید است که در حال توسعه یک قابلیت بر روی یک شاخه بالادست هستید. در حالی که روی این قابلیت کار می‌شود، شاخه بالادست ممکن است جلو برود و بازپایه‌ریزی مداوم روی سرشاخه بالادست ایده چندان مناسبی نباشد، بلکه حفظ کامیت پایه همان‌طور که هست ترجیح داده شود. از آنجا که کامیت پایه بدون تغییر باقی می‌ماند، این گزینه برای جلوگیری از گم شدن کامیت‌ها به طور ضمنی --reapply-cherry-picks را فعال می‌کند. اگرچه هم این گزینه و هم --fork-point پایه ادغام میان و را پیدا می‌کنند، اما این گزینه از پایه ادغام به عنوان نقطه شروع که کامیت‌های جدید روی آن ایجاد خواهند شد استفاده می‌کند، در حالی که --fork-point از پایه ادغام برای تعیین مجموعه کامیت‌هایی که بازپایه‌ریزی خواهند شد بهره می‌گیرد. همچنین بخش INCOMPATIBLE OPTIONS در ادامه را ببینید. شاخه بالادست برای مقایسه با آن. می‌تواند هر کامیت معتبری باشد، و نه فقط نام یک شاخه موجود. پیش‌فرض، شاخه بالادستِ پیکربندی‌شده برای شاخه فعلی است. شاخه کاری؛ پیش‌فرض HEAD است. --apply استفاده از راهبردهای اعمال (apply) برای بازپایه‌ریزی (با فراخوانی درونی git-am). این گزینه ممکن است در آینده، زمانی که بک‌اند merge بتواند همه کارهای بک‌اند apply را انجام دهد، به یک دستور بی‌اثر (no-op) تبدیل شود. همچنین بخش INCOMPATIBLE OPTIONS در ادامه را ببینید. --empty=(drop|keep|stop) نحوه برخورد با کامیت‌هایی که در ابتدا خالی نیستند و گلچین‌های تمیز (clean cherry-picks) هیچ کامیت بالادستی نیز محسوب نمی‌شوند، اما پس از بازپایه‌ریزی خالی می‌شوند (زیرا شامل زیرمجموعه‌ای از تغییرات از پیش موجود در بالادست هستند): drop کامیت کنار گذاشته می‌شود. این رفتار پیش‌فرض است. keep کامیت نگه داشته می‌شود. این گزینه در صورت تعیین --exec به طور ضمنی فعال است، مگر آنکه -i/--interactive نیز مشخص شده باشد. stop, ask عملیات بازپایه‌ریزی با اعمال شدن کامیت متوقف می‌شود و به شما امکان می‌دهد انتخاب کنید که آیا آن را کنار بگذارید، فایل‌های بیشتری را ویرایش کنید، یا صرفاً تغییرات خالی را کامیت نمایید. این گزینه در صورت تعیین -i/--interactive به طور ضمنی فعال است. ask یک نام مترادف قدیمی و منسوخ‌شده برای stop است. توجه داشته باشید کامیت‌هایی که از ابتدا خالی هستند حفظ می‌شوند (مگر اینکه --no-keep-empty مشخص شده باشد)، و کامیت‌هایی که گلچین‌های تمیز هستند (همان‌طور که توسط git log --cherry-mark ... تعیین می‌شود) در یک مرحله اولیه شناسایی شده و کنار گذاشته می‌شوند (مگر اینکه --reapply-cherry-picks یا --keep-base ارسال شده باشد). همچنین بخش INCOMPATIBLE OPTIONS در ادامه را ببینید. --no-keep-empty, --keep-empty کامیت‌هایی را که قبل از بازپایه‌ریزی خالی شروع شده‌اند (یعنی هیچ تغییری نسبت به والد خود ایجاد نمی‌کنند) در نتیجه نهایی نگه ندار. حالت پیش‌فرض حفظ کامیت‌هایی است که خالی شروع می‌شوند، زیرا ایجاد چنین کامیت‌هایی نیازمند ارسال فلگ لغوکننده --allow-empty به git commit است، که نشان می‌دهد کاربر کاملاً آگاهانه چنین کامیتی را ایجاد کرده و بنابراین مایل است آن را حفظ کند. استفاده از این فلگ احتمالاً به ندرت پیش خواهد آمد، زیرا می‌توانید صرفاً با شروع یک بازپایه‌ریزی تعاملی و حذف خطوط مربوط به کامیت‌هایی که نمی‌خواهید، از شر کامیت‌هایی که خالی شروع می‌شوند خلاص شوید. این فلگ به عنوان یک میان‌بر آسان وجود دارد، مثلاً برای مواردی که ابزارهای خارجی کامیت‌های خالی متعددی تولید کرده‌اند و شما می‌خواهید همه آن‌ها حذف شوند. برای کامیت‌هایی که خالی شروع نمی‌شوند اما پس از بازپایه‌ریزی خالی می‌گردند، فلگ --empty را ببینید. همچنین بخش INCOMPATIBLE OPTIONS در ادامه را ببینید. --reapply-cherry-picks, --no-reapply-cherry-picks تمام گلچین‌های تمیز (clean cherry-picks) هر کامیت بالادست را به جای کنار گذاشتن پیش‌دستانه آن‌ها، مجدداً اعمال کن. (اگر این کامیت‌ها پس از بازپایه‌ریزی خالی شوند، به این دلیل که شامل زیرمجموعه‌ای از تغییرات از پیش موجود در بالادست هستند، رفتار نسبت به آن‌ها توسط فلگ --empty کنترل می‌شود.) در نبود --keep-base (یا در صورتی که --no-reapply-cherry-picks داده شده باشد)، این کامیت‌ها به طور خودکار کنار گذاشته می‌شوند. از آنجا که این امر مستلزم خواندن تمام کامیت‌های بالادست است، در مخازنی با تعداد بسیار زیادی کامیت بالادست که نیاز به خوانده شدن دارند می‌تواند فرآیندی پرهزینه باشد. هنگام استفاده از بک‌اند merge، برای هر کامیت کنار گذاشته‌شده هشدارهایی صادر می‌شود (مگر اینکه --quiet داده شده باشد). همچنین راهنمایی‌هایی ارائه خواهد شد مگر اینکه advice.skippedCherryPicks روی false تنظیم شده باشد (به git- config(1) مراجعه کنید). گزینه --reapply-cherry-picks به rebase امکان می‌دهد از خواندن تمام کامیت‌های بالادست صرف‌نظر کند، که به طور بالقوه موجب بهبود کارایی و عملکرد می‌شود. همچنین بخش INCOMPATIBLE OPTIONS در ادامه را ببینید. --allow-empty-message بی‌اثر (No-op). پیش‌تر بازپایه‌ریزی کامیت‌های دارای پیام خالی با خطا مواجه می‌شد و این گزینه آن رفتار را لغو می‌کرد و اجازه می‌داد کامیت‌های دارای پیام خالی بازپایه‌ریزی شوند. اکنون کامیت‌های دارای پیام خالی مانع ادامه کار بازپایه‌ریزی نمی‌شوند. همچنین بخش INCOMPATIBLE OPTIONS در ادامه را ببینید. -m, --merge استفاده از راهبردهای ادغام برای بازپایه‌ریزی (پیش‌فرض). توجه داشته باشید که بازپایه‌ریزی ادغامی با بازپخش هر کامیت از شاخه کاری بر روی شاخه عمل می‌کند. به همین دلیل، هنگام بروز تداخل در ادغام، سمتی که به عنوان ours گزارش می‌شود همان سری کامیت‌های بازپایه‌ریزی‌شده تا این لحظه است که با شروع می‌شود، و سمت theirs شاخه کاری است. به عبارت دیگر، سمت‌ها جابه‌جا شده‌اند. همچنین بخش INCOMPATIBLE OPTIONS در ادامه را ببینید. -s , --strategy= استفاده از راهبرد ادغام داده‌شده، به جای مقدار پیش‌فرض ort. این گزینه به طور ضمنی --merge را فعال می‌کند. از آنجا که git rebase هر کامیت از شاخه کاری را بر روی شاخه با استفاده از راهبرد داده‌شده بازپخش می‌کند، استفاده از راهبرد ours صرفاً تمام وصله‌ها را از خالی می‌کند، که این کار چندان منطقی نیست. همچنین بخش INCOMPATIBLE OPTIONS در ادامه را ببینید. -X , --strategy-option= ارسال به راهبرد ادغام. این گزینه به طور ضمنی --merge و در صورتی که هیچ راهبردی مشخص نشده باشد، -s ort را فعال می‌کند. به جابه‌جا شدن ours و theirs همان‌طور که در بالا برای گزینه -m ذکر شد توجه کنید. همچنین بخش INCOMPATIBLE OPTIONS در ادامه را ببینید. --rerere-autoupdate, --no-rerere-autoupdate پس از آنکه سازوکار rerere از یک راه‌حل ثبت‌شده برای تداخل فعلی جهت به‌روزرسانی فایل‌ها در درخت کاری استفاده کرد، به آن اجازه می‌دهد تا نمایه (index) را نیز با نتیجه حل تداخل به‌روزرسانی کند. گزینه --no-rerere-autoupdate راه خوبی برای بررسی مجدد اقدام انجام‌شده توسط git-rerere(1) و شناسایی ادغام‌های نادرست احتمالی است، پیش از آنکه نتیجه با یک دستور جداگانه git-add(1) در نمایه کامیت شود. -S[], --gpg-sign[=], --no-gpg-sign امضای کامیت‌ها با GPG. آرگومان keyid اختیاری است و پیش‌فرض آن هویت کامیت‌کننده است؛ در صورت تعیین، باید بدون هیچ فاصله‌ای به گزینه بچسبد. --no-gpg-sign برای باطل کردن هم متغیر پیکربندی commit.gpgSign و هم گزینه قبلی --gpg-sign مفید است. -q, --quiet حالت بی‌صدا. به طور ضمنی --no-stat را فعال می‌کند. -v, --verbose نمایش با جزئیات کامل. به طور ضمنی --stat را فعال می‌کند. --stat نمایش گزارش آماری تغییرات (diffstat) از آنچه در بالادست پس از آخرین بازپایه‌ریزی تغییر کرده است. این diffstat همچنین توسط گزینه پیکربندی rebase.stat کنترل می‌شود. -n, --no-stat گزارش آماری تغییرات (diffstat) را به عنوان بخشی از فرآیند بازپایه‌ریزی نشان نده. --no-verify این گزینه قلاب pre-rebase را دور می‌زند. همچنین به githooks(5) مراجعه کنید. --verify اجازه اجرای قلاب pre-rebase را می‌دهد، که رفتار پیش‌فرض است. این گزینه می‌تواند برای باطل کردن --no-verify استفاده شود. همچنین به githooks(5) مراجعه کنید. -C اطمینان از اینکه حداقل خط از زمینه (context) پیرامونی قبل و بعد از هر تغییر مطابقت داشته باشد. وقتی خطوط کمتری از زمینه پیرامونی وجود دارد، همگی آن‌ها باید مطابقت داشته باشند. به طور پیش‌فرض هیچ زمینه‌ای نادیده گرفته نمی‌شود. به طور ضمنی --apply را فعال می‌کند. همچنین بخش INCOMPATIBLE OPTIONS در ادامه را ببینید. --no-ff, --force-rebase, -f اجرای مجدد تک‌تک تمام کامیت‌های بازپایه‌ریزی‌شده به جای فست‌فوروارد (fast-forward) روی موارد بدون تغییر. این کار تضمین می‌کند که کل تاریخچه شاخه بازپایه‌ریزی‌شده از کامیت‌های جدید تشکیل شود. ممکن است پس از بازگردانی ادغام یک شاخه موضوعی (topic branch)، این گزینه برایتان مفید باشد؛ زیرا این گزینه شاخه موضوعی را با کامیت‌های تازه بازسازی می‌کند تا بتوان آن را بدون نیاز به «بازگردانیِ بازگردانی» (revert the reversion) مجدداً با موفقیت ادغام کرد (برای جزئیات به revert-a-faulty-merge How-To[1] مراجعه کنید). --fork-point, --no-fork-point استفاده از reflog برای یافتن یک نیای مشترک بهتر میان و هنگام محاسبه این‌که کدام کامیت‌ها توسط معرفی شده‌اند. هنگامی که --fork-point فعال است، fork_point به جای برای محاسبه مجموعه کامیت‌ها جهت بازپایه‌ریزی استفاده خواهد شد، که در آن fork_point نتیجه دستور git merge-base --fork-point است (به git-merge-base(1) مراجعه کنید). اگر fork_point در نهایت خالی باشد، به عنوان جایگزین استفاده خواهد شد. اگر یا --keep-base در خط فرمان مشخص شده باشد، حالت پیش‌فرض --no-fork-point است، در غیر این صورت پیش‌فرض --fork-point می‌باشد. همچنین به rebase.forkpoint در git-config(1) مراجعه کنید. اگر شاخه شما بر پایه بوده باشد، اما به عقب بازگردانده شده (rewound) و شاخه شما شامل کامیت‌هایی باشد که کنار گذاشته شده‌اند، این گزینه می‌تواند به همراه --keep-base برای کنار گذاشتن آن کامیت‌ها از شاخه شما استفاده شود. همچنین بخش INCOMPATIBLE OPTIONS در ادامه را ببینید. --ignore-whitespace نادیده گرفتن تفاوت‌های فواصل خالی (whitespace) هنگام تلاش برای تطبیق اختلافات. در حال حاضر، هر بک‌اند تقریبی از این رفتار را پیاده‌سازی می‌کند: بک‌اند apply هنگام اعمال یک وصله، تغییرات فواصل خالی در خطوط زمینه را نادیده می‌گیرد. متأسفانه این بدان معناست که اگر خطوط «قدیمی» که توسط وصله جایگزین می‌شوند فقط در فواصل خالی با فایل موجود تفاوت داشته باشند، به جای اعمال موفقیت‌آمیز وصله، با یک تداخل ادغام مواجه خواهید شد. بک‌اند merge هنگام ادغام، خطوطی را که فقط تغییرات فواصل خالی دارند به عنوان بدون تغییر در نظر می‌گیرد. متأسفانه این بدان معناست که هر تکه از وصله (patch hunk) که قصد آن تغییر فواصل خالی و نه هیچ چیز دیگری بوده است کنار گذاشته خواهد شد، حتی اگر طرف دیگر هیچ تغییری که تداخل داشته باشد نداشته باشد. --whitespace=