Git冲突不是错误而是明确提示：两分支对同一代码处做了不可自动调和的修改，需人工决策；文件中出现
分歧报错不是 Git 报错，是它在明确告诉你：两个分支对同一处代码做了不可自动调和的修改——必须人工决策，不能跳过或硬覆盖。
看到 CONFLICT (content) 或文件里出现 就停手
这不是系统故障，是 Git 的正常暂停机制。此时 git status 会显示 Unmerged paths，所有冲突文件都卡在暂存区之外。常见错误包括：
- 直接
git reset --hard回退，结果丢掉当前分支的全部改动 - 删掉冲突文件再
git checkout，反而破坏工作区一致性 - 只改了内容但忘了
git add <file></file>，导致git commit失败并提示 “no changes added to commit”
正确做法是先运行 git status --porcelain | grep "^UU" 确认冲突总数，再用 git diff --name-only --diff-filter=U 列出全部冲突文件，快速区分哪些是 build.gradle、strings.xml 这类高风险文件，哪些是 yarn.lock 或 .editorconfig 这类可安全覆盖的辅助文件。
用 git mergetool 而不是手动删标记
纯靠眼睛扫 块，在 JSON/YAML/Python 中极易看串行、漏空行、误删缩进，尤其当一个文件有 5+ 处冲突时，效率和准确率断崖下跌。推荐配置：
-
git config --global merge.tool vscode（VS Code 自带三栏合并视图） - 或
git config --global merge.tool meld（开源免费，支持 Linux/macOS/Windows）
运行 git mergetool 后，它会按顺序打开每个冲突文件，显示三路内容：LOCAL（你当前分支）、BASE（共同祖先）、REMOTE（要合并进来的分支）。关键点在于：中间 MERGED 区才是你要编辑输出的地方；保存即自动 git add，不用再手动确认。如果只是改了个字符串常量，点 “Accept Remote” 比手敲快 10 秒且零出错。
git checkout --ours 和 git checkout --theirs 的坑在哪
这两个命令在 git merge 和 git rebase 中含义完全相反：
- 在
merge场景下：--ours指当前所在分支（HEAD），--theirs指你正在合并进来的那个分支 - 但在
rebase场景下：--ours反而指“被变基的原始分支”，--theirs指“目标基底分支”
所以不确定上下文时，别死记规则。更可靠的做法是直接看原始内容：git show :1:<file></file>（OURS）、git show :2:<file></file>（BASE）、git show :3:<file></file>（THEIRS）。仅当逻辑完全一边倒（比如对方只改注释，你改了核心方法体）才考虑批量用 --ours 或 --theirs，且执行后必须立刻 git add。
解决后必须验证逻辑一致性，不只是语法通过
很多人 git add + git commit 完就以为结束，结果上线后发现功能异常。这是因为合并没破坏语法，但破坏了语义——比如两个分支分别加了互斥的条件判断，合并后变成永远走某一分支；或两个 build.gradle 文件各自升级了不同版本的 OkHttp，合并后实际加载的是低版本，引发运行时 crash。
真正关键的收尾动作是：
- 对 Java/Kotlin 项目，跑
./gradlew compileDebugSources - 对前端项目，执行
npm run build或yarn build - 对 Python 项目，至少
python -m py_compile <file></file>过一遍 - 重点检查那些你人工比对过的业务核心文件，比如
UserServiceImpl.java、apiRoutes.ts
最易被忽略的一点：冲突解决完，git log --graph 应该清晰显示一条分叉再汇合的拓扑线。如果发现合并提交缺失、历史断层、或出现意外的“空合并”，说明流程中某个环节没走对——不是代码问题，是 Git 操作链断了。
