1.什麽是沖突

　　沖突是指當你在提交或者更新代碼時被合並的文件與當前文件不一致。讀起來有點繞，結合下面的案例理解。

　　從上面對沖突的定義來看，沖突時發生在同一個文件上的。

2.生產上沖突的場景

　　常見沖突的生產場景如下

1. 更新代碼
2. 提交代碼
3. 多個分支代碼合並到一個分支時
4. 多個分支向同一個遠端分支推送代碼時

　　git的合並中產生沖突的具體情況：
　　<1>兩個開發者（分支中）修改了同一個文件（不管什麽地方）
　　<2>兩個開發者（分支中）修改了同一個文件的名稱
　　註意：兩個分支中分別修改了不同文件中的部分，不會產生沖突，可以直接將兩部分合並。

　　總結：上面各種情況的本質都是，當前文件與合並文件不一致，因此不論哪種情況其解決沖突的方法是一樣的

3.idea中解決沖突

　　模擬場景：

　　假設有另個開發人員開發同一個項目，並且編寫同一個文件,工作流程如下：

　　1.01號程序員先上傳文件conflict.txt，並繼續在conflict.txt上寫代碼；

　　2.02號程序員更新項目代碼，並在conflict.txt上寫代碼，寫完後，在提交到遠程服務端；

　　3.當01號程序員把寫完後，準備提交代碼了，這時的正規操作手法，先更新在提交，但是在更新的時候必然會沖突，因為這時候更新的代碼conflict.txt與本地倉庫代碼conflict.txt不一致

　　提交前，我要更新，沖突了：

　　解決方案如下：

　　accept yours:代表以自己的為準；

　　accept theris:代表以更新下來的文件為準；

　　merge:代表手動合並

　　一般解決沖突我們都是選擇merge

　　將需要的內容點擊：">>"既可以合並內容到result中，不需要的內容點擊“x”即可，合並完成後點擊apply即可。

　　值得註意的是，最將所有的“x >>”符號都要處理完，不需要的點擊“x”,需要的點擊“>>”

　　最後，不論是什麽場景下產生的沖突解決方法是一樣的。

4.關於沖突的個人心得

　　多人協作開發的時候,如果出現了你沒有改過的文件跟你沖突了,一定要去找到當事者,說清楚是如何沖突的；

　　然後協商解決,千萬不要擅自拉別的分支去試圖解決沖突,或找文件覆蓋，更或者以自己的文件為準.

　　同時記住,解決了之後,要add 和 commit 最後push.為保證萬無一失,最後在沖突都解決之後,重啟項目；

　　保證至少不會有立即奔潰的現象發生.然後才去提交,push.

　　提交的時候,一定要保持清醒,先搞清楚自己要提交的文件之間的關系,然後再提交,這樣才不會有文件缺失的問題,造成奔潰.

　　如果任務比較多,又開了多個分支,分別進行開發,再次強調，一定要清楚自己在各個分支上做了什麽,自己要提交的是什麽.最好是能做個詳細的筆記，沒有把握寧願不要去提交到生產服務器.

　　提交代碼的時候不要走神,因為這是一個神聖的時刻！

git在idea中的沖突解決（非常重要）