摘要: 大家都知道所有的版本控制系统比如svn,git等设计的核心价值之一就是为了让代码变更有迹可循,而commit mesage的价值在于让有迹可循的代码对人类更加友好,通常一个恰如其分的commit message表达的信息往往先于代码。
背景
大家都知道所有的版本控制系统比如svn,git等设计的核心价值之一就是为了让代码变更有迹可循,而commit mesage的价值在于让有迹可循的代码对人类更加友好,通常一个恰如其分的commit message表达的信息往往先于代码。
而现实的工程实践中,尤其是大型分布式协作的团队,因开发成员背景、习惯、经验多差异性,commit message的风格参差不齐。
那么有没有优雅而简单方式将commit message按照工程标准来落地呢?
下面分享一个git commit message的实践,其核心是通过git commit template标准化comments,希望可以抛砖引玉。
配置commit message template
通过配置相同的git commit template & markdown syntax 来标准化git message。步骤如下:
- 进入~/ 目录,新增__.gitmessage, 内容如下:__
brief introduction.
#brief introdction 必填,概要描述变更内容。
#change item list 选填,针对变更不同模块/业务进行分条描述,使用markdown语法。
#demo
#add xxx open api.
#- add xxx api.
#- add xxx api.
#- add xxx api.
2.编辑.gitconfig文件,新增.gitmessage模版配置。
[commit]
template = ~/.gitmessage
后续在提交代码时候(使用git commit没有指定-m参数)git message将会自动按照模版格式生成。效果如下:
实践建议
- 正式的commit尽量不要使用 git commit -m指定message信息,避免生成的git log可读性差。
- commit message 格式优先使用markdown格式,生成的格式将更优雅,通过git log查看可读性更佳。
- 较大feature发布,git message尽可能丰富,通过概要+变更列表的格式表达,如上图。
- commit mesaage尽量使用英文。
一些思考
- 自动化视角,通过git commit template 自动生成comments模版的方式,可以在一定程度减少漏填AoneID的情况,同时可以提升commit message质量,如果要实现严格管控可以增加githook在checkin之前增加校验,或者接入持续集成在静态检测阶段校验git commit log的有效性。
- 工程视角,git comment, code comment即代码,应该以标准优雅的方式在团队传承。
阅读更多干货好文,请关注扫描以下二维码:
原文地址:http://blog.51cto.com/13679539/2112277