尤文主帅斯帕莱蒂与卡利亚里主帅皮萨卡内在握手环节因“拖延时间”言论爆发口角，双双被红牌罚下。
冲突文件里看到
这是 Git 插入的冲突标记，不是代码本身。 表示当前分支（比如 <code>main）里的修改内容，======= 是分隔线，>>>>>> branch-name 后面是待合并分支（比如 feature/login）的修改。Git 无法自动判断该留哪边、删哪边、还是合并逻辑，所以停在“未解决”状态。
手动编辑完冲突文件后必须执行 git add
很多人改完文件就直接 git commit，结果报错：fatal: cannot do a partial commit of a merge。这是因为 Git 要求所有冲突文件都得显式标记为“已解决”，而唯一方式就是 git add <file></file>。
注意以下几点：
-
git add不代表“准备提交”，它在这里的作用是告诉 Git：“这个文件的冲突我处理完了” - 如果改了多个冲突文件，每个都得
git add，漏一个就会卡住 - 用
git status能看到哪些文件还在Unmerged paths下，那就是还没add的 - 改完但没
add就关编辑器，下次git status还会显示冲突状态
git commit -m "Resolve conflict in xxx" 是标准写法
冲突解决后的提交本质是一次 merge 提交，Git 会自动生成合并信息，但你必须手动补上 -m 参数。不加 -m 会掉进 vim 编辑器里，新手容易懵。
常见误区：
- 不要写成
git commit -m "fix bug"—— 模糊描述不利于回溯，别人看不懂这提交干了啥 - 不要省略文件名，比如
Resolve conflict in src/utils/auth.js，方便后续查日志定位 - 如果一次解决多个文件冲突，写一个通用描述也行，如
Resolve login module conflicts
push 前务必确认当前分支和远程追踪关系
解决完冲突并提交后，别急着 git push。先跑两行命令：
git branch --show-current —— 确认你在目标分支（比如 main），不是阴差阳错切在 feature 上又 merge 回来
git config --get branch.$(git branch --show-current).merge —— 看当前分支是否绑定了正确的远程分支（如 refs/heads/main）
如果没绑定，git push 可能推到错的地方，或者报 fatal: The current branch main has no upstream branch。这时候得补一句：git push -u origin main。
最容易被忽略的是：冲突解决后的新提交，其父提交有两个（HEAD + 合并分支 tip），这意味着它是一次真正的 merge 提交。如果你之后想用 git revert 撤销这次合并，必须加 -m 1 指定主干侧，否则 Git 不知道你想 revert 哪一边。这点在做线上热修复时特别关键。
