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