聲明：本文僅限于簡(jiǎn)書發(fā)布林螃，其他第三方網(wǎng)站均為盜版昼丑，原文地址： merge squash 和 merge rebase 區(qū)別
在團(tuán)隊(duì)合作中，毫無(wú)疑問，我們需要一個(gè)版本管理工具扎拣，相對(duì)于 SVN 這種在我們看來(lái)是老古董的工具桃焕，Git 在年輕化的團(tuán)隊(duì)中更受歡迎瓶盛。并不僅僅是跟著大神們（Linux系）的路子在走惯疙，所以感覺很牛逼，而是 Git 真的很牛逼荚斯，當(dāng)然埠居，牛逼的同時(shí)你需要的學(xué)習(xí)曲線也是很陡的。
這幾天我就遇到了一個(gè)問題拐格，其實(shí)也不是遇到問題，而是遇到了疑惑刑赶，那就是我在 github 系統(tǒng)中 merge 同時(shí)的 PR 的時(shí)候發(fā)現(xiàn)有好幾個(gè)選項(xiàng)懂衩，但是浊洞，卻說(shuō)不清楚這幾個(gè)選項(xiàng)分別代表什么含義枷餐，所以就稍微花了點(diǎn)時(shí)間了解了下，順帶做個(gè)總結(jié)。
merge 的幾種形式
在 merge pr 的時(shí)候，默認(rèn)是有三種選項(xiàng)的冻河，分別是
- 普通的 merge
- rebase merge
- squash merge
這其實(shí)對(duì)應(yīng)于我們?cè)诤喜⒎种У臅r(shí)候的幾種方式，所以我就以本地分支的形式來(lái)說(shuō)說(shuō)有啥區(qū)別茉帅。
一個(gè)簡(jiǎn)單的模型
假設(shè)我們一開始的 master 分支上已經(jīng)有了幾個(gè)提交叨叙，就像這樣：
然后，我們切出一條開發(fā)的分支堪澎，進(jìn)行了一些 Feature 的開發(fā)擂错，然后我們的分支可能就是這種情況：
這種情況還好，也比較常遇到樱蛤，但是钮呀，現(xiàn)在問題來(lái)了，如果在這個(gè)時(shí)候 master 有了一些新提交（可能是其他分支合并進(jìn)來(lái)的）昨凡，那么這個(gè)時(shí)候情形就成了這樣：
這個(gè)情況很有趣爽醋，但是我們不討論，因?yàn)檫@和我們今天的主題無(wú)關(guān)便脊，以后可以另外開一個(gè)話題來(lái)說(shuō)蚂四，今天要說(shuō)的是第二個(gè)情況。
普通 Merge
說(shuō)到合并分支哪痰，可能我們最熟悉的操作是這樣的：
- 先切換到目標(biāo)分支（master）
- 執(zhí)行命令：
git merge devel - 刪除舊分支（可以在上面一同做）：
git branch -D devel - 提交到遠(yuǎn)程分支：
git push origin master
好像這樣沒啥問題的樣子遂赠，但是這樣操作之后，你知道結(jié)果是怎么樣嗎晌杰？假設(shè)合并之前的這樣的：
我們這么一番操作之后解愤，那么最后我們的分支的歷史將會(huì)是這樣的：
是的，看上去很不錯(cuò)乎莉，也是一條直直的 commit line送讲，我們?cè)?devel 分支中的 commit 也是一個(gè)不差得保留在了 master 中。但是惋啃，很多時(shí)候哼鬓，我們并不需要那么多的 commit，假設(shè)你給一個(gè)開源項(xiàng)目提交一個(gè) Bug Fixes边灭，然后一個(gè)簡(jiǎn)單的修改因?yàn)槟愕拇中拇笠?pr 了十幾個(gè) commit 過(guò)去异希，如果作者給你 merge 了，這就在這個(gè)項(xiàng)目的歷史長(zhǎng)河中增加了十幾個(gè) commit 啊绒瘦，以后的人看 commit history 估計(jì)都崩潰了吧称簿；同時(shí)扣癣，對(duì)于你自己管理的項(xiàng)目來(lái)說(shuō)，當(dāng)你 merge 之后發(fā)現(xiàn)有問題憨降，想回滾都蛋疼父虑！
squash merge
在使用 git 的過(guò)程中，可能你遇到過(guò)想要合并多個(gè) commit 為一個(gè)授药，然后很多人會(huì)告訴你用 git commit --amend士嚎，然后你發(fā)現(xiàn)里面有你的多個(gè) commit 歷史，你可以通過(guò) pick 選擇悔叽，squash 合并等等莱衩。同樣得，merge 的時(shí)候也可以這么干娇澎，你只需要這么簡(jiǎn)單的兩步：
- 切換到目標(biāo)分支：
git checkout master - 以 squash 的形式 merge：
git merge --squash devel
你會(huì)發(fā)現(xiàn)笨蚁，在 master 分支上居然有未提交的修改，然后你就需要在 master 上主動(dòng)提交了修改趟庄，注意赚窃，這里是你 commit 的，也就是改變了 commit 的 author岔激。結(jié)果是這樣的：
這里好了，比前面普通的 merge 來(lái)說(shuō)是掰，我們只有一個(gè) commit 了虑鼎，不管在分支中 commit 了多少，這里都只有一個(gè)键痛！
rebase merge
但是炫彩，作為處女座的程序員肯定是不能忍受目前的情況的，因?yàn)槲覀兗认牒喜?commits絮短，又想保留作者的信息江兢，那么有沒有什么好辦法呢？肯定是有的啦丁频，這個(gè)時(shí)候我們可以嘗試一下 rebase杉允，操作步驟是這樣的：
-
先切換到 devel 分支（不一樣咯）：
git checkout devel - 變基：
git rebase -i master - 切換回目標(biāo)分支：
git checkout master - 合并:
git merge devel
這里完成了第二步之后我想你應(yīng)該大概知道發(fā)生了什么事了，我們?cè)?devel 里面對(duì)照 master 進(jìn)行了變基席里，所謂的變基其實(shí)就是找到兩個(gè)分支共同的祖先叔磷，然后在當(dāng)前分支上合并從共同祖先到現(xiàn)在的所有 commit，所以我們?cè)诘诙降臅r(shí)候會(huì)選擇怎么處理這些 commit奖磁，然后我們就得到了一個(gè)從公共commit 到現(xiàn)在的單個(gè) commit改基，這個(gè)時(shí)候別人講我們這個(gè) commit 合并到 master 也只會(huì)在 master 上留下一個(gè) commit 記錄，就像這樣：
雖然這個(gè) commit history 線看上去很不錯(cuò)咖为，而且也比較符合實(shí)際情況秕狰，但是我們需要注意到的有點(diǎn)就是分支上的開發(fā)者需要自己執(zhí)行變基操作稠腊，從而導(dǎo)致他的原始 commit history 變化了（可以理解成被合并了）。
對(duì)比
相比一下前面三種方式鸣哀，我們可以總結(jié)出一些東西：
- rebase 可以盡可能保持 master 分支干凈整潔架忌，并且易于識(shí)別 author
- squash 也可以保持 master 分支干凈，但是 master 中 author 都是 maintainer诺舔，而不是原 owner
- merge 不能保持 master 分支干凈鳖昌，但是保持了所有的 commit history，大多數(shù)情況下都是不好的低飒，個(gè)別情況挺好
所以许昨，相比這么多，我是推薦使用 rebase 的褥赊，但是糕档，當(dāng)你在使用過(guò)程中，你會(huì)發(fā)現(xiàn)它的要求有點(diǎn)高拌喉，[/手動(dòng)哭臉]
