冲突发生时应先停手，运行git status确认冲突文件，用git diff评估影响范围；若冲突复杂，可使用git checkout --ours/--theirs快速兜底、git mergetool可视化解决，或git merge --abort安全回滚。
冲突发生时先别动 git add 或 git commit
打包上线前看到 CONFLICT (content)，第一反应不是立刻删标记、不是狂按 git add .，而是停手。Git 此时处于“合并中”状态（git status 会显示 merging），任何未完成的 git add + git commit 都可能把错误逻辑直接固化进提交历史。
此时最安全的动作是：
- 运行
git status确认哪些文件真正冲突（注意看Unmerged paths区域） - 用
git diff快速扫一眼冲突块的上下文，判断影响范围——是单个配置项？还是核心鉴权函数？ - 如果冲突文件多于 3 个，或涉及
package.json、webpack.config.js这类关键构建文件，先暂停合并流程，别硬刚
紧急情况下用 --ours 或 --theirs 快速兜底
上线时间紧、冲突又集中在非业务逻辑文件（比如 CI 配置、.env.example、README.md），且你明确知道该保留哪边内容，就别手动编辑了。Git 提供了原子级覆盖命令：
-
git checkout --ours src/config/api.js：强制保留当前分支（如release/v2.3）的全部内容 -
git checkout --theirs package.json：采用待合并分支（如feature/login-sso）的package.json，跳过逐行比对 - 每执行一次，立刻跟
git add暂存，避免遗漏
⚠️ 注意：--ours 和 --theirs 是相对当前操作而言的——git merge feature-x 时，HEAD 是 ours，feature-x 是 theirs；但 git rebase main 时角色会反转。不确定就先 git status 看提示。
Git Changelog Generator
下载
使用约定式提交（Conventional Commits）从 Git 历史记录中生成结构化变更日志，支持多种格式、AI 增强型描述以及可自定义的范围……
用 git mergetool 启动 VS Code 快速可视化解决
当冲突在业务代码里（比如 src/services/user.ts 中一个接口返回结构被两边改出不同 shape），手动删标记容易漏掉逻辑耦合点。这时启动图形化工具比纯文本高效得多：
- 确保已配置：
git config --global merge.tool vscode（VS Code 用户）或git config --global merge.tool meld - 执行
git mergetool，它会自动打开三方对比视图：左侧是 base（共同祖先）、中间是当前分支（ours）、右侧是待合并分支（theirs） - VS Code 的 Merge Editor 里，点击每个冲突块下方的 “Accept Current Change” / “Accept Incoming Change” 按钮即可，不用手写代码
- 保存并关闭窗口后，Git 自动执行
git add，你只需最后git commit
实在搞不定就 git merge --abort 回滚到合并前
如果冲突文件超过 10 个、涉及多人协作模块、或你发现某处冲突修改明显违背近期需求文档（比如支付回调地址被回退到测试域名），别硬扛。上线前的稳定性优先级远高于“必须这次合并成功”：
- 确认当前是合并中状态（
git status输出含merging） - 直接执行
git merge --abort—— 它会瞬间还原工作区和暂存区到git merge命令执行前的状态 - 然后你可以：切回
feature分支单独验证、让同事复现冲突再 pair review、或改用git rebase重放提交（但 rebase 同样可能触发冲突，需评估时间）
真正容易被忽略的是：冲突标记本身不会污染远程仓库，但错误的 git commit 会。宁可多花 5 分钟 abort + 重新评估，也别为赶时间提交一个自己都没 fully 理解的合并结果。
