Git 提交信息及几种不同的规范
在团队协作中,使用版本管理工具 Git、SVN 几乎都是这个行业的标准。当我们提交代码的时候,需要编写提交信息(commit message)。
而提交信息的主要用途是:告诉这个项目的人,这次代码提交里做了些什么。如,我更新了 React Native Elements 的版本,那么它就可以是:。对应的我修改的代码就是:package.json
和 yarn.lock
中的文件。一般来说,建议小步提交,即按自己的 Tasking 步骤来的提交,每一小步都有对应的提交信息。这样做的主要目的是:防止一次修改中,修改过多的文件,导致后期修改、维护、撤销等等困难。
而对于不同的团队来说,都会遵循一定的规范,本文主要会介绍以下几种写法:
- 工作写法
- 常规写法
- 开源库写法
那么,先从我习惯的做法说起。
在我的第一个项目里,我们使用 Jira 作为看板工具,Bamboo 作为持续集成服务器,并采用结对编程的方式进行。
在 Jira 里每一个功能卡都有对应的卡号,而 Bamboo 支持使用 Jira 的任务卡号关联的功能。即在持续构建服务器上示例对应的任务卡号,即相应的提交人。
比如:[PHODAL-0001] ladohp & phodal: update documents
,解释如下:
- ,结对编程的两个人的名字,后者(phodal)一般是写代码的人,出于礼貌就放在后面了。由于 Git 的提交人只显示一个,所以写上两个的名字。当提交的人不在时,就可以问另外一个人修改的原因。
update documents
,我们做了什么事情
缺点:而对于采用看板的团队来说,并不存在任务卡号这种东西,因此就需要一种额外的作法。
对于我来说,我则习惯这种的写法:
示例 1,[T] tabs: add icons
。其中的 T
表示这是一个技术卡,tabs
表示修改的是 Tabs, 则表示添加了图标。
示例 2,[SkillTree] detail: add link data
。其中的 SkillTree
表示修改的是技能树 Tab 下的内容,detail
则表示修改的是详情页,add link data
则表示是添加了技能的数据
这样做的主要原因是,它可以轻松也帮我 filter 出相应业务的内容。
与我们日常工作稍有不同的是:工作中的 Release 计划一般都是事先安排好的,不需要一些 CHANGELOG 什么的。而开源应用、开源库需要有对应的 CHANELOG,则添加了什么功能、修改了什么等等。毕竟有很多东西是由社区来维护的。
因此,这里以做得比较好的开源项目 Angular 为例展示。Angular 团队建议采用以下的形式:
诸如: 中:
- docs 则对应修改的类型
- changelog 则是影响的范围
- subject 则是对应做的事件
对应的类型有:
- build: 影响构建系统或外部依赖关系的更改(示例范围:gulp,broccoli,npm)
- docs: 仅文档更改
- feat: 一个新功能
- fix: 修复错误
- perf: 改进性能的代码更改
- refactor: 代码更改,既不修复错误也不添加功能
- style: 不影响代码含义的变化(空白,格式化,缺少分号等)
同时还对应了 20+ 的 Scope,可以说这种提交比上面的提交更有挑战。
(以上的 10 个类型,感谢 Google Translate 提供的快速翻译支持)