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

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

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

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

只有在涉及到分支合并的時候才談到 merge 和 rebase，如果沒有合并的需求，那怎么整都無所謂，就像我自己的小產品，從頭到尾都只有個 main 分支，開發人只有我自己，也沒有沖突一說，有時候寫好幾天都不帶push一次的。

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

merge 合并分支

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

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

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

圖片

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

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

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

圖片

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

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

Rebase 合并分支

rebase 會將分支上的更改重新應用在目標分支上，重寫提交歷史。

圖片

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

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

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

合并壓縮

在rebase 的時候還可以使用 squash 參數來壓縮提交記錄，例如下圖，Feature 1 分支的 A、B、C 三個提交記錄，使用 rebase squash 后會在主分支變為一個提交記錄 F。

圖片

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

適合那種：

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

選擇使用哪種方法

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

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

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

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

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

圖片