Git merge和rebase分支合併命令的區別

歡迎關注富途web開發團隊，缺人從衆

上週花了時間把futu web博客分類,文章，入口搞了一下，主要爲了解決SEO問題。接下來SEO好很差就看效果了。

futu web 博客地址

今天分享的文章呢。小編以爲你們看圖就行。正文講的是Git分支合併命令merge和rebase的區別。

那麼在正文開始前，小編仍是先送一些彩蛋吧。對於你們去理解Git命令挺有用的。

文件狀態轉換：

文件存儲：

上面這兩張圖會對你們理解Git命令有很大的幫助。

正文

在使用 git 進行版本管理的項目中，當完成一個特性的開發並將其合併到 master 分支時，咱們有兩種方式：git merge 和 git rebase。一般，咱們對 git merge 使用的較多，而對於 git rebase 使用的較少，其實 git rebase 也是極其強大的一種方法。下面咱們就來說一講 git merge 和 git rebase 的差異和在實際中的使用。

準備工做

爲了更好地觀察執行 git merge 和 git rebase 以後發生的現象，咱們首先來作一些準備工做，即建立一個項目倉庫，而後在其中構建兩條分支，再增長几回提交。

具體以下：

1. 建立一個目錄 gitTest
2. 在目錄 myTest 中新建一個文件 readme.md，隨便添加一個標題，和第一個列表項 add master1 並提交到本地倉庫
3. 在當前分支的基礎上新建一條分支，名爲 feature，將列表項 add master1 修改成 add feature1 並提交到本地倉庫
4. 隨後切換到分枝 master 上添加一個新的列表項 add master2 並提交到本地倉庫
5. 隨後切換到分枝 feature 上添加一個新的列表項 add feature2 並提交到本地倉庫
6. 重複上面的步驟 4 和 5，直至在 master 和 feature 上各添加了 4 條列表項

此時你的倉庫分支提交的記錄看起來應該是這樣的：

初始 master 分支內容應該是這樣的：

初始 feature 分支內容應該是這樣的：

git merge

從目錄 gitTest 拷貝出一份來，命名爲 gitMerge 來進行咱們的合併操做。

git merge 的使用方法很簡單，假如你想將分支 feature 合併到分支 master，那麼只需執行以下兩步便可：

• 將分支切換到 master 上去：git checkout master
• 將分支 feature 合併到當前分支（即 master 分支）上：git merge feature

如上圖所示，git merge 有以下特色：

• 只處理一次衝突
• 引入了一次合併的歷史記錄，合併後的全部 commit 會按照提交時間從舊到新排列
• 全部的過程信息更多，可能會提升以後查找問題的難度

爲何講 git merge 提交的信息過多可能會影響查找問題的難度呢？由於在一個大型項目中，單純依靠 git merge 方法進行合併，會保存全部的提交過程的信息：引出分支，合併分支，在分支上再引出新的分支等等，相似這樣的操做一多，提交歷史信息就會顯得雜亂，這時若是有問題須要查找就會比較困難了。

使用 git merge 以後的分支提交記錄以下：

git rebase

git rebase 的合併操做

與 git merge 一致，git rebase 的目的也是將一個分支的更改併入到另一個分支中去。

如上圖所示，他的主要特色以下：

• 改變當前分支從 master 上拉出分支的位置
• 沒有多餘的合併歷史的記錄，且合併後的 commit 順序不必定按照 commit 的提交時間排列
• 可能會屢次解決同一個地方的衝突（有 squash 來解決）
• 更清爽一些，master 分支上每一個 commit 點都是相對獨立完整的功能單元

那麼咱們如今來具體操做一下，看看 git rebase 是如何作的。

首先，和 git merge 不一樣的是，你須要在 feature 分支上進行 git rebase master 的操做，意味着讓當前分支 feature 相對於 分支 master 進行變基：

能夠看出，咱們遇到了衝突，進行對比的雙方分別是 master 分支的最新內容和 feature 分支的第一次提交的內容，上圖下方紅框內容告訴咱們，在咱們解決了衝突以後，須要執行 git rebase --continue 來繼續變基的操做。

在解決衝突以後執行 git rebase --continue 時遇到了提示，看來咱們首先須要把咱們的修改存到暫存區，隨後再執行 git rebase --continue。執行以後又遇到了衝突，此次是與 feature 分支的第二次提交進行對比出現的衝突，意味着咱們須要屢次解決同一個地方的衝突。

繼續重複先解決衝突，再 git rebase --continue 的步驟，直到遇到：

意味着完成了 feature 最後一次提交的變基操做，至此整個變基就完成了。

再來看看執行 git rebase 以後的 feature 分支：

徹底符合上面所說的執行 git rebase 的特色，咱們引出 feature 分支的位置變了，沒有多餘的提交歷史，且提交的時序也改變了，另外回憶一下，在咱們執行變基的過程當中也屢次解決了同一個地方的衝突。

這個時候咱們再切換到 master 分支上，將 feature 分支合併進來。

看得出來，feature 分支上的全部提交信息都會被合併到 master 分支上了，這些信息對咱們來講不是必要的，咱們在 masetr 分支上每每只須要知道合併進來了什麼新的功能便可，這些多餘的信息能夠經過 git rebase 的交互模式進行整合，下一節會講到這個。

git rebase 的交互模式

打開變基的交互模式只須要傳入一個參數 -i 便可，同時還須要指定對哪些提交進行處理，如：

git rebase -i HEAD~4
複製代碼

上述命令指定了對當前分支的最近四次提交進行操做。下面咱們使用上面這行命令將 feature 分支的提交合並。

中間紅框內有一些命令，能夠用來處理某次提交的，此處咱們使用 squash 來將全部的 commit 合併成一次提交，編輯並保存以後會出現編輯提交的信息的提示，編輯提交便可。

此時再看 feature 分支上的提交記錄，會看到只有一次提交了。

此時不管是直接將分支合併到 master 仍是先變基再合併，master 分支上的提交記錄都會十分清爽了。

總結

當須要保留詳細的合併信息的時候建議使用git merge，特別是須要將分支合併進入master分支時；當發現本身修改某個功能時，頻繁進行了git commit提交時，發現其實過多的提交信息沒有必要時，能夠嘗試git rebase。