合并提交信息的价值
合并提交信息默认形如 Merge branch 'feature/x'，必要时带上合入的目标分支。它本身不影响代码，但在按分支回溯改动、统计来源和对接工单时是重要线索。团队可以约定格式，也可以整段自定义；平台生成的合并提交通常还会带上评审请求编号，便于反查讨论记录。
基本信息
| 默认形式 | Merge branch '<分支>'，必要时加 into '<目标>' |
|---|---|
| 自定义方式 | git merge -m '<信息>'，或 --edit 打开编辑器 |
| 平台约定 | 平台生成的合并提交常带合并请求编号 |
| 查看方式 | git log --merges --oneline |
典型使用场景
- 按分支维度回溯某次合并引入了哪些改动
- 从提交信息里找到对应的评审请求编号
- 排查某个改动是什么时候进入主干的
- 团队统一格式之后，统计脚本可以稳定解析合并来源
- 保留合并提交，以便整体撤销一次合并
常用示例
常用示例
git merge --no-ff -m 'Merge branch feature/login into main' feature/login # 自定义信息
git merge --edit feature/login # 合并前打开编辑器补充说明
git log --merges --oneline -10 # 查看最近的合并提交
git log --merges --pretty='%h %s' -10 # 只取哈希与标题，便于统计信息要素
| 要素 | 示例 | 作用 |
|---|---|---|
| 来源分支 | feature/login | 快速定位改动来源 |
| 目标分支 | into main | 明确合入路径 |
| 评审编号 | 带请求编号的注记 | 回溯讨论与评审记录 |
| 自定义说明 | 由 -m 指定 | 满足团队约定的格式 |
想批量统计合并来源，可以用只取合并提交的日志；信息里保留评审编号，对回溯变更原因很实用。
如果团队用压缩合并，主干上不会留下合并提交，追溯要靠评审平台的记录。两种依赖方式不要混用，否则统计结果会不完整。合并信息里的来源分支名在分支清理之后可能已不存在，回查时以提交历史为准。
如果团队用压缩合并，主干上不会留下合并提交，追溯要靠评审平台的记录。两种依赖方式不要混用，否则统计结果会不完整；合并信息里的来源分支名在分支清理之后可能已不存在，回查时以提交历史为准。
写自定义合并信息时保留来源分支与评审编号就够用，不必把改动内容再复述一遍：细节交给提交与评审记录，合并信息只承担指路的作用，写得越短越容易被稳定解析。