文章學(xué)習(xí)自：麥兜搞IT，如有侵權(quán)，告知?jiǎng)h除

前言

合并操作在Git中屬于最為核心的一個(gè)操作，包括三種合并方式：一種為fast forward ，需要滿足有非常強(qiáng)的前提條件才能執(zhí)行；一種為3 way merge方式，這種是我們工作中常見的；最后一種為變基rebase。另外，本篇文章也會(huì)深入講解沖突如何產(chǎn)生，以及如何解決

1 Fast Forword 合并

1.1 核心原理

需求：將bugfix分支合并到master(切換到master然后執(zhí)行g(shù)it merge bugfix)

Fast Forword 合并： 將master分支指針向前快速移動(dòng)到bugfix分支所指向的commit對(duì)象，在此合并方式下，不會(huì)產(chǎn)生沖突

前提條件: bugfix和master分支具有完全相同的提交歷史（即bugfix提交歷史中有master最新的提交）

1.2 舉個(gè)栗子

合并前描述：
master分支指向C2代表的commit對(duì)象，而bugfix超前于master分支1次提交（這里可以超前多次），指向了C3所代表的commit對(duì)象。符合fast forward merge

執(zhí)行命令
git checkout master
git merge bugfix

合并后描述：
master指針快速移動(dòng)到bugfix指針?biāo)赶虻腸ommit對(duì)象C3

合并過(guò)程中發(fā)生的事情：

1、.git/ 目錄下會(huì)新增一個(gè)文件 ORIG_HEAD文件，該文件為指向master上一次commit的指針，用于回滾，即若發(fā)現(xiàn)合并錯(cuò)了，那執(zhí)行git reset ORIG_HEAD即可完成回滾操作
2、不會(huì)產(chǎn)生新的commit、bolb、tree對(duì)象

fast-forward為什么不會(huì)產(chǎn)生沖突
沖突產(chǎn)生的原因：多個(gè)分支對(duì)同一個(gè)文件的同一部分進(jìn)行了修改，并且這些修改是相互矛盾的，無(wú)法自動(dòng)合并。而fast-forward只有一個(gè)分支對(duì)文件做了修改(bugfix)

1.3 經(jīng)驗(yàn)之談

在實(shí)際工作場(chǎng)景中，此合并方式基本不會(huì)遇到，除非代碼倉(cāng)庫(kù)只有自己在維護(hù)。而我們通常遇到的情況都是下面要講的3 way merge 或者rebase的情況，也即bugfix和master分支不具有完全相同的提交歷史，產(chǎn)生了分叉

2 three way merge

2.1 核心原理

需求：將bugfix分支合并到master(切換到master然后執(zhí)行g(shù)it merge bugfix)

three way merge： Git 需要比較三個(gè)版本的代碼，即兩個(gè)分支的最新提交對(duì)象和它們的共同祖先提交對(duì)象。Git 使用一種叫做三方合并（three-way merge）的技術(shù)來(lái)自動(dòng)合并這三個(gè)版本的代碼。

合并過(guò)程：
1、找到兩個(gè)分支的共同祖先提交對(duì)象，確定兩個(gè)分支之間的修改范圍，確定沖突的位置

2、比較兩個(gè)分支的最新提交對(duì)象和共同祖先分支之間的差異，確定每個(gè)分支中的修改內(nèi)容。

3、合并兩個(gè)分支的修改。根據(jù)比較結(jié)果，Git 將兩個(gè)分支的修改合并起來(lái)。如果兩個(gè)分支對(duì)同一個(gè)文件的不同部分進(jìn)行了修改，Git 將嘗試自動(dòng)合并這些修改。如果這些修改發(fā)生在同一個(gè)文件的同一個(gè)區(qū)域，Git 就會(huì)提示用戶手動(dòng)解決沖突。

2.2 舉個(gè)栗子（不帶沖突）

合并前描述：
A用戶對(duì)master執(zhí)行了合并，使得master指針從C2變?yōu)榱薈4；B用戶對(duì)bugfix執(zhí)行了commit操作，使得bugfix從C2變?yōu)榱薈3，此時(shí)，產(chǎn)生了分叉。我們的目標(biāo)是要將bugfix合并到master上

執(zhí)行命令
git checkout master
git merge bugfix

此時(shí)會(huì)跳轉(zhuǎn)到一個(gè)vim界面，編輯本次merge包括了哪些信息，這個(gè)自己填寫就可以

合并后描述：
產(chǎn)生一個(gè)新的commit對(duì)象C5，它的parent有兩個(gè)，C3與C4，同時(shí)master指針指向C5，合并完成

2.3 帶沖突的three way merge

合并前描述：
master和bugfix對(duì)同一文件的同一區(qū)域進(jìn)行了修改，現(xiàn)在要將bugfix分支合并到master

執(zhí)行命令
git checkout master
git merge bugfix

此時(shí)會(huì)顯示如下沖突信息

此時(shí)也可以使用git status來(lái)查看有哪些文件產(chǎn)生了沖突

然后可以使用git diff 沖突文件路徑來(lái)查看差異，最后可以手動(dòng)解決（git add git commit即可）。
當(dāng)然目前有很多IDE內(nèi)置了很方便的沖突解決功能

合并后描述：
產(chǎn)生C4，parent是C2,C3，C4中的test.txt是你解決完沖突后的內(nèi)容

3 變基rebase

git rebase命令適合有強(qiáng)迫癥的人使用。

3.1 引入rebase

3 way merge方式在git歷史線上會(huì)產(chǎn)生分叉，類似下面，紅色代表dev，藍(lán)色代表master

有些人就覺得，不行，必須得是直線才好看，也就是想在3 way merge的方式下還想達(dá)到fast forward的效果（fast forward在git 歷史上是直線），所以產(chǎn)生了git rebase

3.2 核心原理

核心原理：將一個(gè)分支的修改“移動(dòng)”到另一個(gè)分支上，使得兩個(gè)分支的修改可以按照時(shí)間順序排列，從而形成一個(gè)線性的提交歷史

基本步驟：

在 rebase完之后，可以checkou 到master執(zhí)行merge操作，完成合并。
注意：rebase的過(guò)程中也是有可能產(chǎn)生沖突的，解決完沖突之后 使用git rebase --continue繼續(xù)rebase

4 沖突問題

4.1 產(chǎn)生沖突的原因

核心原因：多個(gè)分支對(duì)同一個(gè)文件的同一部分進(jìn)行了修改，并且這些修改是相互矛盾的，無(wú)法自動(dòng)合并。

具體來(lái)說(shuō)，當(dāng)多個(gè)分支對(duì)同一個(gè)文件的同一部分進(jìn)行了修改時(shí)，Git 會(huì)嘗試自動(dòng)合并這些修改，并將合并結(jié)果應(yīng)用于最終合并結(jié)果中。但是，如果這些修改是相互矛盾的，例如一個(gè)分支將文件的某個(gè)部分刪除了，而另一個(gè)分支對(duì)該部分進(jìn)行了修改，則 Git 就無(wú)法自動(dòng)合并這些修改，會(huì)提示合并沖突。

在這種情況下，開發(fā)者需要手動(dòng)解決沖突，從而完成合并操作。手動(dòng)解決沖突的過(guò)程中，開發(fā)者需要根據(jù)需要保留、修改或刪除對(duì)應(yīng)的代碼行或代碼段。解決沖突后，開發(fā)者需要將修改提交到 Git 倉(cāng)庫(kù)中。

4.2 常見沖突場(chǎng)景

1、git merge時(shí)（3 way merge）
2、git pull時(shí)

以下場(chǎng)景不會(huì)產(chǎn)生沖突：

場(chǎng)景一：
假設(shè)有兩個(gè)分支，分別是 A 和 B，它們都對(duì)同一個(gè)文件 file.txt 進(jìn)行了修改：

分支 A 對(duì) file.txt 進(jìn)行了刪除操作； 分支 B 對(duì) file.txt 進(jìn)行了修改操作。 這時(shí)候，如果要合并這兩個(gè)分支，Git就會(huì)自動(dòng)先將分支 B 對(duì) file.txt 的修改操作合并到最終合并結(jié)果中，再將A 對(duì) file.txt 的刪除操作合并到最終合并結(jié)果中，而不會(huì)提示合并沖突
最終合并的結(jié)果是file文件被刪除了

4.3 解決沖突

文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-763105.html

到了這里，關(guān)于【Git】分支合并&沖突產(chǎn)生與解決的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！