必须逐个有序合并分支，不能一次性合并多个源分支；先切到main并拉取最新，再依次git merge各分支，每次冲突须用git status识别、手动编辑解决、git add标记、git commit提交，并验证通过后再继续。
合并多个分支到主干，关键不是“一次全塞进去”，而是逐个、有序、可验证地合入。Git 本身不支持一次性合并多个源分支（如 git merge feat-a feat-b feat-c 是非法命令），强行用脚本批量操作反而容易跳过冲突检查、掩盖问题、污染历史。真正能确保不丢失任何冲突代码的做法，是把每个分支当作独立变更单元，分别执行标准合并流程，并在每一步主动暴露和处理冲突。
必须逐个合并，不能跳过中间状态
想把 feat/login、feat/payment、hotfix/timeout 都合进 main，就得按顺序来：
- 先切到
main，拉最新远端：git checkout main && git pull origin main - 合并第一个分支：
git merge feat/login→ 若有冲突，手动解决、git add、git commit - 确认本地
main已包含该分支全部逻辑（编译+基础测试） - 再拉一次远端（防止别人刚推了新提交）：
git pull origin main - 合并第二个分支：
git merge feat/payment→ 再次面对冲突，同样流程解决 - 重复直到所有分支合完
冲突不是障碍，而是必经的校验点
冲突文件本身不会“丢失”，Git 会明确标记出来。只要不跳过下面三步，就不可能漏掉：
-
用
git status看 “Unmerged paths” —— 这些就是冲突文件，列表清晰可见 -
打开文件，删掉
、<code>=======、>>>>>> feat/x标记 —— 不是删代码，是删标记；保留哪边、怎么融合，由你判断 -
改完后必须
git add <file></file>—— 这步没做，Git 仍认为它处于冲突状态，git commit会直接报错
避免“伪干净”：合并前清空本地脏修改
如果 main 上有未提交的改动，合并时 Git 可能把你的临时修改和分支变更混在一起，导致冲突位置错乱、甚至覆盖他人代码：
- 执行
git checkout main后，立刻运行git status - 若显示 “modified” 或 “untracked files”，别忽略 —— 用
git stash暂存（推荐），或确认无用后git reset --hard && git clean -fd - 再次
git status输出 “nothing to commit, working tree clean” 才算真正干净
合并后别急着 push，先验证结果
合完一个分支，不代表逻辑就对了。尤其多个分支叠加后，行为可能互相影响：
- 运行本地构建或关键测试用例，确认功能没被意外破坏
- 用
git log --oneline -n 10看最后几条提交，确认合并提交（含 “Merge branch 'feat/x'”）已存在 - 用
git diff origin/main查看即将推送的内容，核对是否只包含预期变更 - 确认无误后再
git push origin main
本质上，Git 的冲突机制就是为了防止静默覆盖。只要你按流程走、不跳步骤、不靠记忆判断状态，每次冲突都会被强制暴露出来，也就根本不存在“丢失”的可能。
