变基合并是什么
平台的「变基合并」把评审请求里的提交逐个重放到目标分支上，不生成合并提交，得到线性历史。效果等价于在本地做好变基后快进推送。代价是提交哈希会被重写，而且平台在无法干净重放时会拒绝执行，要求先同步分支。
基本信息
| 效果 | 线性历史、无合并提交、提交哈希重写 |
|---|---|
| 前置条件 | 分支与目标分支之间须能干净重放 |
| 本地等效 | 先变基到目标分支，再快进推送 |
| 并列方式 | 与创建合并提交、压缩合并构成三种合并方式 |
典型使用场景
- 团队要求主干保持线性历史
- 每个提交都有独立意义、希望原样保留
- 提交信息已符合规范，不需要在合并时再压缩
- 本地已经完成变基与自查，希望平台直接重放
- 需要按提交粒度回溯某个改动的来源
本地等效操作
本地等效操作
git fetch origin # 先取最新的目标分支
git rebase origin/main # 在本地重放到最新主干
git push --force-with-lease origin feature/login # 安全强推同步后的分支
gh pr view 128 --json mergeable # 复核平台是否判定可以合并三种合并方式对照
| 方式 | 历史形态 | 代价 |
|---|---|---|
| 变基合并 | 线性、无合并提交 | 提交哈希与提交者信息可能变化 |
| 创建合并提交 | 保留分支拓扑 | 主干历史出现合并节点 |
| 压缩合并 | 主干上一条提交 | 原有提交粒度与信息被合并 |
平台执行变基时会用作者身份重放提交，提交者信息可能变成执行合并的人。对署名敏感的场景，建议在本地完成变基再推送。
重放之后原始提交的时间戳与签名都会随之变化，签名提交可能失去验证状态。需要保留验证状态的改动，应在本地变基并重新签名后再推送。
选择之前先确认团队要的是什么：线性历史便于阅读与回溯，分支拓扑便于看出一整块改动；两种诉求都合理，但要提前统一，避免各人各选一种方式。