你們平時合并代碼的時候用 merge 還是 rebase？

我問了一圈，發(fā)現(xiàn)有些人不僅沒用過 rebase，而且根本就沒聽說過。別慌，不要緊，沒有 rebase 也不影響開發(fā)，不影響合并，不影響發(fā)版！

我用 Git 很長時間也一直根本沒聽過 rebase 為何物，只知道合并分支就是 merge ，直到有一個新入職的同事跟我說：“為什么合并分支不用 rebase 呢？我之前公司都用 rebase，不怎么用merge。"

在那之后，我還頭一次聽說 rebase 這個命令。

只有在涉及到分支合并的時候才談到 merge 和 rebase，如果沒有合并的需求，那怎么整都無所謂，就像我自己的小產(chǎn)品，從頭到尾都只有個 main 分支，開發(fā)人只有我自己，也沒有沖突一說，有時候?qū)懞脦滋於疾粠ush一次的。

用到分支合并基本都是多人協(xié)作的團隊項目，通常會有一個主分支，然后有開發(fā)分支，有時候還會有一些臨時的 feature 分支。

merge 合并分支

同一個分支也可能出現(xiàn) merge 的情況，例如我這邊有一個老項目平時基本上沒其他人動，所以我在修改這個項目的時候基本上想不起來要先pull 一下，當(dāng)然了，這是一個非常不好的習(xí)慣，所以有時候一push代碼，發(fā)現(xiàn)有人竟然提交新代碼上去了，所以這種情況下就自動 merge 一下。

今天主要討論的是分支合并時的 merge。

下圖是 merge 合并分支時前后版本變化的情況。

圖片

merge 會創(chuàng)建一個新的合并提交，將兩個分支的歷史記錄保留在一起。

它的特點就是日志保存完整，不管你之前合并進來的那個版本有多少個提交歷史，都會被完整的合并到目標(biāo)分支。

以下是使用 merge 合并后的主分支 Graph 情況，看上去是不是有點亂。

圖片

假設(shè)有兩個分支，main 和 dev分支，在 dev 分支上開發(fā)，然后合并到 main 分支，合并的大致流程如下。

git checkout main
git pull origin main
git merge dev
# 解決沖突后
git commit -m "Merge dev into main"
git push origin main

Rebase 合并分支

rebase 會將分支上的更改重新應(yīng)用在目標(biāo)分支上，重寫提交歷史。

圖片

rebase 方式提交的版本歷史是線性的，不會創(chuàng)建新的合并提交，歷史記錄非常干凈。

同樣地，假設(shè)當(dāng)前有兩個分支，main 和 dev，用 rebase 方式合并分支的大致流程如下。

git checkout dev
git pull origin dev
git rebase main
# 解決沖突后
git rebase --continue
git push origin dev --force

合并壓縮

在rebase 的時候還可以使用 squash 參數(shù)來壓縮提交記錄，例如下圖，F(xiàn)eature 1 分支的 A、B、C 三個提交記錄，使用 rebase squash 后會在主分支變?yōu)橐粋€提交記錄 F。

圖片

使用方式如下，git rebase -i HEAD~3 命令準(zhǔn)備壓縮最近的3次提交，然后在編輯模式下將pick 改為 squash，最后推送到遠端倉庫。

適合那種：

git checkout dev
git rebase -i HEAD~3
# 進入編輯模式后，修改 `pick` 為 `squash`
# 保存并關(guān)閉編輯器后，編輯新的提交信息并保存
git push origin dev --force

選擇使用哪種方法

具體使用哪種方式合并要根據(jù)場景和習(xí)慣而定，沒有絕對的好壞。

使用 merge，如果你希望保留分支的歷史記錄，并且不介意有合并提交。適用于團隊合作時保留每個人的工作記錄。

使用 rebase，如果你希望保持提交歷史的簡潔和線性，適用于希望干凈歷史的項目。

有些公司規(guī)定只能用 rebase，它更適合那種只有單一版本的項目，只有一個主分支一直向前推進，且沒有多個分支并行的情況，例如一個產(chǎn)品既要維護2.x 版本又要維護3.x版本，那用 rebase就不合適了。

之前 Vue 項目就是用 rebase 方式合并分支的。

圖片