git 要解決的沖突，是由分支合并帶來的。

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

合并場景

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

從 develop 分支合并到 master 分支的場景有以下兩種情況：

• develop 有修改但 master 沒有。

• develop 有修改且 master 有修改。

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

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

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

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

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

合并的類型

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

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

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

還是以上述 master 分支和 develop 分支為例來說明。

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

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

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

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

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

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

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

合并策略

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

常見的合并策略包括：

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

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

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

解決合并沖突的辦法

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

• 查看沖突文件

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

git status 

• 打開沖突文件

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

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

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

• 手動解決沖突

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

保留的更改 

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

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

git add conflict_file 

• 提交合并結(jié)果

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

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

避免合并沖突

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

所以我們在工作時會盡量避免沖突的發(fā)生。

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

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

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

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

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

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

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

總結(jié)

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

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

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