作者 | Video++極鏈科技后端Team

整理 | 包包

Git分支和工作流

分支本質是一個指向提交對象的可變指針。Git 保存的不是文件的變化或者差異，而是一系列不同時刻的文件快照。在進行提交操作時，會保存一個提交對象（commit object），在多次提交后，commit對象形成連續的快照鏈，分支指針自動指向最新一次提交。Git 的默認分支名字是 master。如下圖：

branch命令可以輕松創建一個新分支，就像這樣：

$gitbranchnew_branch

這一命令實際是為當前提交對象添加了一個新的指針。這種分支形式比大多數版本控制系統更為輕量，無論是創建還是切換都幾乎可以在瞬間完成。Git 鼓勵在工作流程中頻繁地使用分支與合并，這完全不會增加倉庫負擔，并且可以基于這一特性創建更自由和更可靠的合作開發流程。

許多使用Git 的開發者都喜歡使用這種方式來工作：僅在master分支上保留完全穩定的代碼，這些代碼通常處于已發布或等待發布的狀態。此外使用一些短期分支，比如用develop分支開發新特性，使用test分支修復bug，測試穩定性，直到代碼質量達到發布要求，再合并到master分支，完成一個版本的開發。

不同的開發者團隊可以自由創造適合自己組織形式的分支策略。社區中也存在許多深受歡迎的流程范例，比如經典的gitflow工作流、PR工作流、集中式工作流等等，它們通常適用于不同的合作方式，并不是某種強制規范。有興趣的讀者可以繼續深入探索，此處不再過多介紹。

merge

假設我們基于master分支創建了feature分支用來開發新功能，經過一段時間開發之后，需要把feature的分支代碼合并回到master，通常執行的操作是先檢出master分支，然后執行git merge feature。

一般來說，在單人開發的情況下，merge通常會產生快進（fast-forward）方式的合并。如果在子分支（feature）被創建之后，父分支（master）未產生新的修改和提交，此時把feature合并回master，Git會在提交鏈上把master指針簡單的前移，使兩個分支進度同步，并形成無分支記錄的提交鏈。執行時在控制臺輸出Fast-forward標識。這種merge方式下不會產生沖突，git log命令會看到如下記錄：

但在團隊合作開發時，通常會多人修改同一遠程分支。其中使用的pull和push命令實際包含了merge操作。這時git使用另外一種方式來進行分支合并。目前只有一方修改的情況下，也可以使用 —no-ff 參數來模擬這種方式。

這里使用了git最基礎的三路遞歸合并（recursive three-way merge），輸出Merge made by the 'recursive' strategy.標明合并方式。這種合并會形成帶分支歷史的提交鏈：

從圖中可以看出，這種merge方式實際在發起合并的分支生成了一個帶有Merge 標識的新提交。如果合并時存在沖突，解決沖突后的最終內容也會包含在這個新的提交中。

看到這里，可能有人會有疑問，工作空間中自始至終只出現了兩個分支，為什么會是三路合并。從git 源碼中可以找到merge執行的入口，它有這樣的方法簽名：

可以看出，除了含義明顯的ours和theirs，還有一個待合并的文件叫做ancestor。根據文檔和源碼注釋，這個版本實際是兩個待合并分支的公共部分。在我們的例子中就是創建新分支的那個提交對象。

大體的流程是這樣的，git merge會找出兩個分支指向的最新commit，找到他們最近的公共祖先，然后對每個待合并的文件調用ll_merge，這個方法會比較各分支和祖先節點的差異。然后把這些差異整合成一個Merge提交，應用到當前分支上，生成最終的合并結果。

如果兩個分支之間有多個公共祖先，git會選出最合適的祖先節點依照同樣規則進行遞歸合并。可以使用git merge-base —all命令列出所有的備選祖先節點。

Git還可以一次性合并多個分支，只需要簡單的把分支名當做merge的參數依次列出：

這種策略被稱為octopus，其中核心邏輯與three-way merge相同，不再詳述，可以通過閱讀github上的源碼和文檔繼續深入了解。

three-way merge機制有一定的隱患。如果其中一個待合并分支，比如ours，和ancestor版本的某一部分代碼相同，但另一個待合并分支theirs中有不同的修改，合并的結果就會采用theirs分支不同的那部分，并不會依照修改的時間順序來決定最終內容。在實際項目中可能會反復修改同一段代碼來響應需求變更，就有幾率發生這種合并結果與預計不符的情況，需要特別留意。

rebase

Git rebase，通常被稱作變基或衍合, 可以理解為另外一種合并的方式，與merge 會保留分支結構和原始提交記錄不同，rebase 是在公共祖先的基礎上，把新的提交鏈截取下來，在目標分支上進行重放，逐個應用選中的提交來完成合并。

為了形象理解rebase的過程，可以看下面例子：

使用 merge 合并后：

下面使用rebase方式達到同樣效果：

除了原本的多分支記錄變為了直線提交鏈，還可以注意到，其中原本在feature分支上的提交，rebase后的SHA編碼發生了變化。rebase消除了真實歷史，重新生成了新的提交。

和merge類似，rebase在遇到沖突時也會暫停，需要手動修復后才可以繼續。但是rebase的處理要相對繁瑣一些，merge 如果發生 conflict，只需要在最終的Merge 提交上解決一次。而 rebase 的 conflict 可能發生在每一次提交的重新應用上，所以需要依次解決。

為了避免這種情況，可以在與另一分支合并之前，提前把所有需要提交合并為一個提交。同樣需要用到rebase命令。

執行這樣一個命令來合并當前最新的3個提交：

這條命令將打開一個編輯頁面，我們可以修改前面的命令來合并或丟棄單個提交。

pick 表示將會應用這個提交。

squash 表示把當前提交合并到前一個提交，它的前面必須至少有一個被pick的提交存在。

把某條提交注釋或刪除表示丟棄這條記錄。

這里選擇合并第一個和第三個，丟棄第二個提交。

保存退出后進入新的編輯頁面，提示編輯提交信息，這里選擇不做改動。

再次保存退出后成功合并完成，形成這樣的log：

git還有一個可愛的命令cherry-pick，通常譯作揀選。它的參數是提交對象的SHA編碼，可以視為針對單個提交的rebase操作。示例如下：

總結

merge 和 rebase 的差異在于最終的歷史記錄，可以發現 merge 保持了所有分支的原始修改記錄，可能會包含很多不必要的信息；而 rebase相當于對歷史記錄做出修剪，可以維持一條簡單清晰的提交路線。

通常我們會在基于一個過時的版本進行了本地修改的情況下使用rebase，在實際開發中經常會出現這種情況，當你在本地分支上工作了幾天，突然想起應該push到遠程倉庫時，遠程分支已經被別人更新過了。此時你會得到一個reject信息。

有些人會選擇用pull命令合并遠程和本地的同名分支，但pull實際執行了fetch和merge兩個操作，會生成復雜的分支歷史和一個多余的merge提交。你也可以選擇用fetch和rebase代替pull，始終生成一個美觀的提交鏈。

rebase的另一個重要應用是合并過多的本地提交。因為防止修改內容丟失，經常commit到本地倉庫是一個很好的開發習慣。但是當需要提交到公共分支時，大量無明確意義的提交信息對歷史記錄造成不必要的干擾。此時你可以用rebase命令把本地記錄規范化，再進行推送。

使用rebase的時候需要遵循一條重要原則：不要對在你的本地倉庫外有副本的提交記錄進行變基。rebase的實質是丟棄一些現有的提交，然后相應地新建一些內容一樣但實際上不同的提交。 如果其他人已經在這些提交上做出過大量修改、沖突合并等工作，那么你的rebase將成為他們的惡夢。

對于使用rebase還是merge來合并代碼，實際并沒有什么固定的模式，取決于開發者如何看待倉庫的歷史記錄。一些人認為歷史記錄應該反映全部真實變更細節，而另一些人認為歷史記錄應該是精心維護的變更目錄。具體如何使用取決于項目合作者的一致共識。無論是merge還是rebase，都應該了解其中原理，避免危險操作，才能享受到Git諸多特性帶來的便利。