簡介
以前用git基本上針對git flow以及基本的git操作命令基本上滿足日常開發需求,其實也沒必要過於深究,常用命令80-90%基本上滿足我們正常使用了。 但是其實很多人,包括我自己,git的官方文檔基本沒掃完一遍,所以抽時間其實幾個小時也就能看完的事情。 其中在合併branch的時候，網上有很多關於使用git rebase 還是 git merge有無數篇文章進行所謂的爭論。
甚至有標題黨文章也是聳人聽聞,語不驚人死不休。“git合併代碼永遠用rebase”…文章我也是懶得吐槽了,後面搬出官方文檔來大家自行判斷。
merge分析
先舉例git merge畫圖分析.
如圖所示,develop合併到master會產生一個commit, 我們稱之爲"merge commit". 並且圖上能夠展現完整開發過程,“commit"分叉.很多人比較反感的是多出來的
這個沒有意義的commit以及分叉沒必要存在,所以接下來提到rebase(變基). 我們現在重點看一下此時"c4"的父親是"c3”.
rebase分析
和上面情況不巧的是, 在Develop基於master c3切出來分支以後, master有人往上面提交到了代碼.這時候變成這樣
如果develop要把master merge進來則展現爲這樣:
如果改爲develop rebase master呢? 如圖:
首先的改變是,c4 c5 c6的hash值發生了變化, c4的父親"變基"了, 父節點之前是"c3"現在是"c3-1". 沒有多出來一個merge commit(c6-1)。此時就不出現了"分叉",所有的提交都在一條線上. 其實最通俗理解,
之前develop從c3切出來的,現在從c3-1切出來。(網上一堆花裏胡哨的解釋…,沒想象中那麼複雜)。
總結
rebase 和 merge優缺點和用法各個團隊不一樣,因人而異,業界沒有定論。如果沒有充分理解rebase, 還是老老實實用merge吧。用merge肯定在功能上不會出問題的! 引用官方文檔一句話:
總的原則是，只對尚未推送或分享給別人的本地修改執行變基操作清理歷史， 從不對已推送至別處的提交執行變基操作，這樣，你才能享受到兩種方式帶來的便利。 – git官方文檔, "變基介紹"最後一段話
git文檔: git官方文檔