git合并冲突是git明确提示需人工决策，非系统错误；看到conflict提示后应先git status查看冲突文件，手动编辑删除标记并保留所需内容，再git add标记解决，最后git commit完成合并。

Git 合并冲突不是 Git 出错了，而是它明确告诉你：「这两段修改我没法自动选一个，得你来定」。只要理解冲突标记含义、操作顺序和关键命令边界，90% 的冲突 5 分钟内就能干净解决。

看到 CONFLICT (content) 提示后该做什么

执行 git merge 或 git pull 后出现这行，说明 Git 已停在合并中途，工作区文件已被写入冲突标记，但尚未提交。此时不能直接 git commit，也不能强行 git push。

• 先运行 git status，它会列出所有冲突文件（状态显示为 both modified）
• 打开任一冲突文件，你会看到类似这样的三段结构：

  >>>>> feature/login

• 手动删掉 、<code>=======、>>>>>> 这三行，只保留你最终需要的逻辑——可以全留 A、全留 B、或拼接两者
• 保存文件，然后 git add 标记为已解决（不是 git commit）

用 git mergetool 替代手敲标记

当冲突文件多、或涉及复杂逻辑（比如 JSON 配置、HTML 模板嵌套），纯文本编辑容易漏删标记或误删代码。这时图形化工具更稳。

Digital Twin Discharge Drafter

用于撰写患者出院小结、制定个性化出院指导、模拟出院后结局、降低再入院率

下载

• 确保已配置好工具，例如：git config --global merge.tool vimdiff（Linux/macOS）或 git config --global merge.tool bc3（Windows + Beyond Compare）
• 运行 git mergetool，它会逐个打开冲突文件，在左右/上下/基线三栏中高亮差异
• 在工具里选择「Accept Current Change」「Accept Incoming Change」或手动编辑，保存即完成该文件解决
• 退出工具后，Git 自动执行 git add，你只需最后 git commit
• 注意：git mergetool 不会跳过已解决的文件，如果中途退出，下次再运行会从第一个未解决的继续

git merge --abort 是安全撤退键

改到一半发现逻辑全乱了，或者误删了不该删的代码？别硬撑。Git 允许你在任何阶段干净回退。

• 只要还没运行 git commit，就仍处于 MERGING 状态，此时 git merge --abort 会立即还原到 merge 前的 HEAD，所有冲突标记、未暂存修改全部清除
• 它等价于撤销整个 merge 操作，但不会动你本地其他分支或已提交的历史
• 常见误操作：先 git add 再想 abort → 失败，因为 git merge --abort 要求暂存区为空；此时得先 git reset 再 abort
• abort 后可重新 git pull origin main 拉最新主干，再试 merge，或换思路 rebase

为什么 git checkout --ours 和 --theirs 容易翻车

这两个参数看似能一键取舍，但语义极易被误解——它们的「ours/theirs」取决于你当前在哪分支执行 merge，而不是你直觉里的「我的/别人的」。

• 假设你在 main 分支上运行 git merge feature：  • git checkout --ours <file></file> → 保留 main 分支版本（即「当前分支」）  • git checkout --theirs <file></file> → 保留 feature 分支版本（即「传入分支」）
• 但如果反过来，在 feature 上 merge main，含义就对调了
• 更大的坑：这些命令只作用于工作区，不会自动 git add；且对有多个祖先的合并（如 octopus merge）行为不可控
• 建议仅用于确认无逻辑差异的纯覆盖场景（如更新第三方库 lock 文件），否则优先手动编辑或用 mergetool

真正卡住人的往往不是冲突本身，而是混淆了「当前分支」「传入分支」「已暂存」「未暂存」这几个状态边界。每次操作前看一眼 git status，比死记命令管用得多。