合并冲突复盘:让规则落在流程里 合并冲突复盘让规则落在流程里冲突不是异常盲目选择--ours或--theirs才危险。解决冲突前先理解两边改动的意图完成后运行受影响的测试并在 diff 中确认没有把任一方的必要变更删掉。复盘的价值在于把重复出现的问题转成检查项或仓库规则。冲突处理的基本步骤更新目标分支确认冲突来自哪些提交。对每个冲突块查看两侧上下文和相关测试不以“保留一边”为默认策略。解决后搜索冲突标记运行格式化、构建和受影响测试。对生成文件优先重新生成二进制文件或不可自动合并的 Schema 由负责人确认来源。在 PR 中说明冲突处理方式必要时请原变更作者复核。git diff --check git diff --cached --check git grep -n -e -e -e 这些命令适合本地发现明显遗留但不能证明语义没有丢失语义问题仍需测试和评审。哪些规则适合自动化保护分支可以要求 CI 通过、至少一名评审人批准、关键目录的 CODEOWNERS 审查和分支与目标分支同步。合并队列能让每个待合并变更在更新后的基线上重新验证适合并发较高的仓库。不要把“PR 不超过固定行数”或“分支不超过固定天数”当硬规则。变更规模和同步频率取决于风险、团队节奏和模块边界更可靠的信号是评审是否能理解、测试是否覆盖、回滚是否可行。发生误合并时先停止继续扩散定位引入提交和受影响版本再用新的修复或回滚提交恢复。reflog是本地恢复工具不应作为共享主干的常规修复方案。把根因、遗漏的信号和新增检查记录下来下一次才能少靠记忆。