git冲突是暂停合并待人工决策的正常状态，需用git status定位、git diff分析差异，手动编辑或mergetool解决，解决后git add并提交，出错优先revert而非force push。
冲突不是 Git 出错了，而是它明确告诉你：这段代码两边都改了，得你来拍板。 直接删文件、硬 reset、盲目 git checkout --ours 都可能丢逻辑或埋雷——尤其在多人协作的主干分支上。
看到 CONFLICT (content) 和 标记时该做什么
这是 Git 暂停合并的正常状态，不是错误。它只发生在两个分支对同一段代码（哪怕只是同一行）做了不同修改，或一个分支改文件、另一个删文件时。
- 先运行
git status，看 “Unmerged paths” 下列出了哪些文件 - 打开任一冲突文件，你会看到三段式标记：
（当前分支内容）、<code>=======（分隔线）、>>>>>> branch-name（待合并分支内容） - 不要跳过验证：删掉这三行标记后，必须确保语法合法、变量名不冲突、函数调用不重复，最好本地跑一遍测试
git checkout --ours 和 git checkout --theirs 的真实行为
这两个命令在 merge 和 rebase 中含义相反，是高频踩坑点：
- 在
git merge过程中：--ours指当前所在分支（HEAD），--theirs指你正在合并进来的那个分支 - 但在
git rebase过程中：含义翻转——--ours反而指“被 rebase 的那个旧分支”，--theirs指“rebase 到的目标分支” - 它们只覆盖工作区和暂存区，不影响 HEAD；批量执行前务必确认上下文，否则可能把本该保留的改动全清掉
什么时候该用 git mergetool 而不是手修
纯靠眼睛扫 块容易漏行、串逻辑，尤其在缩进敏感（Python）、结构严格（JSON/YAML）或条件嵌套深的文件里。
- 配一个趁手工具：
git config --global merge.tool vscode（或meld、vimdiff） - 运行
git mergetool，它会拉起三方对比视图：LOCAL（当前分支）、BASE（共同祖先）、REMOTE（对方分支），中间是你要编辑的 MERGED 区域 - 保存退出后，工具自动帮你
git add，不用再一个个确认——5 个以上冲突文件时，省下的时间远超配置成本
合并提交后发现逻辑错了，别 push --force
强制推送会重写历史，破坏其他协作者的本地分支状态，尤其在 main 或 develop 这类共享分支上极其危险。
- 优先用
git revert -m 1 <merge-commit-hash></merge-commit-hash>，生成一个反向提交，干净可追溯 -
-m 1参数不能省：它告诉 Git 这是个合并提交，要撤销的是“从第一个父提交（即原目标分支）引入的所有变更” - 如果只是想退回到合并前状态且没人基于这次合并继续开发，可用
git merge --abort（仅限未提交阶段）或git reset --hard HEAD^（慎用，确保无未提交工作）
最常被忽略的一点：冲突解决后，git add 是必须步骤——Git 不会自动认为你删了标记就算完事；漏掉某个文件，git commit 会直接报错，而不是静默跳过。
