（八）合并冲突的比较与解决

1. 两边改动同一句说明

接着在 docs/personal 分支把 README 的用途改成“个人阅读统计”，main 则改成“每日阅读统计”，并分别提交。这次改的是同一位置：

# 从当前 main 开始新分支，在 README 改为“项目用途：个人阅读统计。”。
git switch -c docs/personal
git add -- README.md
git commit -m "说明个人阅读用途"
git switch main
# 在 README 同一行改为“项目用途：每日阅读统计。”后保存。
git add -- README.md
git commit -m "说明每日阅读用途"
git merge docs/personal
git status --short

Git 停下，README 中出现冲突标记，状态通常是 UU README.md：

<<<<<<< HEAD
项目用途：每日阅读统计。
=======
项目用途：个人阅读统计。
>>>>>>> docs/personal

本次操作中 HEAD 一边是当前 main，另一边是要合入的 docs/personal。Git 找到了两个不同的新内容，但不知道项目应该采用哪一种表述。

# 查看共同版本、当前分支版本和待合入版本，1/2/3 是冲突索引的三个阶段。
git show :1:README.md
git show :2:README.md
git show :3:README.md

共同版本写“阅读练习”；两边分别增加了“个人”和“每日”。这次想保留两项信息，最终写成 项目用途：个人每日阅读统计。，删除三种冲突标记。接着：

# 保存最终文字后，暂存表示这份路径已经解决。
git add -- README.md
git diff --cached
python check_reading.py
git commit -m "合并个人与每日阅读用途说明"
git status

git add 不会替我们判断句子或代码是否正确，它把当前保存的文件作为解决结果。若决定暂时取消这次合并，git merge --abort 会结束进行中的合并并尝试回到合并前；本例从干净工作目录开始，因此回到两次独立提交仍未合并的状态。已经手动编辑的解决结果要保留时，先另存再取消。merge 的冲突与取消

2. 按动作理解当前与传入版本

这里是“main 合并功能分支”，所以当前版本是 main。后面进行 rebase 时，当前一侧会是新基线及已经重放的提交，传入一侧是正在重放的功能提交。先读实际内容和操作名称，再决定采用哪一项；不要单凭“当前”“传入”想象作者是谁。