如何在自定义commit-msg钩子中向提交消息追加Change-id

为什么不推荐走「合并官方Bash钩子、维护多套钩子」的路线 #

• Git的钩子机制默认不会自动链式执行同路径下的多个同名commit-msg脚本，你必须额外写一层调度壳脚本，才能同时跑自己写的Python校验逻辑、官方Bash的Change-id生成逻辑，平白新增一个维护节点
• BASH脚本的跨环境一致性很差，不同操作系统的sed/awk参数差异、bash版本差异，很容易在部分开发同学的设备上出现钩子执行失败、Change-id格式不符合Gerrit要求的问题
• 跨脚本的执行顺序很难对齐：如果把Change-id生成放在你的格式校验逻辑之前，一旦校验不通过，已经被修改的提交消息会留下无效的Change-id字段；如果放在校验之后，又要额外处理返回码透传逻辑，很容易出现本该拦截的不合规提交被误放行的情况
• 这类方案唯一的好处是不需要自己写几十行Change-id生成代码，收益远低于额外的维护成本

为什么自行实现Change-id的投入极低、收益更高 #

Change-id的生成规则是完全固定、公开的，在Python里的实现非常简单：

• 逐行读取钩子传入的提交消息文件，检查是否已存在匹配^Change-Id: I[0-9a-f]{40}$格式的行，存在则直接跳过不重复生成
• 不存在的话，基于当前提交的作者名、作者邮箱、提交时间、提交正文计算SHA1哈希，生成带固定I前缀的40位十六进制字符串
• 在提交消息正文的空行后（也就是Gerrit要求的页脚专属区域）追加对应的Change-id行
• 整个流程完全可以嵌合到你现有钩子的执行链路里：读取提交消息→跑原有格式校验、按你的自定义模板修正内容→按规则检查、追加Change-id到模板指定的页脚位置→回写文件，全程没有跨脚本调度的问题，甚至可以确保Change-id的位置完全匹配你设计的模板结构，不会出现格式错乱
• 复用现有Python脚本的跨环境兼容性，不会像BASH脚本那样因为系统差异出现执行异常，长期维护成本几乎为0

仅适合直接使用官方Bash钩子的场景 #

• 团队没有自定义的提交消息校验、模板注入需求，完全依靠Gerrit的默认规则做提交管控
• 所有开发环境严格统一，不存在多操作系统、多Linux发行版的兼容问题
• 没有足够人力维护自定义钩子，完全依赖Gerrit官方的版本更新

内容的提问来源于stack exchange，提问作者wojtekd09