3.4 解决合并冲突
前置知识：分支与合并
预计时间：15 分钟
练习环境：继续使用同一个临时仓库
完成标志：能制造、解释、解决和取消一次冲突
快进合并很安静，因为主线没有分叉。现在让两条分支同时修改同一个配置，Git 就会遇到无法替人回答的问题。冲突不是仓库损坏，只是两条时间线改了同一处，需要人决定最终语义。
在练习仓库制造冲突
bash
printf '%s\n' 'color=blue' > settings.txt
git add settings.txt
git commit -m 'Add default color'
git switch -c color-red
printf '%s\n' 'color=red' > settings.txt
git commit -am 'Choose red'
git switch main
git switch -c color-green
printf '%s\n' 'color=green' > settings.txt
git commit -am 'Choose green'
git switch main
git merge color-red
merge_status=0
git merge color-green || merge_status=$?
test "$merge_status" -eq 1
git status文件中会出现：
diff
| <<<<<<< HEAD
| color=red
| =======
| color=green
| >>>>>>> color-green左侧 | 只是文档展示前缀，不属于文件内容；真实冲突标记从行首开始。
HEAD一侧来自当前分支合并前的版本。- 另一侧来自正在合入的提交。
- 标记之间不是“任选一边就必定正确”，还要根据配置约束和业务语义决定最终内容。
解决并验证
bash
printf '%s\n' 'color=purple' > settings.txt
git diff --check
git add settings.txt
git status
git commit -m 'Resolve color configuration conflict'
git log --graph --oneline --decorate --all真实项目应在 git add 前后运行对应测试，确认没有残留冲突标记：
bash
git grep -n -E '^(<<<<<<<|=======|>>>>>>>)' -- ':!*.md' || true这条搜索可能误报合法文本，也可能因排除规则漏报，因此只能作为辅助检查。
不想继续这次合并
下面是与“解决并提交”互斥的退出路径。应在前面的合并仍处于冲突状态时使用；已经提交解决结果后，不要继续执行：
bash
git merge --abort它通常回到合并开始前。若开始合并时已有未提交修改，Git 不一定能完整重建原现场；合并前保持工作区清晰更可靠。rebase、cherry-pick 和 revert 冲突有各自的 --continue、--abort 流程，先看 git status 给出的当前操作提示。
图形合并工具能帮助对照，但仍由你决定最终语义。完成后必须查看 diff 和运行测试。
→ 下一步：远程仓库