git自动合并成功仅表示语法无冲突，不保证语义正确；冲突时git拒绝猜测而交由人工决策；解决冲突需完整删除标记并用git status确认状态。
自动合并发生时，Git其实没做任何“智能判断”
自动合并（fast-forward 或 recursive 合并成功）不是 Git “理解了你的意图”，而是它发现两个分支的变更在逻辑上不重叠：要么目标分支是当前分支的直接后续（快进），要么 Git 能基于共同祖先（base commit）干净地三路合并所有改动。只要同一文件的同一行没被两个分支各自修改，Git 就能无声完成合并。
常见误判是认为“没报错 = 合并安全”。但注意：git merge 成功不代表语义正确——比如一个分支删了函数调用，另一个分支改了该函数内部逻辑，Git 会自动合并，但运行时可能崩溃。自动合并只保证语法层面无冲突，不校验行为一致性。
合并冲突的本质是“Git 拒绝猜答案”
当 Git 在同一个文件的同一区域（通常指同一段连续行）检测到两个分支都做了不可合并的修改，它就停止自动处理，并插入冲突标记：、<code>=======、>>>>>> feature/login。这不是 bug，是设计选择：Git 不试图“选一个更合理”的版本，而是把决策权交还给人。
典型触发场景包括：
- 两个分支都修改了
config.json中的"timeout"字段值 - 一个分支删除了
utils.js文件，另一个分支在同名文件里加了新函数 - 一个分支重命名了
src/api/目录，另一个分支在原路径下修改了其中某个文件
这些情况都会让 Git 无法构造出唯一的、无歧义的合并结果。
CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。
git status 和冲突文件里的标记才是真实信号源
别依赖终端最后一句 “Automatic merge failed” 来确认冲突——它可能被滚动刷掉，或被其他命令输出掩盖。最可靠的方式始终是：git status。处于冲突状态的文件会被列为 “both modified”，且状态显示为 “Unmerged paths”。
打开冲突文件后，注意三点：
到 <code>=======之间是当前分支（你checkout的那个）的修改-
=======到>>>>>> branch-name之间是待合并分支的修改 - 整个块必须被完整编辑并删除所有三个标记，否则
git add会持续报错
很多人卡在“删了一半标记就保存”，结果 git commit 失败并提示 “fatal: cannot do a partial commit during a merge”。这是最常被忽略的细节。
用 --ours 和 --theirs 快速覆盖时要分清上下文
git checkout --ours 和 git checkout --theirs 看似快捷，但它们的行为取决于当前操作类型：
- 在
git merge过程中：--ours指当前检出分支（HEAD），--theirs指被合并的分支 - 在
git rebase过程中：含义反转——--ours反而是被变基的原始分支，--theirs是目标分支（容易踩坑）
所以执行前务必确认当前是 merge 还是 rebase 状态，看 git status 输出里的提示词：“merging” 还是 “rebase in progress”。用错上下文会导致整块逻辑被意外覆盖，且难以回溯。
