Merge در برابر Rebase: کدام را چه زمانی انتخاب کنیم؟
جدول مقایسهٔ Merge و Rebase از دید تاریخچه، ایمنی، Conflict و همکاری تیمی؛ معیار انتخاب بر اساس زمینه — نه شعار بهترین. منابع: Pro Git و GitHub Docs.
بنیانگذار و مهندس محصول
بحث Merge در برابر Rebase اغلب به شعار «همیشه خطی» یا «همیشه تاریخچه واقعی» تبدیل میشود. هر دو ابزار پاسخ به یک نیازاند: ادغام کار دو خط توسعه. تفاوت در شکل تاریخچه، حفظ یا بازنویسی hash، و هزینهٔ همکاری است. هیچکدام بهصورت مطلق بهترین نیست؛ معیار زمینه است: آیا تاریخچه عمومی است؟ آیا تیم force push را میفهمد؟ آیا ردیابی merge commit برای Release مهم است؟
Pro Git هر دو را آموزش میدهد و برای Rebase قانون طلایی میگذارد. GitHub هم در PR سه روش merge/squash/rebase-and-merge را میدهد تا انتخاب محصولی باشد نه ایدئولوژیک. این مقاله جدول معیارها و سناریوها را جمع میکند.
پاسخ کوتاه
Merge با حفظ توپولوژی (و اغلب merge commit) دو خط را به هم گره میزند و hashهای موجود را دست نمیزند — برای بهروزرسانی امن Branch مشترک و ثبت «اینجا ادغام شد» مناسب است. Rebase Commitها را روی پایهٔ جدید replay میکند، تاریخچه را خطیتر نشان میدهد، ولی hash عوض میکند و روی تاریخچهٔ اشتراکی خطرناک است. انتخاب را با جدول زیر و سیاست تیم انجام دهید؛ نه با ترند توییتر.
ابزار درست آن است که تیم بدون سورپرایز بتواند با آن Recover کند — نه آنکه در دمو زیباتر به نظر برسد.
یادآوری یکخطی هر کدام
- Merge: ترکیب با جد مشترک؛ ممکن است fast-forward یا merge commit.
- Rebase: بازپخش زنجیره روی نوک جدید؛ معمولاً بدون merge commit میانی.
- Squash merge (هاست): نتیجهٔ محصولی یک Commit روی هدف؛ جزئیات میانی PR فشرده میشود.
جدول مقایسهٔ معیارمحور
| معیار | Merge | Rebase |
|---|---|---|
| شکل تاریخچه | گره ادغام / توپولوژی واقعی | اغلب خطیتر |
| Hash Commitهای قبلی شما | ثابت میماند | عوض میشود (replay) |
| نیاز به force push بعد از Share | معمولاً خیر | اغلب بله |
| ردیابی «کی فیچر ادغام شد» | با merge commit واضح | کمتر واضح مگر PR/هاست |
| Conflict | یکبار در ادغام | ممکن است بهازای چند Commit |
| ایمنی روی Branch مشترک | بالاتر بهصورت پیشفرض | پایینتر بدون هماهنگی |
| تمیزکاری WIP قبل از PR | ضعیفتر (مگر squash جدا) | قوی با interactive |
| منحنی یادگیری Recovery | آشناتر برای خیلیها | abort/continue و lease |
سناریوهایی که Merge معمولاً مناسبتر است
- ادغام feature به main در تیمی که merge commit را برای ردیابی میخواهد (--no-ff).
- بهروز کردن Branch مشترکی که چند نفر روی آن Push میکنند.
- وقتی سیاست «هرگز تاریخچهٔ Remote را بازنویسی نکن» غالب است.
- Release branchهایی که audit توپولوژی مهم است.
سناریوهایی که Rebase معمولاً مناسبتر است
- بهروز کردن Branch شخصی از main قبل از Review، بدون شلوغی merge commit روی خود فیچر.
- Interactive تمیز کردن چند Commit WIP قبل از اولین Push عمومی یا قبل از درخواست Review.
- تیمی که صریحاً تاریخچهٔ خطی روی main میخواهد و rebase-and-merge یا FF-only را بلد است.
- pull --rebase برای همگامسازی کار محلی کوتاه با Remote شخصی.
نقش Squash و دکمههای GitHub
Squash merge روی GitHub میتواند مصالحه باشد: Review روی چند Commit انجام شود، ولی main یک Commit تمیز بگیرد. Rebase-and-merge خطی میکند بدون squash کردن همه به یکی. Merge commit کلاسیک توپولوژی را نگه میدارد. هر سه معتبرند؛ مهم یکدست بودن مخزن و مستند کردن در CONTRIBUTING است.
| روش PR در GitHub | نتیجه روی شاخهٔ پایه | نکته |
|---|---|---|
| Create a merge commit | یک merge commit | ردیابی واضح PR |
| Squash and merge | یک Commit فشرده | main خلوت؛ جزئیات در PR |
| Rebase and merge | Commitهای خطیشده | نیاز به درک hash/PR |
چارچوب تصمیم سریع برای تیم
- آیا Branch فقط یک نویسنده دارد؟ اگر بله، rebase آزادتر است.
- آیا بعد از Push دیگران ممکن است بر پایهٔ همان Commitها کار کنند؟ اگر بله، merge امنتر است.
- آیا اولویت خوانایی log خطی است یا حفظ واقعیت ادغام؟ پاسخ را بنویسید نه فرض کنید.
- آیا همه force-with-lease را بلدان؟ اگر نه، آموزش قبل از اجباری کردن rebase.
اشتباههای رایج در این مقایسه
- اعلام بهترین مطلق بدون معیار.
- Rebase روی main عمومی برای «زیبایی».
- Mergeهای پیاپی بدون معنی روی feature و شلوغ کردن PR بدون نیاز — گاهی rebase شخصی قبل از Merge نهایی تمیزتر است.
- عوض کردن هفتگی سیاست PR بدون اطلاع تیم.
ماتریس تصمیم تکصفحهای
اگر فقط یکی از این جملات را روی دیوار تیم بگذارید:
- تاریخچهٔ اشتراکی را بازنویسی نکنید مگر با توافق و ابزار ایمن.
- Branch شخصی را میتوانید rebase کنید تا PR خوانا شود.
- ورود به main را با یک روش هاست (merge/squash/rebase) یکدست کنید.
- زیبایی log هرگز بر ایمنی همکاری و قابلیت Rollback مقدم نیست.
مثال جریان ترکیبی توصیهشده برای بسیاری تیمها
۱) روی feature از origin/main بهصورت rebase یا merge بهروز بمانید (ترجیح تیم). ۲) PR باز کنید و Review بگیرید. ۳) برای ورود به main از سیاست ثابت مخزن استفاده کنید — مثلاً squash برای فیچرهای کوچک، merge commit برای فیچرهای بزرگ با نیاز ردیابی. ۴) از rebase روی خود main پرهیز کنید.
این جریان «بهترین جهانی» نیست؛ نمونهای است که معیارهای جدول را متعادل میکند و در عمل کمتر سورپرایز میسازد.
آموزش تیم بدون جنگ ایدئولوژیک
یک کارگاه ۳۰ دقیقهای با مخزن آزمایشی که هم merge و هم rebase را روی یک سناریو نشان دهد، بیشتر از ده پیام در چت ارزش دارد. خروجی کارگاه باید سند یکصفحهای سیاست باشد نه ترجیح فرد با صدای بلندتر.
جدول دوم: هزینهٔ اشتباه
| اشتباه | عمدتاً با Merge | عمدتاً با Rebase |
|---|---|---|
| ادغام زودرس بدون تست | با Revert قابل مدیریتتر | اگر force شده، پیچیدهتر |
| بازنویسی اشتراکی | نادر | شایع اگر بیاحتیاطی |
| تاریخچه شلوغ | ممکن است | کمتر روی همان Branch |
| غافلگیری Reviewer از hash | کم | زیاد بعد از force |
از این جدول برای آموزش استفاده کنید نه برای اعلام برندهٔ مطلق. وزن ستونها در تیم شما ممکن است فرق کند — همان نکتهٔ محوری این مقاله است.
پیوند سیاست با Branch protection
اگر required linear history روی مخزن روشن است، عملاً مسیر Merge با merge commit محدود میشود و باید FF یا rebase/squash را بفهمید. سیاست هاست را قبل از اجبار فردی همتیمها مستند کنید.
زبان مشترک برای بحث تیم
بهجای «Rebase بهتر است»، بگویید: «میخواهم تاریخچهٔ main خطی باشد چون ابزار Release ما فرض FF دارد» یا «میخواهم merge commit بماند چون audit توپولوژی میخواهد». معیار صریح اختلاف را قابلحل میکند. اگر معیار ندارید، اول معیار بنویسید بعد ابزار را انتخاب کنید.
جمعبندی تصمیم بدون برندهٔ مطلق
Merge و Rebase هر دو رسمی، مستند، و در Pro Git و GitHub Docs پشتیبانی میشوند. برنده آن است که با ایمنی همگامسازی، مهارت تیم، و نیاز Release شما جور باشد. جدولهای این مقاله را چاپ کنید، وزن محلی بدهید، و همان را در CONTRIBUTING بگذارید — پایان جنگ شعاری.
سوالات متداول
اگر یکی Merge دوست دارد و یکی Rebase؟
سیاست مخزن را مکتوب کنید. اختلاف سلیقه بدون قرارداد = Conflict اجتماعی بیشتر از Conflict فایل.
آیا میتوان هر دو را در یک جریان داشت؟
بلهٔ رایج: روی feature از rebase برای بهروز ماندن با main استفاده کنید؛ ورود به main با merge commit یا squash طبق هاست. این ترکیب در بسیاری تیمها کار میکند.
از کجا یاد بگیرم بدون خراب کردن؟
مخزن آزمایشی، دو Branch، یکبار merge و یکبار rebase، سپس --graph را مقایسه کنید. روی مخزن واقعی از Branch پرتاولویت شروع نکنید.
خلاصه
Merge تاریخچه را با گره ادغام (یا FF) گسترش میدهد و hashها را حفظ میکند؛ Rebase بازپخش میکند و خطیتر میسازد با هزینهٔ بازنویسی. جدول معیارها را برای زمینهٔ خودتان وزن بدهید. بهترین انتخاب آن است که با ایمنی همکاری و قابلیت بازیابی تیم سازگار باشد — نه یک شعار جهانی.
جزئیات مکانیکی: ۲۰۶ برای Merge، ۲۱۰ برای Rebase، ۲۰۷ برای Conflict.
منابع و مراجع
- Pro Git — Basic Merging — https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
- Pro Git — Rebasing — https://git-scm.com/book/en/v2/Git-Branching-Rebasing
- git-merge documentation — https://git-scm.com/docs/git-merge
- git-rebase documentation — https://git-scm.com/docs/git-rebase
- GitHub Docs — About pull request merges — https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges
- GitHub Docs — About Git rebase — https://docs.github.com/en/get-started/using-git/about-git-rebase
نویسنده
سهیل ابراهیمپور بنیانگذار FutureForge است. روی طراحی محصول، معماری و استقرار نرمافزار سفارشی کار میکند.
یادداشتهای مرتبط
اگر در انتخاب معماری یا مسیر توسعه مطمئن نیستید، میتوانید درباره پروژه صحبت کنیم.
مسئله و محدودیت را بنویسید. اگر تطابق داشته باشیم، برای گفتگو هماهنگ میکنیم.
