一文理解GIT的代碼沖突

對于GIT，不知道有沒有人和我一樣，很長時間都是小心翼翼、緊張兮兮，生怕一不小心，自己辛苦寫的代碼沒了。

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

【資料圖】

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

只要理解了，你會發現所有問題一下子沒了，所有焦慮一下子釋然，你變的自信而堅定。

接下來說一下我對GIT代碼沖突的理解，希望能幫助到你。

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

（1）本地倉庫和遠程倉庫之間

場景一般是：你從遠程倉庫拉取了代碼開始開發，在這期間，有同事提交了代碼，等你提交時，報錯不讓你提交了。

（2）本地的分支之間

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

其實，本質都是一樣的，我們用一個簡單的模型來解釋，為什么會出現代碼沖突。

（1）沒有沖突的場景：

我們把A倉庫（分支）的代碼拉取到B倉庫（分支），一頓開發后，向A提交。

這么做一點問題都沒有，既然你是在我之上修改的船新版本，很好，一切以你為準，沒問題。

（2）沖突來了：

我們把A倉庫（分支）的代碼拉取到B倉庫（分支），在我們開發的過程中，A發生了變化（不管什么原因），開發完成后我們再向A提交。

不用說GIT，我們自己都會覺得這事兒有問題。

我們倆都是在老代碼之上修改的船新版本，那么以誰為準??？咱倆改的不是一個地方還好說，如果改的是同一個地方，那么GIT根本沒法自己判斷選擇哪一個。

這就是GIT的代碼沖突，一句話：你跑了一趟回來（開發完成回來提交），它已經變了（相比當初拉取代碼時，發生了變化）。

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

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

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

（1）遠程倉庫和本地倉庫的沖突

在這種場景下，可以這么做嗎？

顯然，不行。因為遠程倉庫那邊，沒有人會給你處理沖突。所以遠程倉庫對于這種方式，是直接拒絕的，只能采用第二種了。

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

遠程倉庫不允許，本地分支卻可以，因為都是在我們本地，程序員可以處理沖突。

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

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

我們再來看一下采用這種方式，兩種沖突場景各自是怎么處理的。

（1）遠程倉庫和本地倉庫的沖突

對于本地和遠程倉庫的沖突，我們一般就是這么做的。

從邏輯上講，既然你不敢接受我的推送，是因為我不是在你的基礎上修改的。那好，我提交前先拉取你的代碼，主動和你拉齊，現在你的代碼我都有，我就是在你的基礎上修改的了，你現在可以放心的接受我的推送了吧。

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

對于分支，我們也可以按照這個思路。先在develop上執行merge master，處理完沖突后，再切換到master，執行merge develop。這樣，同樣倆分支都成了最新版本。是不是發現比第一種方式更簡單？

最后總結一下：

1、本地倉庫和遠程倉庫的沖突：

（1）git pull。沒有沖突最好，有沖突處理沖突。

（2）gitadd -A

（3）gitcommit -m

（4）gitpush

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

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

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

（1）gitmerge master。把master分支合并過來，沒有沖突最好，有沖突處理沖突。

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

（3）gitmerge develop。把develop分支合并過來。

關鍵詞：