首先,一個用git 寫代碼,而且只有一個本地分支的情況下是不會又沖突的.
沖突可以說是兩個分支的沖突.具體是兩個已經提交的分支的相同文件相同位置的的不同操作進行了合並.
不會沖突的習慣是,修改文件之前先merge 別的分支.
我在master 分支上創建並提交一個文件,切換到新的b分支上是沒有這個文件的.這說明分支之間是相互獨立的.
通過git merge master 把master上新增的文件給merge 過來.這是不會又沖突的.0+x = x
如果我在新的分支b上把master 對應行的數據給改了,並提交.然后切換到master,我再git merge b -m 'from b' 也不會沖突,結果是被b分支的修改給覆蓋了.
沖突的原因:
如果我切換到分支b ,修改了master 原本哪行的代碼,提交.然后再切換到master.我不知道b修改了這個文件.我也修改這一行的代碼,並提交.好了,"兩個分支相同文件相同位置的的不同操作" 我這個時候就在master merge b 或在 b上merge master. 沖突!!! 不解決沖突是沒法提交和切換到別的分支的. 反正這個沖突后的文件必須被改動一下.
自動合並:
上面沖突的原因大字體的句子改為,我不知道b修改了這個文件.我[我在我自己的代碼上做了修改,b並沒有動我代碼]的代碼,並提交,然后去合並b ,不會沖突,即便我沒有先merge b.這種情況是自動合並.
如何解決沖突:
沖突發生的時候,最好能聯系一下開發的人員,一起解決沖突.
一般情況下沖突后的文件會是:
<<<<<<<<HEAD
other code
========
your code
>>>>>>>>your branch name
解決的一般辦法是:仔細對比,取綜合的並集,就是盡量把所有不同的文件保留,共同的只留一份
個人的一點經驗:多人協作開發的時候,如果出現了你沒有改過的文件跟你沖突了,一定要去找到當事者,說清楚是如何沖突,然后協商解決,千萬不要擅自拉別的分支去試圖解決沖突,或找文件覆蓋.同時記住,解決了之后,要add 和 commit 最后push.為保證萬無一失,最后在沖突都解決之后,重啟項目,特別是指服務器項目,保證至少不會有立即奔潰的現象發生.然后才去提交,push.
提交的時候,一定要保持清醒,先搞清楚自己要提交的文件之間的關系,然后再提交,這樣才不會有文件缺失的問題,造成奔潰.
如果任務比較多,又建議開多個分支,分別進行開發.還是老話,一定要清楚自己在各個分支上做了什么,自己要提交的是什么.最好是能做個詳細的筆記.好記性不如爛筆頭.
最笨的辦法:沒有把握寧願不要去提交生產機.
提交代碼的時候不要走神,因為這是一個神聖的時刻.開發的時候你可以怎么測試都行,一旦上生產機,各種奇葩問題都會出現.