平台的合并方式是什么
GitHub 与 GitLab 在合并 PR/MR 时都提供多种按钮：保留合并提交、压缩为单条提交（squash）、以及变基后快进（rebase）。它们会以不同方式把分支内容写进主干，直接影响事后能否按功能回滚、历史是否线性。仓库允许使用哪些方式属于管理员设置，团队需要事先统一约定，否则同一仓库会同时出现三种历史风格，追溯与回滚都会变难。
基本信息
| 常见方式 | Merge commit / Squash and merge / Rebase and merge |
|---|---|
| 决定权 | 仓库管理员的合并方式设置 |
| 影响面 | 主干历史形态与回滚粒度 |
| 查看位置 | GitHub 仓库设置或 GitLab 项目的合并方法配置 |
| 平台 | GitHub 与 GitLab |
典型使用场景
- 需要保留每个功能一个回滚点时选合并提交
- 小改动想保持主干线性时用压缩合并
- 分支内提交已逐条整理干净时用变基合并
- 按发布节奏选择策略：频繁发版更倾向线性历史
- 排查主干历史风格混乱，统一仓库的可用方式
- 给新人说明何时选哪种按钮，减少随意点击
三种方式对照
| 方式 | 历史形态 | 适用 |
|---|---|---|
| Merge commit | 保留分支与合并点 | 需要完整拓扑与回滚点 |
| Squash and merge | 压成单条提交 | 小改动、要求整洁线性史 |
| Rebase and merge | 线性、无合并点 | 逐提交整理过的分支 |
选择建议
选择建议
需要独立回滚点：Merge commit
要求主干线性：Rebase and merge（分支已整理）
小改动或零散提交：Squash and merge
# 选定后建议在仓库设置里只保留一种或两种，避免混用压缩合并会把 PR 标题作为主干提交信息，因此标题质量直接影响主干历史；这也解释了为什么提交与 PR 规范在这里格外重要。
变基合并要求分支内提交已经整理过，否则会把这些临时提交原样写进主干，事后清理成本更高。