git怎麼合併分支程式碼

本教學操作環境：Windows7系統、Git2.30.0版、Dell G3電腦。

在專案中，我們總會建立很多分支進行不同功能或者需求的開發，等功能完成後再合併回主分支。那麼如何才能優雅的合併分支呢？如果此時你提起了興趣，那麼不妨繼續讀下去了。

建立多人開發場景

1. 建立倉庫

// 初始化倉庫
git init
// 建立a.txt
touch a.txt
// 建立b.txt
touch b.txt
// 加入暫存區
git add .
// 提交
git  commit -m 'initial'

2. 建立 feature 分支

git checkout -b feature

3. 兩個分支同時開發

feature 分支開發下一版本新功能，提交了兩次，分別修改 a.txt 檔案和 b.txt 檔案。

master 分支開發本次版本功能，同樣提交了兩次，且修改了 a.txt 檔案和 b.txt 檔案。

當前分支情況如下圖，各節點上面的字元是每次 commit 的雜湊值，當前 master 分支的 header 在 c5 節點上，feature 分支的 header 在 c3 節點上。

這個時候需要將 feature 分支合併回 master 分支，有兩種方案：

• 在 master 分支上直接 merge feature 分支；

• 是先在 feature 分支上 rebase(變基)，然後在 master 分支上 merge feature 分支。

下面分別說明一下這兩種方案：

合併命令1：git merge

git merge 用來做分支合併,將其他分支中的內容合併到當前分支中。

git merge 操作比較暴力，也是用的比較多的方式，下面演示的是 feature 分支合併至 master 分支，具體過程如下：

• 找到 feature 分支和 master 分支的最近共同祖先 commit 節點 c1；

• 把 feature 分支的最新一次 commit 節點 c3 和 master 分支上的最新一次 commit 節點 c5 合併，此時若有衝突，則一次性解決所有衝突，然後生成一個新的 commit 節點 c6；

• 同時根據兩個分支上的 commit 時間的先後順序，依次放到 master 分支上，使用git log可以看到時間順序。

上面流程的結果示意圖如下所示：

在專案中的操作命令如下。可以看到執行 git merge feature 命令後，存在衝突，進入 merging 工作區，然後一次性解決所有衝突後，提交一個新的 commit。

執行 gitk 命令列，可以在介面上看到當前分支如下圖所示。有一個新的 commit。

合併命令2：git rebase

這個命令從名字上就可以直觀看出它的功能：改變當前的分支的基點。對於 feature 分支，它是從 master 分支的 c1 節點建立的分支，所以它的基點就是 c1。如果在 feature 分支上執行 git rebase master ，其過程大致如下：

• 找到當前 master 分支最新的 commit 節點 c5，將 feature 分支的基點變成 c5 節點。；

• 若 feature 分支與 master 分支存在衝突，那麼將根據 feature 分支的提交時間，依次解決衝突，並修改 feature 分支此次 commit 的雜湊值。

• 最終在分支上看，呈現一條直線，但是存在歷史commit覆寫的問題。

上面過程的結果示意圖如下所示，其中 c2’和 c3’表示雜湊值改變了。

值得注意的是：

• 執行 rebase 操作的時候，需要保證 master 分支處於最新狀態，否則在 merege 合併的時候也可能存在衝突，就失去使用 rebase 的意義。

• 千萬不要對已經推到遠端的內容進行rebase，如果有人拉取遠端程式碼後修改並提交，分支會變得極其麻煩。

瞭解其基本過程後，我們就可以是用 rebase 命令開始進行合併分支的操作：

• 在專案中執行 git rebase master，如下所示。因為兩次提交都存在衝突，故在 rebase 工作區中需要依次解決這些衝突。

在 feature 分支上執行 gitk 命令，可以在介面中看到：

• feature 分支完成變基之後，切換回 master 分支執行 git merge feature，就可以完成合並操作。

在 master 分支上執行 gitk，其分支結構如下。可以看到分支呈現一條線，看上去非常清爽。

說明：git stash

有時候分支上的程式碼還沒開發完成，需要合併分支，此時只需要：

2、完成分支合併後，切回開發的分支，執行 git stash pop 將工作區內容彈出就可以繼續愉快的寫程式碼了。

總結

git merge 比較粗暴，也是大多數會選擇的方式，這種方式可以保證每個 commit 都按照時間順序排列，但是分支圖會非常凌亂，而會引入一次沒有意義的 commit。

git rebase 在歷史提交記錄就是一條線，非常優雅，但存在修改歷史commit的風險，並且git log檢視紀錄檔時commit時間線錯亂。同時，謹記已推播至遠端的內容就不要再變基，否則分支會變得很亂。

個人傾向於使用 rebase 方法，畢竟 commit 的認知成本擺在那裡，而且看著也舒服。不過如果開發人員很多，還是merge吧，畢竟一個個解決衝突會煩死個人，哈哈哈