在Git中，merge和rebase是兩種不同的代碼合并策略，它們用于將一個分支的更改合并到另一個分支。它們的主要區別在于合并的方式和提交歷史的表現上

在介紹區別之前，我們先看下當我們從主干（Main）創建了一個新的分支（Feature）開始開發代碼時，然后另外有人把自己的代碼提交到主干（Main）之后，就會產生分叉的提交記錄。

圖片

這時候你想把你的代碼也提交到主干中，就有兩個選擇了：merge(合并)，rebase(變基)

Merge

git checkout feature
git merge main

git merge feature main

以上兩種都是把一個主干(main)的最新代碼合并(merge)到分支(featrue)的方式。

這個操作會在分支中創建一個新的“merge commit”，它將兩個分支的更改合并到一個新的提交中。

圖片

如上圖，就是我們把Main中的新提交Merge到我們的Feature分支中。

Rebase

作為merge的替代方法，您可以使用以下命令將功能分支重新設置為主分支：

git checkout feature
git rebase main

這會將整個feature移動到main分支的頂端，從而有效地將所有新提交合并到 main 中。但是，rebase不是使用merge commit，而是通過為原始分支中的每個提交創建全新的提交來重寫項目歷史記錄。

圖片

如上圖，就是我們將Main中新的提交，通過rebase的方式合并到我們的Feature分支中。（另外我出了一份Java面試寶典，里面有600多道面試常考題目）

區別

當我們想要把一個分支合并到主干的時候，merge操作會通過merge commit的方式在主干上新建一個節點，并一次性的把分支中的修改合并到主干中。它的優點是分支代碼合并后不破壞原分支的代碼提交記錄，缺點就是會產生額外的提交記錄并進行兩條分支的合并。

而rebase操作，不會在主干上新建節點，而是把分支上的所有歷史提交都合并到主干中，形成一個完成的線性提交記錄。他的優點是無須新增提交記錄到目標分支，rebase后可以將對象分支的提交歷史續上目標分支上，形成線性提交歷史記錄，進行review的時候更加直觀。

所以，merge rebase可以保留完整的歷史提交記錄。

當你想要保留原始分支的提交歷史，并且不介意在合并中產生額外的合并提交時，可以使用merge。在多人協作或公共分支上，merge是一個更安全和常見的選擇，因為它保留了每個開發者的提交歷史，易于跟蹤和回溯。（另外我出了一份Java面試寶典，里面有600多道面試常考題目）

當你想要保持提交歷史的整潔、線性，并且愿意改寫提交歷史時，可以使用rebase。在個人開發分支上，為了保持提交歷史的簡潔和易于閱讀，rebase用的更多。

一般來說，在公司內部做團隊開發，使用merge的情況會更多一些，我在工作中基本上90%的時間都是使用merge的。

Rebase黃金法則

一般來說，我們在工作中的開發模式都是基于分支開發，基于主干發布的模式。什么意思呢？

就是倉庫中有一份主干的代碼，線上運行的就是這套代碼，當我們有需求要開發的時候，不會直接在主干上開發，而是基于主干拉一個分支出來，在分支中進行開發，開發好之后，再把這個分支的代碼通過發布的方式合并到主干中。

在業內有一個rebase黃金法則：不要對已經提交到共享倉庫（如遠程倉庫）的提交執行 rebase。

為什么要遵守這個黃金法則呢？

rebase會將所有的Main分支上的提交移動到Feature分支的頂端，問題是這個操作只發生在你自己的本地倉庫中，所有的其他開發者是完全不感知的，因為他們是使用舊的Main分支創建的分支。（另外我出了一份Java面試寶典，里面有600多道面試常考題目）

圖片

這時候如果我們的Feature變更被推送到遠程倉庫后，其他人的Feature想要在提交的時候，就會產生大量的沖突。

所以，在多人協作中，應該遵循以下指導原則：

1. 在個人開發分支上進行 rebase：如果你在個人開發分支上進行 rebase，這不會對其他開發者產生影響，因為這個分支只屬于你個人。
2. 在共享倉庫的主分支上使用 merge：在共享倉庫的主分支（如 master 或 main）上，推薦使用 merge 來將開發的功能或修復合并回主分支。這樣可以保留每個開發者的提交歷史，易于跟蹤和回溯。
3. 協作時協商：如果有特殊情況需要在共享倉庫的分支上進行 rebase，應該與其他開發者進行充分協商，并確保大家都知道并同意這個變更。