對(duì)于GIT，不知道有沒(méi)有人和我一樣，很長(zhǎng)時(shí)間都是小心翼翼、緊張兮兮，生怕一不小心，自己辛苦寫的代碼沒(méi)了。

特別是代碼沖突，更是難到我無(wú)法理解，每次都要求助于百度，跟著人家的教程一步步解決，下一次還是這樣。

【資料圖】

所有的緊張、不自信、不敢用、用不好，都來(lái)源于：不理解。

只要理解了，你會(huì)發(fā)現(xiàn)所有問(wèn)題一下子沒(méi)了，所有焦慮一下子釋然，你變的自信而堅(jiān)定。

接下來(lái)說(shuō)一下我對(duì)GIT代碼沖突的理解，希望能幫助到你。

GIT的代碼沖突主要存在于兩個(gè)地方：

（1）本地倉(cāng)庫(kù)和遠(yuǎn)程倉(cāng)庫(kù)之間

場(chǎng)景一般是：你從遠(yuǎn)程倉(cāng)庫(kù)拉取了代碼開(kāi)始開(kāi)發(fā)，在這期間，有同事提交了代碼，等你提交時(shí)，報(bào)錯(cuò)不讓你提交了。

（2）本地的分支之間

場(chǎng)景一般是：你從master分支拉出了develop分支，在develop分支上開(kāi)發(fā)，在這期間，各種原因，master分支發(fā)生了變化。等你想把develop分支合并到master分支，提示代碼沖突。

其實(shí)，本質(zhì)都是一樣的，我們用一個(gè)簡(jiǎn)單的模型來(lái)解釋，為什么會(huì)出現(xiàn)代碼沖突。

（1）沒(méi)有沖突的場(chǎng)景：

我們把A倉(cāng)庫(kù)（分支）的代碼拉取到B倉(cāng)庫(kù)（分支），一頓開(kāi)發(fā)后，向A提交。

這么做一點(diǎn)問(wèn)題都沒(méi)有，既然你是在我之上修改的船新版本，很好，一切以你為準(zhǔn)，沒(méi)問(wèn)題。

（2）沖突來(lái)了：

我們把A倉(cāng)庫(kù)（分支）的代碼拉取到B倉(cāng)庫(kù)（分支），在我們開(kāi)發(fā)的過(guò)程中，A發(fā)生了變化（不管什么原因），開(kāi)發(fā)完成后我們?cè)傧駻提交。

不用說(shuō)GIT，我們自己都會(huì)覺(jué)得這事兒有問(wèn)題。

我們倆都是在老代碼之上修改的船新版本，那么以誰(shuí)為準(zhǔn)啊？咱倆改的不是一個(gè)地方還好說(shuō)，如果改的是同一個(gè)地方，那么GIT根本沒(méi)法自己判斷選擇哪一個(gè)。

這就是GIT的代碼沖突，一句話：你跑了一趟回來(lái)（開(kāi)發(fā)完成回來(lái)提交），它已經(jīng)變了（相比當(dāng)初拉取代碼時(shí)，發(fā)生了變化）。

那么，GIT是怎么處理代碼沖突的呢？有兩種方式：

第一種方式：B仍然向A提交代碼，A進(jìn)行代碼合并、處理沖突后，B再把A的代碼拉過(guò)來(lái)，A和B都是最新版本了。

我們分別看一下采用這種方式，兩種沖突場(chǎng)景各自是怎么處理的。

（1）遠(yuǎn)程倉(cāng)庫(kù)和本地倉(cāng)庫(kù)的沖突

在這種場(chǎng)景下，可以這么做嗎？

顯然，不行。因?yàn)檫h(yuǎn)程倉(cāng)庫(kù)那邊，沒(méi)有人會(huì)給你處理沖突。所以遠(yuǎn)程倉(cāng)庫(kù)對(duì)于這種方式，是直接拒絕的，只能采用第二種了。

（2）本地分支之間的沖突

遠(yuǎn)程倉(cāng)庫(kù)不允許，本地分支卻可以，因?yàn)槎际窃谖覀儽镜?，程序員可以處理沖突。

一般對(duì)于本地分支的沖突，我們也是這么做的。master分支把develop分支merge過(guò)來(lái)，處理完沖突后，develop分支再把master分支merge回來(lái)，這樣倆分支都是最新版本了。當(dāng)然如果develop分支不需要了，你直接刪了也可以。

第二種方式：B先拉取A的代碼，在本地處理沖突后，再把代碼提交給A，這樣A和B都是最新版本了。

我們?cè)賮?lái)看一下采用這種方式，兩種沖突場(chǎng)景各自是怎么處理的。

（1）遠(yuǎn)程倉(cāng)庫(kù)和本地倉(cāng)庫(kù)的沖突

對(duì)于本地和遠(yuǎn)程倉(cāng)庫(kù)的沖突，我們一般就是這么做的。

從邏輯上講，既然你不敢接受我的推送，是因?yàn)槲也皇窃谀愕幕A(chǔ)上修改的。那好，我提交前先拉取你的代碼，主動(dòng)和你拉齊，現(xiàn)在你的代碼我都有，我就是在你的基礎(chǔ)上修改的了，你現(xiàn)在可以放心的接受我的推送了吧。

（2）本地分支之間的沖突

對(duì)于分支，我們也可以按照這個(gè)思路。先在develop上執(zhí)行merge master，處理完沖突后，再切換到master，執(zhí)行merge develop。這樣，同樣倆分支都成了最新版本。是不是發(fā)現(xiàn)比第一種方式更簡(jiǎn)單？

最后總結(jié)一下：

1、本地倉(cāng)庫(kù)和遠(yuǎn)程倉(cāng)庫(kù)的沖突：

（1）git pull。沒(méi)有沖突最好，有沖突處理沖突。

（2）gitadd -A

（3）gitcommit -m

（4）gitpush

后三步和平時(shí)提交代碼一個(gè)樣。所以，提交代碼前先pull，是一個(gè)很有必要的好習(xí)慣。

2、本地master分支和develop分支的沖突：

（1）git switch develop。切換到develop分支。

（1）gitmerge master。把master分支合并過(guò)來(lái)，沒(méi)有沖突最好，有沖突處理沖突。

（2）gitswitch master。切換回master分支。

（3）gitmerge develop。把develop分支合并過(guò)來(lái)。

關(guān)鍵詞：