1.實(shí)驗(yàn)問題：多人協(xié)作下的合并沖突問題
1.1 實(shí)驗(yàn)一
實(shí)驗(yàn)?zāi)康模?/strong>
模擬某些情況下使用git pull下拉遠(yuǎn)程倉庫代碼時(shí)覆蓋了自己已有代碼
實(shí)驗(yàn)步驟：
使用git clone拷貝遠(yuǎn)程倉庫到本地
使用git reset --hard把本地倉庫工作區(qū)，版本庫都回退到很久之前的版本
使用git pull下拉遠(yuǎn)程倉庫最新分支，觀察本地倉庫代碼變化
實(shí)驗(yàn)結(jié)果：
本地倉庫的所有代碼都被完全替代成遠(yuǎn)程倉庫的最新版本
實(shí)驗(yàn)分析：
在git pull拉下之后遠(yuǎn)程倉庫分支之后，對(duì)應(yīng)了之前總結(jié)的git merge的fast forward模式，因?yàn)楸镜貍}庫分支和遠(yuǎn)程倉庫分支不分叉，因此進(jìn)行了fast forward模式合并
1.2 實(shí)驗(yàn)二
實(shí)驗(yàn)?zāi)康模?/strong>
模擬某些情況下，多人共同開發(fā)相同文件，在git pull時(shí)發(fā)生的沖突
實(shí)驗(yàn)步驟：
- 工作者一
- 給工作者一創(chuàng)建一個(gè)文件夾，表示工作者一的工作區(qū)
- 使用git clone把遠(yuǎn)程倉庫拷貝到工作區(qū)
- 在工作區(qū)對(duì)項(xiàng)目中的文件X做出修改
- 打開windows的憑據(jù)管理器，修改已保存的登錄憑據(jù)（此處以gitee為例，修改gitee的登錄憑據(jù)即可），修改為工作者一的用戶名和密碼
- 使用git add .和git commit -m和git push將最新分支提交到遠(yuǎn)程倉庫
- 工作者二
- 給工作者二創(chuàng)建一個(gè)文件夾，表示工作者二的工作區(qū)
- 使用git clone把遠(yuǎn)程倉庫拷貝到工作區(qū)
- 在工作區(qū)對(duì)項(xiàng)目中的文件X做出修改
- 打開windows的憑據(jù)管理器，修改已保存的登錄憑據(jù)，修改為工作者二的用戶名和密碼
- 使用git pull拉下最新分支，觀察結(jié)果
- 使用git add .和git commit -m和git push將本地分支提交到遠(yuǎn)程倉庫，觀察結(jié)果
- 使用git pull來下最新分支，觀察結(jié)果
- 使用git reset --merge撤銷git pull導(dǎo)致的合并
- 修改沖突位置的代碼，可以選擇在文件中手動(dòng)修改：同時(shí)保留遠(yuǎn)程倉庫和本地倉庫的代碼。可以選擇IDE修改：可以選擇留下任何內(nèi)容（推薦使用專業(yè)IDE例如VSCODE，會(huì)有merge editor，可以直接指定merge合并結(jié)果。否則需要手動(dòng)輸入其它git 指令來合并）
- 使用git add .和git commit -m和git push將本地分支提交到遠(yuǎn)程倉庫，觀察結(jié)果
實(shí)驗(yàn)結(jié)果：
- 顯示git pull失敗，提示需要git stash或git commit
- 顯示git push失敗，提示當(dāng)前倉庫版本低于遠(yuǎn)程倉庫版本并有分叉
- 顯示文件X處產(chǎn)生git merge沖突
- 顯示上傳遠(yuǎn)程倉庫成功
實(shí)驗(yàn)分析：
- git merge時(shí)如果工作區(qū)有修改，那么不會(huì)進(jìn)行
- git push失敗是因?yàn)槊鞅镜貍}庫版本落后于遠(yuǎn)程倉庫，并且出現(xiàn)了分叉，這樣才會(huì)被拒絕
- git merge失敗是因?yàn)閮蓚€(gè)人都對(duì)X文件修改，不清楚保留哪一個(gè)修改
- 當(dāng)前倉庫分支合并后版本高于遠(yuǎn)程倉庫版本，上傳成功
2.實(shí)戰(zhàn)問題：?jiǎn)稳藢?dǎo)致的合并沖突問題
2.1 同一分支下單人導(dǎo)致的合并沖突問題
引入：提升切換分支的速度
正在最新的還沒有上線的分支修改文件，但是老的已經(jīng)上線的分支上出現(xiàn)了錯(cuò)誤，需要切換分支修改。而當(dāng)前分支修改的文件很多，功能沒有開發(fā)完全，因此有很多eslint問題導(dǎo)致不能直接提交并發(fā)送到遠(yuǎn)程倉庫。
老的解決方案：
想要快速切換分支，不想一個(gè)個(gè)把功能沒開發(fā)完導(dǎo)致的eslint警告給修改掉。就從遠(yuǎn)程倉庫clone了多份一樣的倉庫到本地。然后修改時(shí)不切換分支，直接在另一個(gè)clone的項(xiàng)目文件上修改。
產(chǎn)生的問題：
這通常來講沒有問題。因?yàn)樾薷牡睦戏种系睦洗a一般當(dāng)前版本不再修改，一般不會(huì)有沖突。但是有時(shí)候可能在clone的項(xiàng)目1上修改了當(dāng)前分支的文件并提交，過了一段時(shí)間忘記了自己在clone的哪個(gè)分支上提交文件了，你可能打開了clone的項(xiàng)目2。這時(shí)你必須git pull拉取最新代碼，但實(shí)際上可能會(huì)忘記這個(gè)操作。原因是文件都是由自己修改，當(dāng)前本地倉庫版本一定大于等于遠(yuǎn)程倉庫，不需要git pull。但是clone多份項(xiàng)目下來，會(huì)有本地倉庫版本小于等于遠(yuǎn)程倉庫的情況，這需要我們關(guān)注更多的版本細(xì)節(jié)。因此這種解決方案不是一種好主意。
2.2 不同分支下單人導(dǎo)致的合并沖突問題
引入：修改已上線分支的問題
在最新未上線的分支（例如7.1.50）中進(jìn)行開發(fā)時(shí)，上一個(gè)版本的老分支（例如7.1.40）出現(xiàn)的問題需要修改。此時(shí)需要切換分支修改。但是有時(shí)候改完之后，忘記切回最新分支了，然后繼續(xù)在老分支上開發(fā)最新的功能并提交，當(dāng)你發(fā)現(xiàn)時(shí)你的同事已經(jīng)進(jìn)行了若干次提交，如果你進(jìn)行回滾，就會(huì)丟失同事的修改。此時(shí)選擇繼續(xù)在最新分支上進(jìn)行開發(fā)。當(dāng)老版本分支進(jìn)入穩(wěn)定版本后，會(huì)把老版本分支和當(dāng)前分支進(jìn)行合并。此時(shí)就會(huì)出現(xiàn)問題，同一份文件都是自己修改，但是無法直接合并，因?yàn)閷⒎种У奶峤挥涗浛醋鳂?，那么你自己修改的文件?.1.40和7.1.50中不存在祖先孩子關(guān)系，無法直接合并，這樣就造成了沖突。
解決方案：
很簡(jiǎn)單，直接選擇合并的內(nèi)容即可
3.總結(jié)
解決沖突的最好方案是：
-
git pull之后手動(dòng)修改：
- 只保留遠(yuǎn)程倉庫的代碼，剪切你的修改，等到合并成功后再對(duì)文件進(jìn)行修改并重新提交
- 同時(shí)保留遠(yuǎn)程倉庫的代碼和你的代碼，合并可以成功
- 使用IDE提供的merge editor，可以選擇性保留任意內(nèi)容
-
git pull之前修改：
-
只保證工作區(qū)做出了修改，如果提交到了版本庫，那么使用git reset撤銷提交。
-
之后使用git stash將工作區(qū)修改緩存進(jìn)棧。
-
之后git pull下拉代碼，直接進(jìn)行fast forward合并。
-
再進(jìn)行g(shù)it stash pop出棧，自動(dòng)發(fā)生git merge合并，此時(shí)你還需要遵循上述方案選擇如何merge合并。文章來源：http://www.zghlxwxcb.cn/news/detail-468032.html
-
-
項(xiàng)目開發(fā)時(shí)的規(guī)范：文章來源地址http://www.zghlxwxcb.cn/news/detail-468032.html
- 不要fork或clone多份遠(yuǎn)程倉庫到本地，保證本地倉庫只有一個(gè)。當(dāng)切換分支時(shí)，先處理當(dāng)前修改的提交。
- 每次開發(fā)時(shí)應(yīng)先檢查當(dāng)前分支版本。每次提交時(shí)應(yīng)先檢查分支版本。避免把代碼提交到錯(cuò)誤分支。
到了這里，關(guān)于解決git合并的沖突問題的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
