git 要解決的沖突，是由分支合并帶來的。
合并（Merge）是將分支 A 的更改合并到分支 B 的過程。
合并場(chǎng)景
假如我們有 master 分支，然后有基于 master 分支創(chuàng)建出來的 develop 分支。
從 develop 分支合并到 master 分支的場(chǎng)景有以下兩種情況：
合并沖突發(fā)生在上述的第二個(gè)場(chǎng)景里，當(dāng)同一個(gè)文件在兩個(gè)分支上都被修改了。
同一文件的同一部分被不同的分支修改：當(dāng)兩個(gè)或多個(gè)分支對(duì)同一文件的同一部分進(jìn)行了不同的修改時(shí)，Git 無法自動(dòng)合并這些更改，從而產(chǎn)生沖突。
如果一個(gè)分支刪除了某個(gè)文件，而另一個(gè)分支修改了同一個(gè)文件，Git 也會(huì)產(chǎn)生沖突。
當(dāng)一個(gè)分支重命名了某個(gè)文件，而另一個(gè)分支對(duì)該文件進(jìn)行了修改，Git 也會(huì)產(chǎn)生沖突。
出現(xiàn)沖突的時(shí)候，就需要手動(dòng)解決沖突并提交合并結(jié)果。
合并的類型
合并的結(jié)果有兩種，一是直接合并，不產(chǎn)生新的提交。二是有沖突并解決了沖突，它會(huì)產(chǎn)生新的提交，這里的提交內(nèi)容就是合并沖突修改。
這里有三種類型的合并：前進(jìn)合并（fast-ford）、三方合并（three-way merge）和變基合并（Rebase）。
快速前進(jìn)合并（fast-forward）是最簡(jiǎn)單的合并方式。
還是以上述 master 分支和 develop 分支為例來說明。
當(dāng) master 分支沒有新的提交時(shí)，Git 只需將 master 分支的指針移動(dòng)到 develop 分支的最新提交即可。這種合并不會(huì)產(chǎn)生新的合并提交。
三方合并（three-way merge）是指當(dāng) master 分支和 develop 分支都有新的提交時(shí)，Git 會(huì)進(jìn)行三方合并。
這種合并會(huì)創(chuàng)建一個(gè)新的合并提交，包含兩個(gè)分支的更改。
# 切換到目標(biāo)master分支 git checkout master # 合并源develop分支 git merge develop
變基合并（Rebase）是將 develop 分支的提交應(yīng)用到 master 分支的基礎(chǔ)上，從而避免創(chuàng)建合并提交。
這種方式可以保持提交歷史的線性，但可能會(huì)導(dǎo)致沖突需要手動(dòng)解決。
# 切換到源develop分支 git checkout develop # 變基到目標(biāo)master分支 git rebase master
合并策略
在進(jìn)行合并時(shí)，還能使用不同的合并策略來控制合并的行為。
常見的合并策略包括：
# 使用 ours 策略進(jìn)行合并 git merge -s ours develop
解決合并沖突的辦法
解決合并沖突需要手動(dòng)干預(yù)，基本上可以按以下步驟進(jìn)行：
當(dāng)合并沖突發(fā)生時(shí)，Git 會(huì)提示哪些文件存在沖突。可以使用 git status 命令查看沖突文件。
git status
打開沖突文件，可以看到?jīng)_突部分被標(biāo)記為 <<<<<<< HEAD、======= 和 >>>>>>> branch_name。
這些標(biāo)記分別表示當(dāng)前分支的更改、分隔符和合并分支的更改。
<<<<<<< HEAD 當(dāng)前分支的更改 ======= 合并分支的更改 >>>>>>> branch_name
根據(jù)實(shí)際情況，手動(dòng)編輯沖突文件，保留需要的更改并刪除沖突標(biāo)記。
保留的更改
解決沖突后，使用 git add 命令將修改后的文件添加到暫存區(qū)。
git add conflict_file
最后，使用 git commit 命令提交合并結(jié)果。
git commit -m "解決合并沖突"
避免合并沖突
在團(tuán)隊(duì)協(xié)作里，頻繁出現(xiàn)合并沖突多少會(huì)影響開發(fā)效率，以及團(tuán)隊(duì)士氣。
所以我們?cè)诠ぷ鲿r(shí)會(huì)盡量避免沖突的發(fā)生。
它的策略核心是盡可能減少同時(shí)對(duì)同一個(gè)文件的修改，以及盡可能減少單次提交的代碼量。
頻繁拉取和推送代碼：團(tuán)隊(duì)成員應(yīng)養(yǎng)成頻繁拉?。?code style="-webkit-tap-highlight-color: transparent; margin: 0px; padding: 0.1em 0.3em; outline: 0px; max-width: 100%; box-sizing: border-box !important; overflow-wrap: break-word !important; line-height: 1; white-space: initial; color: rgb(51, 51, 51); background: rgba(27, 31, 35, 0.05); border-radius: 0.3em; font-weight: bold; font-size: 1em; top: -0.1em;">git pull）和推送（git push）代碼的習(xí)慣，以確保本地倉庫與遠(yuǎn)程倉庫保持同步。
小步提交：盡量將更改分成小的、獨(dú)立的提交，而不是一次性提交大量更改。這樣可以更容易地解決沖突，并且每次合并的范圍更小，沖突的可能性也會(huì)降低。
使用分支策略：采用合理的分支策略，如 Git Flow 或 GitHub Flow。每個(gè)功能或修復(fù)都在獨(dú)立的分支上進(jìn)行開發(fā)，完成后再合并到主分支。這可以減少直接在主分支上進(jìn)行開發(fā)導(dǎo)致的沖突。
代碼評(píng)審：在合并代碼之前進(jìn)行代碼評(píng)審（Code Review），可以提前發(fā)現(xiàn)潛在的沖突和問題，并在合并之前解決。
溝通和協(xié)調(diào)：團(tuán)隊(duì)成員之間應(yīng)保持良好的溝通，特別是在處理同一文件或模塊時(shí)。提前告知其他成員自己的更改計(jì)劃，可以避免同時(shí)修改同一部分代碼。
自動(dòng)化測(cè)試：在合并之前運(yùn)行自動(dòng)化測(cè)試，確保代碼的正確性和兼容性。這樣可以在合并之前發(fā)現(xiàn)并解決潛在的問題。
總結(jié)
?? 有三種類型的合并：前進(jìn)合并（fast-ford）、三方合并（three-way merge）和變基合并（Rebase）。
?? 在進(jìn)行合并時(shí)，還能使用不同的合并策略來控制合并的行為。
?? 在團(tuán)隊(duì)協(xié)作里，盡量避免沖突的發(fā)生。
該文章在 2024/12/4 17:24:57 編輯過
400 186 1886
