冲突需人工解决：删冲突标记、保留所需逻辑、git add 标记已解决、再 git commit；rebase 中用 git add + git rebase --continue；预防重在每日 pull、短周期分支、提前对齐共享文件修改。

Git merge 时提示 “CONFLICT (content)” 怎么办

冲突不是错误，而是 Git 在告诉你：同一文件的同一段代码，两个分支各自改了不同内容，它没法自动决定留哪个。这时候必须人工介入，否则 git merge 会卡住，git status 显示 unmerged paths。

关键动作是：先看冲突标记，再编辑文件删掉 、<code>=======、>>>>> 这三行及中间冗余内容，只保留你想要的逻辑，保存后 git add <file></file> 标记为已解决，最后 git commit（Git 会自动生成合并提交信息）。

• 别直接 git commit 而不 git add —— 这样提交的是“空合并”，冲突还在
• 别用编辑器“全部替换”删冲突标记 —— 可能误删你实际要保留的代码
• 如果改得太多拿不准，用 git checkout --ours <file></file> 或 git checkout --theirs <file></file> 快速取某一方版本（注意：这两个命令会丢弃另一方修改，慎用）

vscode 内置合并工具怎么用才不漏改

VS Code 检测到冲突文件会高亮显示“Accept Current Change / Accept Incoming Change / Accept Both Changes”按钮，但默认只处理当前选中块——容易只点了几处就以为全搞定了，其实文件底部还有隐藏冲突。

正确做法是：打开文件后，按 Ctrl+Shift+P（Win/Linux）或 Cmd+Shift+P（Mac），输入 “Merge Conflict: Show Conflicts” 并回车，它会列出所有冲突位置，逐个点开确认；或者用侧边栏的 “Merge Editor” 视图（需开启设置 "git.mergeEditor": true），左右对比更直观。

• “Accept Both Changes” 不是万能的——如果两边都新增了同名函数，合并后会出现重复定义
• 保存前务必运行一次本地测试，尤其涉及逻辑分支、配置项、API 参数顺序变更时
• 关闭 “Auto Save” 模式，防止未审阅完就自动写入

rebase 过程中遇到冲突和 merge 有啥区别

本质一样：都是同一段代码被不同分支修改。但触发时机和后续操作不同。merge 是把对方变更“整体合进来”，冲突只发生在最终合并提交那一刻；rebase 是把你的提交“重放”到目标分支最新版上，每遇到一个你改过的文件，就可能单独停住让你解决一次冲突。

也就是说，rebase 中的冲突更细粒度，也更容易迷失在自己的多个提交里。解决完一个冲突后，不能 git commit，而要用 git add <file></file> + git rebase --continue；如果想放弃整个 rebase，用 git rebase --abort 回退到之前状态。

• rebase 后的提交 SHA-1 全变了，别在已推送的分支上硬 rebase，除非你明确知道协作成员已同步并同意覆盖
• 用 git status 看到 “You are currently rebasing branch…” 提示时，说明还在 rebase 流程中，别直接切分支
• 如果冲突太多，不如中断 rebase（git rebase --abort），改用 merge + 后续清理提交历史

怎么提前降低冲突概率

冲突无法完全避免，但高频冲突往往暴露协作节奏或分支策略问题。最有效的预防不是靠工具，而是靠习惯。

• 每天上班第一件事：git pull origin main（或你所在主干分支），让本地始终贴近上游
• 功能分支生命周期控制在 1–3 天内，越长越容易偏离主干
• 对公共配置文件、类型定义（如 types.ts）、路由表这类“共享接口层”，改之前先在群组里对齐意图
• 启用 pre-commit hook 自动格式化（如 Prettier）和基础 lint，避免因空格、分号、引号风格差异引发虚假冲突

真正难处理的从来不是语法冲突，而是语义冲突：两个人都加了“导出 Excel”按钮，但一个走前端生成，一个调后端接口——这种得靠沟通，Git 帮不上忙。