评审署名 Reviewed-by 是什么
评审署名机制：部分平台在合并时写入 Reviewed-by 页脚（GitLab 在 squash/合并时可按配置写入批准者），用于追溯谁完成了这次评审。内核等邮件流项目则由评审者手工声明背书。Trailer 写在提交信息末尾，可以用 git log 直接检索。
基本信息
| GitLab | 合并/squash 时按平台配置写入 Reviewed-by 页脚 |
|---|---|
| 邮件流程 | 评审者在回复中加入 Reviewed-by 声明背书 |
| 查看 | git log 中按 trailer 检索评审记录 |
| 手工添加 | git interpret-trailers 生成规范格式 |
| 审计边界 | 保留与否取决于合并方式，重要项目以平台记录为准 |
| 格式约定 | 署名写在提交信息末尾的页脚区，多个署名列成一组 |
典型使用场景
- 审计追溯：回答「谁评审了这次改动」时有据可查。
- 合规要求：流程规范要求在合并记录里留下评审署名。
- 邮件流项目：接收补丁时检查是否带必要的署名标签。
- 数据统计：脚本统计评审人分布与评审负载。
- 模板统一：把署名规范写入贡献指南，减少格式混乱。
- 问题归因：线上问题回溯时找到当时评审与批准链条。
- 工具集成：CI 校验提交信息是否包含必需 trailer，缺失则给出提示。
查看与手工添加
查看与手工添加
git log -1 --format='%B' | grep -i 'reviewed-by' || true # 检查提交信息里的评审署名
git interpret-trailers --parse < <(git log -1 --format=%B) # 解析提交信息里的 trailer
git interpret-trailers --in-place --trailer 'Reviewed-by: Wang Wu <wangwu@example.com>' msg.txt
# msg.txt 是完整的提交信息文件，trailer 会附加在末尾页脚区署名来源与可靠性
| 来源 | 写入方 | 可靠性 |
|---|---|---|
| 平台自动 | 合并与 squash 流程 | 高，依据平台配置 |
| 邮件声明 | 评审者本人 | 取决于流程规范 |
| 手工添加 | 提交者 | 需流程约束，易遗漏 |
团队若要求评审签名，合入方式（squash/merge）会影响 trailer 是否被保留，先在测试仓库验证；不同平台默认行为不同，写进贡献指南前先确认。；署名信息最好同时记录进发布说明，方便外部追溯。