Skip to content

GitHub PR

Jump to bottom
未竟 edited this page Jun 3, 2026 · 7 revisions

GitHub Pull Request 合并策略区别说明

GitHub 在 Pull Request（PR）设置中提供了三种主要的合并方式：合并提交（Merge Commit）、压缩合并（Squash Merge） 和 变基合并（Rebase Merge）。你可以根据项目需求选择启用其中一种或多种方式。

重要提示：至少必须启用一种合并方式。如果受保护分支启用了“线性历史”要求，则必须启用“压缩合并”或“变基合并”。

1. 允许合并提交（Allow merge commits）✅

行为说明

  • 将源分支（head branch）的所有提交通过一个合并提交（merge commit） 添加到目标分支（base branch）。
  • 保留源分支的完整提交历史，并在目标分支创建一个新的合并提交来记录这次合并。

历史记录特点

  • 非线性历史：会产生分叉的历史图，清晰显示“什么时候合并了什么功能”。
  • 每个 PR 都会在目标分支留下一个明显的合并提交节点。

优点

  • 完整保留开发过程和上下文，便于追溯“这个功能是什么时候合并的”。
  • 适合团队需要严格审计合并历史、或使用 Git Flow 等工作流的场景。
  • 回滚整个 PR 非常方便（直接回滚那个 merge commit）。

缺点

  • 历史记录相对“脏”，有大量合并提交节点。
  • 如果频繁合并小 PR，历史会变得很长且难以阅读。

适用场景

  • 大型项目、需要强审计的项目。
  • 团队习惯使用 merge commit 来标记发布节点。

2. 允许压缩合并（Allow squash merging）✅

行为说明

  • 将源分支的所有提交压缩成一个单一的提交，然后合并到目标分支。
  • 源分支的多个 commit 会被“压扁”成 base branch 的一个新 commit。

历史记录特点

  • 线性历史：目标分支保持干净的线性提交记录。
  • PR 内部的详细提交历史在合并后不可见（除非你查看 PR 本身）。

优点

  • 保持主分支（main/master）历史非常整洁、易读。
  • 特别适合小型功能开发、bug 修复、文档修改等“一个 PR 对应一个逻辑变更”的场景。
  • 减少不必要的合并提交噪音。

缺点

  • 丢失 PR 内部的提交粒度：如果之后需要回滚 PR 中的某个具体 commit，会比较困难（只能回滚整个 squash 后的 commit）。
  • 不适合需要保留详细开发过程的场景。

适用场景

  • 大多数现代开源项目和团队（推荐默认开启）。
  • 追求“主分支历史干净” 的项目。
  • CI/CD 流程中希望每个 PR 对应一个清晰的 commit。

3. 允许变基合并（Allow rebase merging）✅

行为说明

  • 将源分支的每个提交逐个变基（rebase） 到目标分支的最新提交之上。
  • 相当于把源分支的提交“重放”到 base branch 的顶部，每个 commit 都会生成新的 commit hash。

历史记录特点

  • 完全线性历史：没有 merge commit，历史像所有工作都是按顺序依次完成的。
  • 每个 PR 的提交都会以独立 commit 的形式出现在目标分支上。

优点

  • 历史记录极其干净、线性，阅读体验最佳。
  • 保留了 PR 内部的每个 commit 的独立性（比 squash 更好）。
  • 适合需要保持“这个功能是由这些小提交组成的”场景。

缺点

  • 改变了 commit hash：如果源分支已经 push 给别人或被其他人基于它开发，rebase 后会导致冲突（需要 force push）。
  • 不适合已共享给其他人的分支（违反 Git “不要 rebase 已公开分支” 的原则）。
  • 解决冲突时可能比 merge 更麻烦。

适用场景

  • 个人项目或小团队，开发者严格遵守 “rebase before push” 流程。
  • 追求极致线性历史的团队。
  • 与 squash 结合使用时非常强大（很多项目同时开启 squash 和 rebase）。

其他相关设置说明

始终建议更新 Pull Request 分支

  • 作用：当目标分支有新提交时，自动在 PR 页面提示用户“更新分支”。
  • 建议：建议开启，尤其是多人协作的项目，能减少“这个 PR 已经过时了”的情况。

允许自动合并（Allow auto-merge）

  • 作用：当所有必选 review 和状态检查通过后，自动合并 PR。
  • 适用场景：小型团队、自动化程度高的项目、依赖机器人 review 的场景。
    • 工作流程： 1. 提交 PR → 2. 等待 Review 和 CI 检查 → 3. 全部通过 → 自动合并
  • 注意：需要配合分支保护规则使用。
    • 常见的分支保护规则包括：
      • 必须有至少 1 个（或更多）人 Code Review 通过
      • 必须通过所有的 CI 检查（测试、构建、代码规范、覆盖率等全部绿灯）
      • 禁止直接 push 到 main（必须走 PR）
      • 要求提交有签名、历史必须是线性的等

自动删除源分支（Automatically delete head branches）

  • 作用：PR 合并成功后，自动删除源分支（feature branch）。大部分 PR 都是在同一个仓库里建分支，开启这个选项后，PR 合并成功就能自动清理掉 feature 分支，仓库会保持很干净。
  • 优点：保持仓库整洁，减少无效分支堆积。
  • 注意：删除后仍可恢复（GitHub 保留 30 天）。

总结对比表

特性 合并提交 (Merge Commit) 压缩合并 (Squash) 变基合并 (Rebase)
历史是否线性 否（有分叉） 是 是
是否保留 PR 内部提交 完整保留 全部压缩成一个 保留每个 commit
是否产生 merge commit 是 否 否
适合回滚单个 commit 困难 很困难 容易
适合大型团队/审计 优秀 良好 一般（需规范流程）
保持主分支整洁 一般 优秀 优秀
推荐开启场景 需要完整合并历史 大多数现代项目 追求极致线性历史

实际建议（2026 年主流做法）

  1. 大多数项目推荐：同时开启 Squash Merge + Rebase Merge，关闭 Merge Commit（除非有特殊需求）。
  2. 需要严格审计历史的项目：开启 Merge Commit。
  3. 个人/小团队追求干净历史：只开启 Rebase Merge 或 Squash Merge。
  4. 强烈建议开启：
    • 自动删除源分支
    • 始终建议更新 PR 分支
    • 配合分支保护规则 + 状态检查使用

参考来源：GitHub 官方 Pull Request 合并设置页面（2026 年 6 月界面）

如需针对具体项目定制合并策略，欢迎提供更多项目背景，我可以给出更针对性的建议！

Clone this wiki locally