name: resolving-merge-conflicts description: "需要解决正在进行的 Git 合并或变基冲突时使用。"
第 23 课 / resolving-merge-conflicts
按两边的意图解决代码冲突
冲突标记只显示文本位置；正确合并需要理解每边为什么改。
还不清楚 Skill、Agent、安装和调用？先读 从零开始的6节入门课。
在关系图中查看 resolving-merge-conflicts 与其他技能的关联 →
一 / 读这一课之前
先把必要的概念讲清楚
合并冲突表明两条修改路径在某处无法自动结合。解决它需要理解双方要保留的行为，不能只把冲突标记删除，或一律保留自己的版本。
下面是老师补充的入门说明；原作者的要求保留在中英对照正文中。所有例子均为帮助理解而构造的教学情境。
Git、commit、branch｜版本与分支
Git 记录项目随时间的变化；commit 是一次有标识的修改记录；branch 是一条可继续发展的工作线。你可在功能分支试做收藏能力，验证后再合入主分支。保存了文件不等于已提交，提交了也不等于已推到服务器或已上线。
diff / merge-base｜变更差异与共同起点
diff 展示两个版本之间哪些内容增删；merge-base 是两条分支共同的祖先。评审功能分支时从共同起点看差异，有助于聚焦这条分支引入的变化。比较基准错误，可能把别人早已做的修改也当成此次工作。
PR / pull request｜合并评审请求
把一条分支的修改交给他人检查，并请求合入目标分支的协作对象。PR 通常包含改了什么、为何修改、验证结果和代码差异。草稿 PR 表示还在做；“可评审”表示可以检查；合并完成也不自动等于部署完成。
CI｜持续集成检查
把修改提交到共享流程时，自动运行测试、类型检查等约定检查，尽早发现集成问题。绿灯表示配置的检查通过，不代表所有需求都正确；红灯也可能由环境故障导致，应看具体证据。需要先检查“配置了什么”，才能解释绿灯的意义。
二 / 中英全文对照与精讲
读原文，理解每一步为什么这样做
左右内容按小节对应；窄屏先中文、后英文。两种语言均完整展示，对应讲解紧接在小节之后。译文传达原文要求；老师讲解补充概念、原因、例子与适用边界。
中文译文English · 英文原文
name: resolving-merge-conflicts description: "Use when you need to resolve an in-progress git merge/rebase conflict."
- 先查看当前合并或变基的状态，阅读 Git 历史和发生冲突的文件，弄清操作进行到了哪里。
- 找到每处冲突背后的原始依据。阅读提交说明、相关 PR 和最初的需求工单，深入理解双方为什么修改、原本希望实现什么。
- 逐个解决冲突片段。能够兼顾时保留双方意图；确实不兼容时，采用符合本次合并既定目标的方案，并说明取舍。不要发明新的行为。作者要求继续解决冲突，而不是执行
--abort中止。 - 找出项目已有的自动化检查并运行，通常先类型检查，再测试，再格式检查。修复本次合并导致的问题。
- 完成合并或变基。将改动加入暂存区并提交；变基时继续后续处理，直到全部提交都已完成变基。
-
See the current state of the merge/rebase. Check git history, and the conflicting files.
-
Find the primary sources for each conflict. Understand deeply why each change was made, and what the original intent was. Read the commit messages, check the PRs, check original issues/tickets.
-
Resolve each hunk. Preserve both intents where possible. Where incompatible, pick the one matching the merge's stated goal and note the trade-off. Do not invent new behaviour. Always resolve; never
--abort. -
Discover the project's automated checks and run them, typically typecheck, then tests, then format. Fix anything the merge broke.
-
Finish the merge/rebase. Stage everything and commit. If rebasing, continue the rebase process until all commits are rebased.
老师讲解 · 对应上方原文 · 含教学举例
双方意图比哪一段代码看起来更新更重要
假设一条分支给收藏增加权限检查，另一条分支给相同函数增加去重。机械选择一方，可能丢掉另一项必要行为。提交说明、原始工单和 PR 能解释为什么改。
冲突可以是同一行文字，也可以是合并工具没报错的逻辑不兼容。例如两人分别更改响应字段和页面读取逻辑，自动合并成功但运行失败。因此要先了解整体合并目标。
你无需逐行写代码也能审查解决方案：问它保留了双方哪项意图，舍弃了什么，为什么。
解决标记后，要重新验证组合起来的程序
类型检查、测试和格式检查提供不同证据。类型检查能发现部分参数不匹配，测试验证写明的行为，格式化保持约定；任何一种都不是全部。
merge 与 rebase 的完成步骤不同。rebase 可能逐个重放提交，多次遇到冲突，需要继续直到全部结束。只解决第一处冲突就说完成，会留下未结束的仓库状态。
原文“绝不 abort”是作者很强的执行偏好，不是通用 Git 规则。目标不明确或无权作取舍时，不能据此编造新行为。教学上应理解它鼓励完成已知目标，但真实操作仍需明确权限和正确范围。
冲突处理要保留意图，不是随便选左边或右边
假设一条分支给收藏按钮加“未登录先登录”，另一条分支加“保存中不允许重复点击”。它们修改同几行，Git 可能无法自动组合。
只保留任意一边，都可能丢掉另一项必要行为。应回到原工单理解目标，让结果同时满足登录检查与防重复操作，再验证这些场景。
Git 能发现文字位置冲突，不能替你判断业务意图。原文“不要中止”是此技能的执行偏好，不是 Git 的普遍规则；若合并目标本身错误，仍需澄清。收尾也要辨认本次改动，避免把用户无关的工作一起提交。
三 / 你问我答
先作答，再看参考思路
Q1 · 理解
用自己的话说明：它解决什么问题，完成后会留下什么？
请各用一句话回答。若它只做规划或解释，不要把“已开发”“已部署”写成产物。
Q2 · 判断
删除冲突标记且程序能编译，为什么仍可能合并错误？
我已思考，查看参考思路
文本已一致不代表语义正确，可能丢失一侧行为。应回到双方需求并验证对应场景。
Q3 · 追问
原文中哪条要求在你的环境下可能不成立？
说出具体一句及其前提，例如工具不可用、资料缺失、已有项目约定冲突，或它只是作者偏好。把你的答案带回课堂，我们据此继续讨论。
课堂回传格式：第 23 课 / 我的理解 / Q2 回答 / 仍不理解的原句。这里是阅读教材；实时问答在我们的对话中进行。
四 / 应用场景讨论
把方法放进一个具体情境
教学案例：一边增加文章来源字段，另一边重命名文章对象。选择“全保留我的版本”可能丢掉来源功能。应理解目标后同时适配新名称与来源字段。
边界与容易误读的地方
通过语法检查不能证明两边需求都保留。原文中的 stage everything 在混合工作区尤其需要结合任务边界，不能把他人的未完成修改一起带入。
讨论后再实践：先判断上述情境是否适用，再选择真实任务。现在无需安装、运行命令或修改现有项目。