git merge 出现 conflict 后必须用 git add 显式标记已解决的冲突文件，再执行 git commit；不可跳过 git add 或使用 git commit -m 简化提交，否则报 fatal: cannot do a partial commit during a merge。
git merge 后出现 CONFLICT 提示怎么办
直接执行 git commit 会失败，Git 会报错：「fatal: cannot do a partial commit during a merge」。这不是漏写了 -m 参数，而是 Git 强制要求你先明确标记哪些冲突已解决，才能继续提交。
必须用 git add 标记已解决的文件
git add 在冲突场景下不是“添加新文件”，而是“告诉 Git：这个文件的冲突我已经手动处理完了”。不执行这步，Git 拒绝任何 commit。
- 只对真正修改过的冲突文件运行
git add <file></file>，比如git add index.html - 不要
git add .—— 它可能把未修改但处于 unmerged 状态的文件也加进去，导致后续提交混乱 - 如果改了多个冲突文件，每个都得单独
git add，Git 不接受批量“全部确认” - 执行后用
git status确认输出里不再有 “Unmerged paths”，只有 “Changes to be committed”
git commit 不需要额外参数就能完成合并
一旦所有冲突文件都被 git add 过，直接运行 git commit 即可。Git 会自动调用默认编辑器，生成一条带 “Merge branch 'xxx'” 的提交信息 —— 这是合并提交的标准格式，别删它。
- 如果你用
git commit -m "fix conflict"，虽然能成功，但会丢失自动注入的分支来源信息，历史追踪变弱 - 不建议加
--no-edit，除非你确定要跳过检查；默认编辑器打开时，至少扫一眼自动生成的提交说明是否合理 - 提交后，
git log --oneline会看到一条新记录，它的 parent 有两个（即两个分支的最新提交）
别碰 git merge --continue 或 git rebase --continue
这两个命令只在 git rebase 或 git merge 中途被中断（比如遇到冲突后你退出了编辑器）时才有效。普通 merge 出现冲突后，解决 + git add + git commit 就是完整流程，不需要、也不该用 --continue。
强行用会报错 “No merge in progress”，或者误触发 rebase 流程，把本该是一次合并提交的操作变成一串线性提交，破坏分支拓扑。
