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

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

1、執行 git stash 將工作區內容存儲起來，然后選擇上述兩種合并分支的方式進行分支合并。

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

總結

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

git rebase 在歷史提交記錄就是一條線，非常優雅，但存在修改歷史commit的風險，并且git log查看日志時commit時間線錯亂。同時，謹記已推送至遠程的內容就不要再變基，否則分支會變得很亂。

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