git 要解決的沖突，是由分支合并帶來(lái)的。

合并（Merge）是將分支 A 的更改合并到分支 B 的過(guò)程。

合并場(chǎng)景

假如我們有 master 分支，然后有基于 master 分支創(chuàng)建出來(lái)的 develop 分支。

從 develop 分支合并到 master 分支的場(chǎng)景有以下兩種情況：

• develop 有修改但 master 沒(méi)有。

• develop 有修改且 master 有修改。

合并沖突發(fā)生在上述的第二個(gè)場(chǎng)景里，當(dāng)同一個(gè)文件在兩個(gè)分支上都被修改了。

• 同一文件的同一部分被不同的分支修改：當(dāng)兩個(gè)或多個(gè)分支對(duì)同一文件的同一部分進(jìn)行了不同的修改時(shí)，Git 無(wú)法自動(dòng)合并這些更改，從而產(chǎn)生沖突。

• 如果一個(gè)分支刪除了某個(gè)文件，而另一個(gè)分支修改了同一個(gè)文件，Git 也會(huì)產(chǎn)生沖突。

• 當(dāng)一個(gè)分支重命名了某個(gè)文件，而另一個(gè)分支對(duì)該文件進(jìn)行了修改，Git 也會(huì)產(chǎn)生沖突。

出現(xiàn)沖突的時(shí)候，就需要手動(dòng)解決沖突并提交合并結(jié)果。

合并的類(lèi)型

合并的結(jié)果有兩種，一是直接合并，不產(chǎn)生新的提交。二是有沖突并解決了沖突，它會(huì)產(chǎn)生新的提交，這里的提交內(nèi)容就是合并沖突修改。

這里有三種類(lèi)型的合并：前進(jìn)合并（fast-ford）、三方合并（three-way merge）和變基合并（Rebase）。

快速前進(jìn)合并（fast-forward）是最簡(jiǎn)單的合并方式。

還是以上述 master 分支和 develop 分支為例來(lái)說(shuō)明。

當(dāng) master 分支沒(méi)有新的提交時(shí)，Git 只需將 master 分支的指針移動(dòng)到 develop 分支的最新提交即可。這種合并不會(huì)產(chǎn)生新的合并提交。

三方合并（three-way merge）是指當(dāng) master 分支和 develop 分支都有新的提交時(shí)，Git 會(huì)進(jìn)行三方合并。

這種合并會(huì)創(chuàng)建一個(gè)新的合并提交，包含兩個(gè)分支的更改。

# 切換到目標(biāo)master分支 git checkout master  # 合并源develop分支 git merge develop 

變基合并（Rebase）是將 develop 分支的提交應(yīng)用到 master 分支的基礎(chǔ)上，從而避免創(chuàng)建合并提交。

這種方式可以保持提交歷史的線(xiàn)性，但可能會(huì)導(dǎo)致沖突需要手動(dòng)解決。

# 切換到源develop分支 git checkout develop  # 變基到目標(biāo)master分支 git rebase master 

合并策略

在進(jìn)行合并時(shí)，還能使用不同的合并策略來(lái)控制合并的行為。

常見(jiàn)的合并策略包括：

• 默認(rèn)策略（recursive）：這是 Git 的默認(rèn)合并策略，適用于絕大多數(shù)情況。

• 合并策略選項(xiàng)（ours/theirs）：在沖突時(shí)，選擇保留當(dāng)前分支或合并分支的更改。

# 使用 ours 策略進(jìn)行合并 git merge -s ours develop 

解決合并沖突的辦法

解決合并沖突需要手動(dòng)干預(yù)，基本上可以按以下步驟進(jìn)行：

• 查看沖突文件

當(dāng)合并沖突發(fā)生時(shí)，Git 會(huì)提示哪些文件存在沖突。可以使用 git status 命令查看沖突文件。

git status 

• 打開(kāi)沖突文件

打開(kāi)沖突文件，可以看到?jīng)_突部分被標(biāo)記為 <<<<<<< HEAD、======= 和 >>>>>>> branch_name。

這些標(biāo)記分別表示當(dāng)前分支的更改、分隔符和合并分支的更改。

<<<<<<< HEAD 當(dāng)前分支的更改 ======= 合并分支的更改 >>>>>>> branch_name 

• 手動(dòng)解決沖突

根據(jù)實(shí)際情況，手動(dòng)編輯沖突文件，保留需要的更改并刪除沖突標(biāo)記。

保留的更改 

• 標(biāo)記沖突已解決

解決沖突后，使用 git add 命令將修改后的文件添加到暫存區(qū)。

git add conflict_file 

• 提交合并結(jié)果

最后，使用 git commit 命令提交合并結(jié)果。

git commit -m "解決合并沖突" 

避免合并沖突

在團(tuán)隊(duì)協(xié)作里，頻繁出現(xiàn)合并沖突多少會(huì)影響開(kāi)發(fā)效率，以及團(tuán)隊(duì)士氣。

所以我們?cè)诠ぷ鲿r(shí)會(huì)盡量避免沖突的發(fā)生。

它的策略核心是盡可能減少同時(shí)對(duì)同一個(gè)文件的修改，以及盡可能減少單次提交的代碼量。

• 頻繁拉取和推送代碼：團(tuán)隊(duì)成員應(yīng)養(yǎng)成頻繁拉取（git pull）和推送（git push）代碼的習(xí)慣，以確保本地倉(cāng)庫(kù)與遠(yuǎn)程倉(cāng)庫(kù)保持同步。

• 小步提交：盡量將更改分成小的、獨(dú)立的提交，而不是一次性提交大量更改。這樣可以更容易地解決沖突，并且每次合并的范圍更小，沖突的可能性也會(huì)降低。

• 使用分支策略：采用合理的分支策略，如 Git Flow 或 GitHub Flow。每個(gè)功能或修復(fù)都在獨(dú)立的分支上進(jìn)行開(kāi)發(fā)，完成后再合并到主分支。這可以減少直接在主分支上進(jìn)行開(kāi)發(fā)導(dǎo)致的沖突。

• 代碼評(píng)審：在合并代碼之前進(jìn)行代碼評(píng)審（Code Review），可以提前發(fā)現(xiàn)潛在的沖突和問(wèn)題，并在合并之前解決。

• 溝通和協(xié)調(diào)：團(tuán)隊(duì)成員之間應(yīng)保持良好的溝通，特別是在處理同一文件或模塊時(shí)。提前告知其他成員自己的更改計(jì)劃，可以避免同時(shí)修改同一部分代碼。

• 自動(dòng)化測(cè)試：在合并之前運(yùn)行自動(dòng)化測(cè)試，確保代碼的正確性和兼容性。這樣可以在合并之前發(fā)現(xiàn)并解決潛在的問(wèn)題。

總結(jié)

• ?? 有三種類(lèi)型的合并：前進(jìn)合并（fast-ford）、三方合并（three-way merge）和變基合并（Rebase）。

• ?? 在進(jìn)行合并時(shí)，還能使用不同的合并策略來(lái)控制合并的行為。

• ?? 在團(tuán)隊(duì)協(xié)作里，盡量避免沖突的發(fā)生。