衝突是指當你在提交或者更新**時被合併的檔案與當前檔案不一致。讀起來有點繞，結合下面的案例理解。
從上面對衝突的定義來看，衝突時發生在同乙個檔案上的。
常見衝突的生產場景如下
更新**
提交**
多個分支**合併到乙個分支時
多個分支向同乙個遠端分支推送**時
git的合併中產生衝突的具體情況：
<1>兩個開發者（分支中）修改了同乙個檔案（不管什麼地方）
<2>兩個開發者（分支中）修改了同乙個檔案的名稱
注意：兩個分支中分別修改了不同檔案中的部分，不會產生衝突，可以直接將兩部分合併。
總結：上面各種情況的本質都是，當前檔案與合併檔案不一致，因此不論哪種情況其解決衝突的方法是一樣的。
模擬場景：
假設有另個開發人員開發同乙個專案，並且編寫同乙個檔案,工作流程如下：
1.01號程式設計師先上傳檔案conflict.txt，並繼續在conflict.txt上寫**；
2.02號程式設計師更新專案**，並在conflict.txt上寫**，寫完後，在提交到遠端服務端；
3.當01號程式設計師把寫完後，準備提交**了，這時的正規操作手法，先更新在提交，但是在更新的時候必然會衝突，因為這時候更新的**conflict.txt與本地倉庫**conflict.txt不一致
提交前，我要更新，衝突了：
解決方案如下：
accept yours:代表以自己的為準；
accept theris:代表以更新下來的檔案為準；
merge:代表手動合併
一般解決衝突我們都是選擇merge
值得注意的是，最將所有的「x >>」符號都要處理完，不需要的點選「x」,需要的點選「>>」
最後，不論是什麼場景下產生的衝突解決方法是一樣的。
多人協作開發的時候,如果出現了你沒有改過的檔案跟你衝突了,一定要去找到當事者,說清楚是如何衝突的；
然後協商解決,千萬不要擅自拉別的分支去試**決衝突,或找檔案覆蓋，更或者以自己的檔案為準.
同時記住,解決了之後,要add 和 commit 最後push.為保證萬無一失,最後在衝突都解決之後,重啟專案；
保證至少不會有立即奔潰的現象發生.然後才去提交,push.
提交的時候,一定要保持清醒,先搞清楚自己要提交的檔案之間的關係,然後再提交,這樣才不會有檔案缺失的問題,造成奔潰.
如果任務比較多,又開了多個分支,分別進行開發,再次強調，一定要清楚自己在各個分支上做了什麼,自己要提交的是什麼.最好是能做個詳細的筆記，沒有把握寧願不要去提交到生產伺服器.
提交**的時候不要走神,因為這是乙個神聖的時刻！
git 在idea中解決衝突
衝突是指當你在提交或者更新 時被合併的檔案與當前檔案不一致。讀起來有點繞，結合下面的案例理解。從上面對衝突的定義來看，衝突時發生在同乙個檔案上的。常見衝突的生產場景如下 更新 提交 多個分支 合併到乙個分支時 多個分支向同乙個遠端分支推送 時 git的合併中產生衝突的具體情況 1 兩個開發者 分支中...
在IDEA中實戰Git
工作中多人使用版本控制軟體協作開發，常見的應用場景歸納如下 假設小組中有兩個人，組長小張，組員小袁 場景一 小張建立專案並提交到遠端git倉庫 場景二 小袁從遠端git倉庫上獲取專案原始碼 場景三 小袁修改了部分原始碼，提交到遠端倉庫 場景四 小張從遠端倉庫獲取小袁的提交 場景五 小袁接受了乙個新功...
git衝突的解決
使用git pull更新 時，你修改的檔案已被他人修改，而自己沒有更新時，git會提示commit your changes or stash them before you can merge.此時可以用git stash將你修改的檔案暫存入棧中，然後git pull 然後git stash po...