1、定義：兩個分支修改了同一文件的同一行代碼，無法自動決定如何合并代碼，需要人工干預的情況。（假設A提交了文件a,此時B在未拉取代碼的情況下，直接提交是會報錯的，此時需要拉取之后再提交才會成功）

2、原始沖突解決演示：

背景：假設現在有主分支：develop，開發分支A,開發分支B，二者都是基于develop分支創建的，此時A 先向develop分支合并了一個文件index.js。然后B緊接著向develop分支上合并了自己修改的index.js文件，以為A和B都在index.js中寫了不同的代碼，此時git不知道保留哪段代碼。此時就會報代碼沖突。怎么解決呢？這里介紹的是在gitLab網頁上做合并分支操作的情況。

首先如果出現代碼沖突時，gitLab會給出提示提醒你合并沖突了，此時針對的代碼沖突可以在gitLab上點擊在線解決，?

如果不想在線解決沖突，也可在VS code中解決。首先使用git remote update -p ?# 獲取所有遠程最新數據，并清理過時的遠程分支?。其次git checkout 自己的開發分支名 ? # 切換到你的分支（假設當前不在你的分支）。然后git merge 主分支名 ? # 將遠程 develop 分支合并到你的分支。此時在左側的源代碼管理中會列舉沖突的文件（右側會提示感嘆號），點擊進去會顯示具體的沖突代碼，此時可以依據自己的需求解決沖突之后，然后重新提交推送合并即可。

3、上面說到的原始合并沖突會有個情況，即開發分支B收到了develop的污染。下面說下進階版。

背景：假設現在有主分支 ：develop，開發分支A,開發分支B，初版發布分支1.1.0,更新版發布分支1.1.1，本次發布分支1.1.2。此時A與B分支都是基于1.1.0分支創建的，develop是調試用的分支。發布時會將各自的開發分支合并至發布分支上,但此時有個復雜情況就是分支A是第二次迭代的時候合并至1.1.1上了，此時分支B是第三次迭代的開發分支，是需要合并到1.1.2上的，此時有人就會問了，為什么B分支不在1.1.1的基礎上創建呢？因為第二次迭代與第三次迭代是同步開發的。此時我再想通過merge develop到B分支上時就會出現污染。因為develop分支上可能存在某些代碼是本次發布不需要發布出去的代碼。此時，比如有個需求，需要在開發分支B上修改1.1.1分支上的某個文件index.js，此時應該怎么做呢？

解決方案：使用 gitcheckout+臨時分支(推薦)

第一步：在本地模擬合并沖突

# 1. 確保當前在B分支且工作區干凈
git checkout B
git status ?# 確認沒有未提交的修改

# 2. 基于當前B創建臨時分支(用于安全測試合并)
git checkout -b 臨時分支名稱

# 3. 嘗試將 develop 合并到臨時分支(觸發沖突):（這里也可以merge1.1.1分支，只是develop是調試分支，所有的開發分支都需要合并至develop分支驗證通過才會合并至1.1.2上），這里解決的是B分支與develop分支合并沖突。

git merge develop
#這里會報沖突，但不會影響原B分支

第二步：在 VSCode 中查看沖突

VSCode 會自動檢測沖突:
1.打開 源代碼管理面板(左側導航欄的 Git 圖標)。
2.沖突文件會顯示為 紅色感嘆號 !，文件名旁標注 CONELICT 。
3.點擊沖突文件，會看到沖突標記(<<<<<<<、==----=、>>>>>>>)。

手動查看沖突文件:git status

第三步：清理臨時分支(不保存合并結果)，此時B分支完全未被修改，且你已知道沖突文件。

git checkout B #切換回原分支

git branch -D 臨時分支名 #強制刪除臨時分支

第四步：此時可將剛剛在臨時分支上解決好的沖突代碼復制一份替換至B分支上，此時就可以精確的解決index.js文件的代碼沖突，而不會造成污染。此時再次提交推送合并即可。