冲突解决后必须手动提交，不能跳过：需编辑文件、git add 标记、再 git commit；提交信息须规范为“resolve: [模块名] conflict in [文件路径]”，关联 issue/MR 编号，且不得混入新功能。
冲突解决后必须手动提交，不能跳过 git commit
执行 git merge 或 git rebase 触发冲突后，Git 会停在冲突状态，不会自动生成提交。你必须手动编辑文件、git add 标记已解决，再运行 git commit —— 这一步漏掉，合并就卡死在“未完成”状态。
常见错误现象：
- 终端卡在
CONFLICT (content): Merge conflict in xxx.js后无响应 - 误以为
git merge --continue能跳过提交（它只对rebase有效） - 直接
git push报错 “non-fast-forward”，因为本地 HEAD 没更新
提交信息必须带 resolve 前缀和具体文件/模块名
规范的冲突解决提交不是“修复冲突”这种空泛描述，而是明确指出“谁在什么上下文里解决了什么”。团队日志可读性、后续 git blame 追溯、CI 自动识别都依赖这个结构。
推荐格式：resolve: [模块名] conflict in [文件路径]
- ✅
resolve: user-service conflict in api/auth.js - ✅
resolve: payment-gateway conflict in handlers/refund.ts - ❌
fix conflict（太模糊） - ❌
merge fix（没说明解决对象）
如果冲突涉及多个文件且属同一逻辑模块，用逗号分隔：resolve: order-api conflict in service/order.go, dto/order_request.go
不要在冲突提交里混入新功能或重构
冲突解决提交的唯一职责是让两个分支的修改共存，不是趁机加代码。一旦夹带额外变更，会导致：
github-repo-analyzer
下载
当用户提及 GitHub URL，或要求分析、审查、探索或理解任意 GitHub 项目、仓库或代码库时，请使用此技能。触发条件包括以下短语：“分析这个项目”、“看看这个仓库”、“analyze this repo”、“what does this project do”，或消息中包含任何 github.com URL。
- 历史难以回溯：无法区分哪些是解决冲突引入的，哪些是新增逻辑
- Code Review 失效：评审人默认该提交只处理冲突，忽略新增内容
- 回滚风险：想 revert 冲突提交时，可能意外删掉本不该删的功能
实操建议：
- 解决冲突前先
git status确认只有冲突文件被修改 - 解决后
git diff --cached检查暂存区，确保没有意外加入的改动 - 如果真需要同步改逻辑，另起一个 commit，不要塞进
resolve:提交里
多人协作时，冲突提交必须关联原始 issue 或 MR 编号
当 feature 分支和 main 同时修改了同一段代码，冲突本质是需求/实现层面的不一致。仅写文件名不够，得锚定到源头。
- ✅
resolve: user-profile conflict in components/ProfileCard.vue (REQ-7892) - ✅
resolve: auth flow conflict in middleware/auth.ts (MR !456)
这样做的实际好处：
- 后续有人查
REQ-7892的全部变更，能一眼看到冲突如何被协调 - 自动化工具（如 GitLab CI）可基于 issue 号触发对应测试套件
- 避免“这个冲突为什么这么解”的重复沟通——答案就在 issue 评论里
最容易被忽略的一点：冲突提交本身不解决根本矛盾，只是临时协调。真正要减少这类提交，得回到分支同步节奏和接口契约上——比如每天 git rebase main 一次，比攒三天再 merge 更安全。
