压缩合并的提交信息
平台执行压缩合并时，默认用评审请求的标题作为主干提交的标题，正文一般取评审描述或各条提交的摘要，并可在合并框中编辑。以压缩合并为主的仓库，评审标题直接决定主干历史是否可读、可检索。
基本信息
| GitHub | 默认取 PR 标题与正文，可在合并框的默认信息中编辑 |
|---|---|
| GitLab | 启用压缩提交后默认拼接各条提交信息，合并页面仍可编辑 |
| 标题来源 | 评审请求的标题，压缩后成为主干上唯一的提交标题 |
| 建议写法 | 标题遵循提交规范，正文补关键说明与关联单号 |
| 编辑时机 | 在合并前于合并框中修改，事后修改需要改写主干历史 |
典型使用场景
- 功能分支里积累了大量「改错再改对」的琐碎提交，需要压缩
- 主干历史要求一条提交对应一个可回溯的改动
- 要把需求单号与关闭指令一并带进主干
- 发布说明与评审口径需要一致，避免两处说法不同
- 多人协作同一分支时统一提交信息的口径
压缩后的信息形态
压缩后的信息形态
# 压缩合并后主干上看到的提交信息
feat(login): 支持邮箱验证码登录 (#4821)
* 增加验证码发送接口与限流
* 补充风控校验与单元测试
Closes #4821
git log --oneline -3 # 确认主干上的提交标题符合预期平台默认行为对照
| 方式 | 默认标题来源 | 可编辑性 |
|---|---|---|
| GitHub 压缩合并 | 评审请求标题 | 合并框中可改标题与正文 |
| GitLab 压缩合并 | 评审标题，并拼接各条提交信息 | 合并页面可编辑 |
| 本地压缩提交 | 人工整理后的提交信息 | 完全由提交者决定 |
标题里写「修复问题」「优化代码」这类模糊描述，会让主干日志失去检索价值；评审时应把标题当成最终提交信息来审。
压缩后原始提交哈希不再保留，追溯细节要依赖平台上的评审记录；对需要逐条追溯的分支，改用保留合并提交的方式更合适。