git merge main到功能分支冲突的本质是三路合并时主干与功能分支在相同文件相同位置存在互斥修改，需按业务逻辑协调保留内容而非简单覆盖。
主干分支（如 main）向功能分支（如 feature/login）合并时出现冲突，本质是 Git 在尝试把主干的最新变更“应用到”功能分支上，但两者在相同文件、相同位置有互斥修改。这种情况比功能分支合入主干更少见，但一旦发生，处理逻辑完全一致——不是“谁覆盖谁”，而是“保留哪些变更、如何协调逻辑”。
为什么 git merge main 到功能分支会冲突？
常见诱因包括：
- 你在
feature/login分支改了src/api/auth.js的登录接口逻辑，而main上刚合入另一组人对同一文件中错误码统一处理的修改； -
main分支更新了package.json里的依赖版本，而你的功能分支也手动改过同一行（比如加了个devDependency），Git 无法判断该保留哪个顺序或组合； - 你本地功能分支长期未同步
main，导致共同祖先（merge base）过于陈旧，Git 的三路合并算法找不到稳定锚点。
关键点：冲突标记中的 <<<<<< HEAD 指的是当前所在分支（即你的 feature/login），>>>>>> main 才是主干带过来的变更——别看反了。
git merge main 冲突后必须做的三件事
不要直接 git commit 或 git push，先确保状态可控：
- 用
git status确认哪些文件标为Unmerged，只处理这些文件； - 打开冲突文件，删掉全部
<<<<<<、=======、>>>>>>标记，按业务逻辑保留或融合两段代码——例如把主干新增的错误码映射表和你功能分支里新加的 token 刷新逻辑合并进同一个switch块； - 保存后，对每个已解决的文件执行
git add <file>，而不是git add .（避免误加未处理完的冲突文件）。
完成所有 git add 后，再运行 git commit。此时 Git 会自动生成类似 Merge branch 'main' into feature/login 的提交信息，无需修改。
用 git mergetool 快速定位三方内容
命令行里手动删标记容易漏行，尤其当冲突嵌套在函数体内部时。启用可视化工具能直接看到三方版本：
- 先配置好工具：比如全局设
git config --global merge.tool vscode（VS Code 自带三方合并界面），或git config --global merge.tool kdiff3； - 运行
git mergetool，它会逐个打开冲突文件，左侧是你的功能分支变更（CURRENT），右侧是main的变更（INCOMING），中间是共同祖先（BASE）——这个BASE是关键，帮你判断哪边改得更合理； - 注意：某些编辑器（如 VS Code）在保存合并结果后不会自动
git add，仍需手动执行。
如果团队多人共用一个功能分支，合并 main 后务必立刻 git push 推送这次合并提交，否则下一个人拉取时又会触发重复冲突。
长期规避这类冲突的两个硬动作
靠每次手动解决是下策。真正省事的做法是：
- 每周固定时间在功能分支上执行一次
git merge main（哪怕没冲突），让共同祖先保持新鲜——Git 的三路合并能力高度依赖这个 base 的时效性； - 在功能分支开发早期就明确“哪些文件属于主干强管控范围”，比如
tsconfig.json、jest.config.js，约定这类文件的修改必须先提 PR 到main，再由功能分支主动拉取，而非自行改动。
最常被忽略的一点：功能分支命名别用 feat/xxx 这种模糊前缀，换成带日期或迭代号的，比如 feat/login-2026q3。这样当你在 10 月回看这个分支为何要合并 main，一眼就能关联到当时正在对齐的季度发布计划，而不是对着一堆 feat/xxx 发呆。
