Git 与交付 核心 B · 官方指南或术语 平台: 通用

Merge Conflict

合并冲突

合并冲突是 Git 无法安全地自动合并互相冲突的改动,必须由人或工具决定最后要保留的内容。

看看怎样运作
也有人这样说 Merge Conflict合并冲突

看看怎样运作

原创情境示例合并冲突

另一个例子

两个分支用不同方式修改同一行价格代码。开发人员先理解双方目的,再整理成一致结果、加入暂存并运行测试;只删除冲突标记却不验证行为,不算解决冲突。

主要部分

  1. 01基础版本
  2. 02冲突变更
  3. 03解决后结果

什么时候用

当合并、变基、挑选应用或反向提交无法自动决定单一结果时,可以使用这个词。

什么时候不要用

不要把每个 Git 命令失败都叫作合并冲突,也不要在不了解代码用途时直接解决冲突。

代码里的名称

ours + base + theirs → resolved result

上线前要检查

发布前核对正确的代码仓库、分支、目标与代码差异。保留尚未发布的工作,并通过审查与自动检查(CI)。记录冲突、数据丢失风险、发布顺序、版本追踪、恢复与回到上一版的方法。

可以直接复制的需求

预期结果:用 合并冲突 (Merge Conflict) 安全交付或恢复变更,并留下可审核记录。 用户场景:两个分支用不同方式修改同一行价格代码。开发人员先理解双方目的,再整理成一致结果、加入暂存并运行测试;只删除冲突标记却不验证行为,不算解决冲突。 交付概念或操作:合并冲突 (Merge Conflict)。 适用理由:当合并、变基、挑选应用或反向提交无法自动决定单一结果时,可以使用这个词。 不应使用的情况:不要把每个 Git 命令失败都叫作合并冲突,也不要在不了解代码用途时直接解决冲突。 交付要求:指出代码仓库与目标。列出前置条件、变更内容、审查与自动检查(CI)、冲突和数据丢失风险、发布顺序,以及恢复或回到上一版的命令。 仓库防护:保留尚未发布的工作与可审核历史。没有明确备份时,不得执行破坏性操作。发布前核对准确的代码差异与远程仓库目标。 验收标准:预期的代码差异已审查,必要检查已通过。目标版本可追踪,失败恢复已演练,发布历史也可审核。 证据与限制(证据边界):它只代表该来源的官方说法。其他平台或团队可能有不同用法。 待确认:代码仓库与分支、协作状态、发布环境、批准负责人、受保护的检查,以及要恢复的版本。

检查这份需求

请 AI 编程助手检查当前如何使用 合并冲突 (Merge Conflict)。 定义:合并冲突是 Git 无法安全地自动合并互相冲突的改动,必须由人或工具决定最后要保留的内容。 生产环境检查:发布前核对正确的代码仓库、分支、目标与代码差异。保留尚未发布的工作,并通过审查与自动检查(CI)。记录冲突、数据丢失风险、发布顺序、版本追踪、恢复与回到上一版的方法。 修改程序前,先列出看到的证据、缺口、严重程度,以及最小且安全的修正。

B
这个术语有多正式?

官方指南或术语

列出的平台、框架、项目或专业组织,发布了这个术语的官方指南。

它只代表该来源的官方说法。其他平台或团队可能有不同用法。

适用范围
只包含来源有说明的内容:正式名称、定义、平台 API、实现、使用指南
文档状态
稳定
核验日期
2026-07-30

证据来源与适用范围

正式来源 + 术语参考资料 · Git · 稳定 git-merge 适用范围: 正式名称、定义、平台 API、实现、使用指南 本页用途: 直接术语参考 来源涵盖内容: 正式名称, 定义, 平台 API, 实现, 使用指南

自行复制

浏览器无法自动复制。请选择下方文字,再自行复制。