Git merge 冲突不是错误，而是 Git 无法自动判断保留哪边修改；需查看冲突标记、手动编辑后 git add 解决；rebase 中冲突须逐个解决并 git rebase --continue；可提前用日志和协作规范预警；merge 后漏改应建修复分支补救。
Git merge 时提示 conflict，文件被多个分支修改过
冲突不是错误，而是 Git 在告诉你：它无法自动判断该保留哪边的修改。常见于两个分支都改了 src/utils.js 的同一行，或一个分支删了函数、另一个分支改了函数体。
关键判断点：先看冲突标记位置（<<<<< HEAD 和 >>>>> feature/login 之间的内容），再决定是取 A、取 B、还是手动合并逻辑。
- 用
git status查看哪些文件有冲突，状态显示为both modified - 打开冲突文件，重点看中间三行分隔符：
<<<<< HEAD（当前分支改动）、=======（分界）、>>>>> branch-name（待合并分支改动） - 编辑时不要删掉分隔符，直到你手动解决完并运行
git add <file>，Git 才认为该冲突已处理
rebase 过程中遇到相同文件冲突，该怎么继续
rebase 把当前分支的提交“重放”到目标分支顶端，每放一个提交就可能触发一次冲突。和 merge 不同，它不生成合并提交，所以冲突必须逐个解决、逐个 git add、再 git rebase --continue。
容易踩的坑是：解决完一个冲突后直接 git commit —— 这会创建新提交，破坏 rebase 流程；正确做法是只 git add，然后继续 rebase。
- 每次冲突后，编辑文件 →
git add <file>→git rebase --continue - 如果卡住想放弃，用
git rebase --abort，会回到 rebase 前状态 - 若冲突涉及大量重复逻辑（比如两个分支都重构了同一个模块），建议先
git checkout <target-branch>，人工对比 diff 再决定怎么合并，而不是硬扛 rebase
如何提前发现多分支同时改同一文件的风险
靠人盯代码不现实，得用工具+流程降低概率。Git 本身不提供“谁在改什么”的实时通知，但可以通过日志和协作规范提前预警。
- 合并前跑
git log --oneline --left-right origin/main...HEAD，快速看当前分支有哪些提交，再对重点文件（如package.json或核心 service）单独查：git log -p --grep="utils" -- src/utils.js - 团队约定：修改公共配置或工具函数前，在协作平台（如钉钉/飞书）发个简短说明，避免“静默修改”
- CI 可加一步检查：用
git diff origin/main --name-only | grep -E '\.(js|ts|json)$' | xargs -r git blame -L1,+10快速定位近期谁碰过这些文件（适合中小型项目）
merge 后发现漏合部分修改，还能补救吗
能，但别直接改合并后的分支再 push —— 这会污染历史。正确做法是基于那次合并提交做修复提交，或用 git revert 回退再重来。
最稳妥的是新建修复分支，从那次 merge 提交拉出，补上遗漏的改动，再 merge 回去。这样既清晰又可追溯。
- 查上次 merge 提交 ID：
git log --oneline -n 5，找到形如abc1234 Merge branch 'feat/api'的记录 - 建修复分支：
git checkout -b fix-missed-changes abc1234 - 把漏掉的修改 cherry-pick 过来：
git cherry-pick <commit-hash>，或手动复制代码再git add+git commit - 推上去再 merge，比强行 amend 或 reset 更安全
多人协作时，一旦 merge 推送，所有后续开发都基于那个提交，随意改历史会让别人 fetch 后出现 diverged 分支，排查成本远高于多一次 clean merge。
