应使用git rebase替代git merge同步代码，避免生成中间合并提交；最终合并时用git merge --no-ff保留关键合并记录，从而保持历史线性且清晰可追溯。
git merge 后出现多余 merge 提交，历史变“分叉”了
这是最常见也最容易被忽略的问题：你解决完冲突后执行 git commit，Git 自动生成一条 Merge branch 'feature/login' 提交，分支图立刻从线性变成 Y 形。这不是错误，但会污染主干历史——尤其在 CI/CD 流水线依赖提交线性时，可能触发不必要的构建或阻断自动化回滚。
根本原因在于你用了 git merge 而非 git rebase。merge 本质是三方合并，必须记录一个新提交来承载两个父提交；rebase 则是把你的提交“重放”到目标分支顶端，保持单一线性。
- 如果还没 push，立刻用
git reset --hard HEAD~1撤掉 merge 提交（注意：仅限本地未推送） - 改用
git rebase develop（假设你在feature/login分支，想合入develop） - rebase 过程中遇到冲突，解决后用
git add . && git rebase --continue，不是git commit - 完成 rebase 后，
git switch develop && git merge --ff-only feature/login（确保 fast-forward 合并，不产生新提交）
冲突解决后 push 失败，提示 non-fast-forward
你本地解决了冲突、提交了 merge，但 git push origin main 报错：! [rejected] main -> main (non-fast-forward)。这说明远程 main 已被别人更新过，你的本地 main 已落后。
直接 git pull 会再触发一次 merge，让历史更乱；硬 push（--force）又可能覆盖他人提交。稳妥做法是同步远程最新状态，再重放你的变更：
- 先
git fetch origin拉取远程引用，不改动工作区 - 检查差异：
git log HEAD..origin/main --oneline看远程多了哪些提交 - 用
git rebase origin/main把你刚做的 merge 提交（及之前所有本地提交）重放到远程最新提交之后 - 如果有冲突，按提示解决 →
git add→git rebase --continue - 最后
git push origin main就能成功（前提是没其他人同时推）
误删冲突标记导致代码逻辑错乱，但已 commit 推送
冲突文件里残留的 或 <code>>>>>>> feature/x 被当成普通代码提交了，上线后直接报错。这种情况不能只改文件再 commit，因为错误内容已进入历史。
关键判断点：是否已推送到远程？是否已被他人拉取？
- 如果仅在本地，用
git reset --soft HEAD~1回退提交但保留修改，重新编辑文件、删干净标记、git add、git commit - 如果已 push 但无人拉取，可用
git push --force-with-lease origin main覆盖（比--force安全，会检查远程是否被他人更新） - 如果错误提交已被多人拉取，不要 force push。应新建修复提交：
git revert -m 1 HEAD（-m 1表示 revert 合并提交的第一个父提交，即你自己的分支变更），再修正逻辑并提交
IDE 自动解决冲突后，实际行为和预期不符
VS Code、IntelliJ 等工具提供“Accept Current Change”“Accept Incoming Change”快捷操作，但它们只处理标记块，不校验语义。比如你选了“Accept Incoming”，结果把别人删掉的关键初始化逻辑也一并接受了。
真正可靠的验证方式不是看 IDE 预览，而是：
- 解决冲突后，立即运行
git diff --staged，确认暂存区内容和你预期完全一致 - 对涉及业务逻辑的文件，手动执行单元测试或快速 smoke test（哪怕只是启动服务看日志）
- 如果项目有 pre-commit hook，确保它已启用；没有的话，至少加一行
git diff --staged | grep -q " 到脚本里
Git 不管你写的代码对不对，它只保证你提交的内容和你暂存的内容一致。冲突标记消失 ≠ 逻辑正确 —— 这一点，永远要靠人眼和测试兜底。
