# 合并冲突解决 ## 目的当 git merge 或 rebase 发生冲突时，防止意外丢失预期更改（例如，功能 024 中引用的“docs/architecture.md”事件等文档回归）。此技能适用于可以提交更改的**任何代理**。 ## 核心原则冲突不是“选择我们的/他们的”问题——而是一个**意图和解**问题。在解决任何问题之前，您必须了解_两个_更改的意图。正确的解决方案取决于意图，而不取决于哪一方是“main”。通常，正确的答案是“保留两项更改的意图”，这可能需要进行组合或重组内容的手动编辑。有时，意图确实是矛盾的，无法自动解决。在这种情况下，请询问用户如何继续。 ## 硬性规则 ### 必须 * 先分析双方： * 确定各方试图实现的目标（意图）。 * 确定哪些部分是兼容的（可以合并）与矛盾的部分（需要做出决定）。 * 如果任一更改的意图不清楚，**询问用户问题，直到清楚为止**。不要猜测。 * 通过编辑冲突的文件来解决冲突（而不是盲目地选择一侧）。 * 解析后： * 验证是否存在任何冲突标记（`<<<<<<<`、`=======`、`>>>>>>>>`）。 * 验证 `scripts/git-status.sh` 是否显示未合并的路径。 * 验证已解析的内容保留了两个更改的意图（或在意图冲突时反映了明确的用户决定）。 ### 一定不能 * 盲目运行 `git checkout --ours ` / `git checkout --theirs ` 而不验证意图。 * 通过删除部分来“解决”，只是为了让冲突消失。 * 提交冲突解决方案而不检查结果差异。 ## 何时询问维护者如果冲突涉及**真实来源文档**（例如，`docs/spec.md`、`docs/architecture.md`），并且当前任务上下文中的正确内容并非明确，则您必须在提交之前**询问维护者要保留/合并哪个版本**。如果这两个改变意图是矛盾的（两者不能同时为真），你必须要求用户选择一个方向。不要试图“平均”或发明新的意图。 ## 所需分析（编辑前）在修改任何冲突文件之前，请使用此模板在聊天中生成显式分析：冲突分析改变意图： - <此更改试图实现的目标> 改变B意图： - <此更改试图实现的目标> 兼容性： - 兼容/部分兼容/矛盾 - 注释：<为什么> 提议的决议： - <如何保留这两项更改的意图> 开放性问题（必须回答后再继续）： - <问题1> 如果您无法自信地陈述这两项更改的意图，请停下来询问。 ## 澄清问题（当意图不明确时）如果您对更改的意图有疑问，请提出问题，直到您理解为止。有用的提示： *“合并后哪种行为/陈述应该是正确的？” *“此更改是重构（无行为更改）还是行为更改？” *“我们是否需要保留这两项更改，还是应该其中一个更改覆盖另一个更改？” *“如果两项更改都无法保留，那么哪一项更重要，为什么？” *“是否有规范/问题/公关描述来定义预期结果？” ## 工作流程（推荐） ### 0\.确认您确实处于冲突之中使用git确认冲突状态并列出冲突文件：脚本/git-status.sh git diff --name-only --diff-filter=U ### 1\.识别冲突的文件脚本/git-status.sh # 或（机器友好） git diff --name-only --diff-filter=U ### 2\.理解“我们的”与“他们的” * 在 **合并** 期间： *“我们的”=当前分支（您运行“git merge ...”的位置） *“他们的”=您要合并的分支 * 在 **rebase** 期间： *“我们的”/“他们的”语义不同——更喜欢阅读冲突标记并使用差异而不是依赖命名。 ### 3\.检查每一面都发生了什么变化对于每个冲突文件： # 查看冲突帅哥和周围环境 sed -n '1,200p' <文件> # 比较当前索引阶段（2=我们的，3=他们的）（如果可用） #（即使缺少阶段，这些命令也是安全的。） git show :2:<文件> 2>/dev/null | git show :2:<文件> 2>/dev/null |头-50 ||真实 git show :3:<文件> 2>/dev/null | git show :3:<文件> 2>/dev/null |头-50 ||真实检查时，明确确定意图： * 添加/删除/重命名了什么，为什么？ * 一方面是重构，另一方面是功能吗？如果是的话，解决方案通常需要两者兼而有之。 * 是否存在必须保持正确的不变量（文档准确性、API 行为、测试）？ ### 4\.有意识地解决冲突 * 编辑文件以组合双方的正确部分。 * 删除冲突标记。 * 保留所需的部分（尤其是文档）。 ### 5\.验证分辨率质量 # 回顾一下你要提交的内容脚本/git-diff.sh # 确保 git 看到冲突已解决脚本/git-status.sh 还要进行整个存储库范围的检查，确保不存在任何冲突标记。首选直接搜索文件的工具（不需要脚本），例如： * VS Code 搜索面板：搜索 `<<<<<<< `、`========` 和 `>>>>>>> ` * 如果您作为 Copilot 代理操作：使用工作区文本搜索工具搜索 `<<<<<<<`、`=======` 和 `>>>>>>>>` * 可选后备（终端）：`git grep -n '^<<<<<<< ' || true`（对其他标记重复） ### 6\.验证_意义_，而不仅仅是标记解决冲突后，根据文件类型验证正确性： * 文档更改： * 确保生成的文档能够体现这两个变更的意图，并且不会丢失相关信息。 * 确保文档不包含合并引入的矛盾语句。 * 检查常见的合并回归： * 删除或重复的标题/部分 * 重新引入过时的语句 * 一侧细节消失的部分合并 * 如果存在矛盾，请明确解决或询问用户哪种说法是正确的。 * 代码变更： * 确保所有测试均通过。 * 确保这两项更改的预期新功能或行为更改仍然有效。 * 如果更改区域存在测试，请先运行这些测试；然后根据需要扩大。 ### 7\.继续或结束 * 如果这是一个**合并**： git add <文件>... git 提交 * 如果这是一个 **rebase** ： git add <文件>... git rebase --继续 ## 提交消息要求（用于合并冲突解决）当您创建解决冲突的提交时，提交消息必须描述： * 哪些文件有冲突（高级） * 冲突是如何解决的（例如，“结合两个意图”、“保持 X 并调整 Y 来匹配”、“用户选择 A 而不是 B”） * 为什么此决议保留了预期的行为/文档模板：：解决合并冲突冲突： - <文件/组>: <冲突的内容> 分辨率： - <您如何保留这两项更改的意图或做出了什么决定> 为什么： - <为什么这是正确的> ## 注释 * 如果你遇到困难，更愿意寻求指导而不是猜测。错误的冲突解决方案可能会默默地发送损坏的文档。

合并冲突解决

包含技能