Git Rebase چیست؟ بازچینی Commitها روی پایهٔ جدید

Rebase مسئلهٔ «Branch من از main عقب افتاده و می‌خواهم تغییراتم را روی نوک جدید پیاده کنم» را با بازپخش Commitها حل می‌کند. به‌جای یک merge commit که دو خط را به هم گره بزند، Git انگار Commitهای شما را از پایهٔ قدیمی جدا می‌کند و یکی‌یکی روی پایهٔ جدید اعمال می‌کند. نتیجه اغلب تاریخچهٔ خطی‌تر است — با هزینهٔ تغییر hash و نیاز محتمل به force push.

Pro Git فصل Rebasing و مستندات git-rebase همین مدل replay را شرح می‌دهند. مقالهٔ ۲۱۱ مقایسه با Merge است؛ اینجا خود مکانیک، interactive، و قانون تاریخچهٔ عمومی.

پاسخ کوتاه

git rebase پایهٔ یک زنجیره Commit را جابه‌جا می‌کند: Commitهای بعد از merge base روی نوک Branch مقصد (مثلاً main) دوباره اعمال می‌شوند و Commitهای جدید با hash تازه ساخته می‌شوند. برای به‌روز کردن feature از main رایج است. روی Commitهایی که دیگران بر پایهٔ آن‌ها کار کرده‌اند، rebase بدون هماهنگی مخرب است.

Rebase تاریخچه را دوباره می‌نویسد؛ روی Branch خصوصی ابزار تمیزکاری است، روی تاریخچهٔ مشترک اسلحه.

مکانیک گام‌به‌گام

bash

git switch feature/x git fetch origin git rebase origin/main # در صورت conflict: حل کن، git add، سپس: # git rebase --continue # یا git rebase --abort

در هر گام ممکن است Conflict بیاید — شبیه Merge ولی پشت‌سرهم برای هر Commit. بعد از اتمام، Branch شما از نوک main منشعب به نظر می‌رسد. اگر قبلاً به Remote Push کرده بودید، معمولاً به --force-with-lease نیاز دارید نه force کور.

چرا کسی Rebase می‌خواهد؟

• تاریخچهٔ خطی برای خواندن git log --graph.
• به‌روز کردن فیچر بدون merge commit میانی روی خود Branch.
• تمیز کردن Commitهای WIP قبل از Review با interactive rebase.

آنچه نمی‌خرد: حذف نیاز به فهم Conflict، یا جایگزین Review. فقط شکل تاریخچه عوض می‌شود.

Interactive rebase: ویرایش داستان

bash

git rebase -i HEAD~5

در ویرایشگر می‌توانید pick را به squash/fixup/reword/edit/drop تغییر دهید تا پیام‌ها ادغام یا اصلاح شوند. مناسب قبل از باز کردن PR روی Branch شخصی. بعد از اینکه دیگران همان Commitها را Pull کردند، interactive روی همان بازه معمولاً ممنوع عملی است مگر توافق تیمی.

جدول: امن در برابر ناامن

Force-with-lease نه Force کور

پس از rebase، تاریخچهٔ Remote با محلی واگرا می‌شود. --force-with-lease اگر کسی در این فاصله Commit جدید Push کرده باشد عملیات را رد می‌کند؛ ایمن‌تر از --force است. باز هم قرارداد تیم مقدم است.

Rebase در برابر به‌روز کردن با Merge

Merge origin/main به feature یک merge commit روی feature می‌سازد و hashهای قبلی شما را حفظ می‌کند. Rebase همان به‌روزرسانی را با replay انجام می‌دهد و hashها عوض می‌شوند. هیچ‌کدام همیشه برتر نیست؛ ۲۱۱ معیار می‌دهد.

اشتباه‌های رایج

1. Rebase کردن main که دیگران از آن Clone کرده‌اند.
2. Forget کردن abort وقتی Conflict از کنترل خارج شده.
3. Interactive squash بعد از Approve بدون اطلاع Reviewer — diff نهایی ممکن است همان باشد ولی hash و مکالمه عوض حس شود.
4. استفاده از rebase برای «پنهان کردن» Commit بد که Secret داشته؛ Secret در تاریخچهٔ قدیمی Remote می‌ماند مگر پاکسازی تخصصی.

مثال: به‌روز کردن فیچر از main

feature سه Commit دارد و main جلو رفته. مسیر امن شخصی:

bash

git switch feature/paywall git fetch origin git rebase origin/main # حل conflict در صورت نیاز git push --force-with-lease

در توضیحات PR یک خط بنویسید که rebase انجام شده تا Reviewer از تغییر hash تعجب نکند.

قانون طلایی با مثال نقض

اگر روی Branch مشترکی rebase کنید که همکارتان دیروز Clone کرده، او با Push معمولی رد می‌شود و با Pull ممکن است Commitهای تکراری یا Conflictهای گیج‌کننده ببیند. هماهنگی، یا اجتناب، یا استفاده از Merge برای آن Branch مشترک، هزینهٔ کمتری از «تاریخچه زیبا» دارد.

بازیابی وقتی rebase بد پیش رفت

• اگر هنوز در عملیات هستید: --abort.
• اگر تمام شده و می‌خواهید برگردید: reflog معمولاً نوک قبلی را نشان می‌دهد؛ با احتیاط reset (جزئیات در ۲۱۳).
• روی Remote، force دوباره فقط با lease و اطلاع تیم.

rebase --onto برای جراحی تاریخچه

وقتی بخشی از Commitها باید به پایهٔ دیگری منتقل شوند (مثلاً از روی Branch اشتباه)، --onto کنترل دقیق می‌دهد. قبل از استفاده روی کار واقعی، روی مخزن کپی تمرین کنید؛ اشتباه اینجا گران است.

تفاوت معنایی با cherry-pick

cherry-pick یک Commit را کپی مفهومی می‌کند؛ rebase زنجیره‌ای را جابه‌جا می‌کند. برای یک Fix فوری روی release، cherry-pick رایج‌تر است. برای به‌روز کردن کل فیچر، rebase یا merge. قاطی واژه‌ها در چت تیم باعث فرمان اشتباه می‌شود.

Rebase در CI و ربات‌ها

بعضی ربات‌ها Branch را خودکار از main rebase می‌کنند. مفید است اگر conflict را انسان بفهمد؛ مخرب است اگر بدون اطلاع force شود. تنظیمات ربات را بخشی از سیاست Git تیم بدانید نه جزئیات پنهان.

چک‌لیست قبل از force-with-lease

1. آیا فقط من روی این Branch کار می‌کنم؟
2. آیا Reviewer از بازنویسی تاریخچه خبر دارد؟
3. آیا lease استفاده می‌کنم نه force کور؟
4. آیا نسخهٔ قبلی در reflog قابل برگشت است اگر لازم شد؟

اگر به یکی از سه سؤال اول نه محکم می‌گویید، یک‌بار دیگر به Merge برای به‌روزرسانی فکر کنید.

سوالات متداول

آیا rebase داده را پاک می‌کند؟

Commitهای بازپخش‌شده hash جدید می‌گیرند؛ اشیاء قدیمی تا garbage collection ممکن است محلی بمانند. از دید Remote بعد از force، تاریخچهٔ دیده‌شده عوض می‌شود.

pull --rebase چیست؟

به‌جای merge هنگام Pull، Commitهای محلی شما را روی نوک Remote replay می‌کند. برای همگام‌سازی شخصی رایج است؛ سیاست تیم را یکدست کنید.

onto چه زمانی؟

وقتی می‌خواهید فقط بخشی از Commitها را به پایهٔ دیگری منتقل کنید؛ پیشرفته‌تر از rebase سادهٔ روزمره.

خلاصه

Rebase بازچینی و بازپخش Commitها روی پایهٔ جدید است برای تاریخچهٔ خطی‌تر و تمیزکاری Branch خصوصی. هزینهٔ آن تغییر hash و ریسک force push است. قانون طلایی Pro Git را جدی بگیرید: تاریخچه‌ای را که دیگران به آن تکیه کرده‌اند بازنویسی نکنید.

برای انتخاب بین Merge و Rebase سراغ ۲۱۱ بروید.

منابع و مراجع

• Pro Git — Rebasing — https://git-scm.com/book/en/v2/Git-Branching-Rebasing
• git-rebase documentation — https://git-scm.com/docs/git-rebase
• GitHub Docs — About Git rebase — https://docs.github.com/en/get-started/using-git/about-git-rebase
• GitHub Docs — Resolving merge conflicts after a git rebase — https://docs.github.com/en/get-started/using-git/resolving-merge-conflicts-after-a-git-rebase
• Pro Git — The Golden Rule of Rebasing — https://git-scm.com/book/en/v2/Git-Branching-Rebasing