Git合并冲突源于三路合并算法发现两个分支对同一区域互斥修改，无法安全裁决而暂停，需人工判断；其本质是Git严格比对公共祖先、当前分支（Ours）和待合并分支（Theirs）三个版本后，对双改区域拒绝自动覆盖。
Git合并冲突不是“系统出错”，而是它在严格遵守三路合并逻辑时，发现无法安全裁决——此时必须交由人来判断。
为什么git merge会卡在“CONFLICT (content)”
这不是随机报错，而是Git明确告诉你：它手上有三个版本（公共祖先、当前分支HEAD、待合并分支），但两个分支对同一行或相邻几行做了互斥修改。比如：
- 公共祖先中是
return user.is_active -
HEAD改成return user.is_active and user.email_verified - 待合并分支改成
return user.is_active and user.has_paid
Git能识别这两处都加了and，但无法推断业务逻辑上该选哪个条件——它不猜意图，只认文本差异。一旦检测到这种“双改同一区域”，就停在冲突状态，拒绝自动覆盖。
git pull失败时的冲突其实也是merge
git pull本质是git fetch + git merge（默认行为）。所以当你看到Automatic merge failed; fix conflicts and then commit the result，实际就是远程origin/main和你本地main分支在某个文件的相同位置有分歧。
- 常见诱因：你本地改了
config.py某行，同时同事也提交了对同一行的修改 - 容易忽略的点：即使你没动过那个文件，只要本地有未提交的暂存改动（
git add过但没commit），pull也可能因工作区脏而触发冲突提示 - 临时规避办法：
git stash再pull，但 stash 不解决根本分歧，只是把冲突推迟到git stash pop时
文件删除+修改引发的CONFLICT (modify/delete)
这类冲突比内容冲突更隐蔽，但发生频率不低。典型场景：
- 分支A里你删掉了
utils/legacy_helper.py - 分支B里同事还在这个文件里加了新函数
- 执行
git merge branch-b时，Git看到：祖先有这个文件 → A分支删了它 → B分支改了它 → 无法决定“该保留文件还是删除”
标记不会出现<<<<<< HEAD块，而是直接报错：CONFLICT (modify/delete): utils/legacy_helper.py in them and in us。这时必须手动决定：是恢复文件并合并修改？还是坚持删除并同步移除B分支里的引用？
变基（git rebase）中的冲突更容易被误判为“重复冲突”
rebase不是合并，而是把你的提交“重放”到目标分支最新提交之后。每次重放一个提交时，Git都会做一次三路比较。这意味着：
- 同一个文件可能在多个rebase步骤中反复冲突——因为每个提交都可能触碰相同区域
- 冲突内容显示的是“这个提交 vs 目标分支当前状态”，而不是“整个分支 vs 整个分支”，所以
<<<<<< HEAD里是你单个提交的改动，不是整个分支的累积改动 - 解决完一个冲突后，必须
git add <file>再git rebase --continue，漏掉git add会导致下一轮重放仍用旧状态，再次冲突
真正棘手的从来不是语法怎么写，而是当冲突块里混着业务逻辑变更、配置调整和空格换行改动时，你得一眼分清哪些是语义关键，哪些只是格式噪音——Git不帮你过滤，它只负责把所有差异原样摊开。
