PR 合并策略与平台配置

很多团队会讨论“我们应该用 squash 还是 rebase merge”，但真正落地时，平台配置和口头约定常常并不一致。
所以这页关注的不是命令偏好，而是团队想要的主线历史，是否真的被平台设置支撑了。

先决定

主线历史形态共享历史边界review 方式

→policy → settings → enforcement

平台应体现

允许的 merge method保护规则统一默认值

平台配置如果和团队规范不一致，最终执行的一定是平台，不是文档。

为什么要把策略和平台配置放在一起看

因为团队真正执行的，并不是讨论会上说的规则，而是平台最终允许的入口。

如果团队口头说：

• “我们只用 squash”
• “主线不保留 merge commit”
• “PR 必须过完整检查”

但平台同时还开着所有 merge method，且保护规则很松，那最终落地的就不会是口头规范。

建议先统一 3 个问题

1. 主线想保留 PR 粒度还是提交粒度

• 如果希望每个 PR 落成一个清楚的主线节点，squash merge 常更合适
• 如果希望保留原始提交粒度并尽量线性，rebase merge 更接近这个目标
• 如果希望明确保留整合节点和分叉关系，merge commit 更合适

2. 已共享历史是否允许更强的重写

如果团队对共享历史非常保守，就要避免把设置开得过宽。

3. 平台默认到底开放哪些入口

不要让“所有方式都开着”成为默认状态。
那等于把每个 PR 的历史表达交给个人偏好决定。

一个更稳的决策框架

倾向 squash merge

适合：

• 主线想最短
• 每个 PR 对应一个提交
• 团队希望减少主线噪声

倾向 rebase merge

适合：

• 想保留原提交粒度
• 主线尽量保持线性
• 团队对提交质量要求较高

倾向 merge commit

适合：

• 希望明确保留整合节点
• 想看清分支如何汇入主线
• 团队接受主线更“图状”而不是极致线性

真正危险的不是选错一次，而是团队没有统一默认值，导致每个 PR 都按个人偏好落地。

平台配置应该对应什么

建议把这些一起对齐：

• 只打开团队认可的 merge methods
• 明确分支保护规则
• 明确谁能 bypass，谁不能
• 如果平台支持自动删除分支、merge queue，也一并统一
• 检查 required checks 是否和团队约定一致

为什么“平台默认值”特别值得警惕

默认值往往只是平台产品的通用选择，不是你们团队的最佳实践。
如果不主动收紧配置，就会发生这类问题：

• 文档写的是 squash，实际有人一直 merge commit
• 说主线必须保护，实际管理员随时能绕过
• 说必须 review，结果平台入口允许过宽

!平台入口比规范文档更有执行力

只要平台入口还开着，团队里就一定会有人走那条路。真正想统一 PR 落地方式，必须让平台设置和规范站在同一边。

常见误区

以为平台默认值就是团队最佳实践

平台默认值通常只是“通用可用”，不是“最适合你们”。

口头说用 squash，但平台实际三种都开着

这样最后历史风格一定会漂。

只讨论命令，不讨论平台上的真实入口

PR 合并方式最终是平台产品行为，而不只是 Git 命令语义。

→给团队做一次 PR 合并策略自查

1. 你们想保留的是 PR 粒度、提交粒度，还是整合节点？
2. 平台当前实际开放了哪些 merge methods？
3. 分支保护和 required checks 是否真的和团队规范一致？
4. 管理员绕过、自动删分支、merge queue 是否有统一规则？

接下来建议继续学什么

1. Squash vs rebase merge
2. Merge queue workflow
3. Sync before review