如何安全地把分支合并到 main（master）
安全合并的标准流程：更新本地 main → 先把 main 合入功能分支解决冲突 → 跑测试 → 再合并回 main（此时通常快进）→ push。走 PR/MR 流程加评审和 CI 检查更稳。
安全合并的要点：不要直接在 main 上处理冲突。 标准流程是先把 main 合进功能分支（冲突在功能分支上解决、验证），再合回 main——如果主线未再前进，可快进到已验证提交，但快进只描述历史关系，不保证零功能风险。
推荐流程
# 1. 同步两边最新状态
git status # 先保存未提交改动，核实各自上游
git checkout main && git pull --ff-only
git checkout feature-x && git pull --ff-only
# 2. 把 main 合入功能分支（在这里解决冲突）
git merge main
# 解决冲突 → git add → git commit
# 3. 验证：跑测试、构建
npm test
# 4. 合回 main（此时通常是快进）
git checkout main
git merge --ff-only feature-x # 若 main 已推进则拒绝，重新集成与验证
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 的"半合并状态"下，出错或误提交会直接污染主线。把冲突解决挪到功能分支，还需保护分支和 CI 保证合入的确是最终验证提交，远端主线并发更新时必须重新检查。
Q：合并后发现有问题怎么撤？
未推送时先保存引用及工作区，再选择回退；已共享时按集成方式处理：merge commit 核实主线后用 revert -m，squash 用普通 revert，快进需明确要反向的提交范围。不能对所有合并方式都套 -m 1。
Q：merge 和 rebase + 快进怎么选？
merge 保留分支拓扑（能看出并行开发）；rebase 后快进得到线性历史。团队约定统一即可，混用才是问题。
