如何安全地把分支合并到 main（master）
安全合并的标准流程：更新本地 main → 先把 main 合入功能分支解决冲突 → 跑测试 → 再合并回 main（此时通常快进）→ push。走 PR/MR 流程加评审和 CI 检查更稳。
安全合并的要点：不要直接在 main 上处理冲突。 标准流程是先把 main 合进功能分支（冲突在功能分支上解决、验证），再合回 main——此时多半已是快进合并，零风险。
推荐流程
# 1. 同步两边最新状态
git checkout main && git pull
git checkout feature-x && git pull
# 2. 把 main 合入功能分支（在这里解决冲突）
git merge main
# 解决冲突 → git add → git commit
# 3. 验证：跑测试、构建
npm test
# 4. 合回 main（此时通常是快进）
git checkout main
git merge feature-x
git push
合并策略选项
git merge --no-ff feature-x # 强制产生合并提交（保留分支历史痕迹）
git merge --squash feature-x # 压成一个提交（功能分支历史杂乱时用）
--no-ff 适合保留"这是一个特性批次"的边界；--squash 适合 WIP 提交很多的分支。
团队级防护
- main 设保护分支：禁止直接 push，必须走 PR；
- PR 配 CI 检查：测试过了才允许合并；
- 至少一人 code review 通过。
常见问题（FAQ）
Q：直接在 main 上 merge 功能分支有什么风险？
冲突解决发生在 main 的"半合并状态"下，出错或误提交会直接污染主线。把冲突解决挪到功能分支，main 永远只接受验证过的内容。
Q：合并后发现有问题怎么撤？
未推送：git reset --hard origin/main；已推送：git revert -m 1 <合并提交>。
Q：merge 和 rebase + 快进怎么选？
merge 保留分支拓扑（能看出并行开发）；rebase 后快进得到线性历史。团队约定统一即可，混用才是问题。
