|
| 1 | +Git 提交信息及几种不同的规范 |
| 2 | +=== |
| 3 | + |
| 4 | +> 受 Growth 3.0 开发的影响,最近更新文章的频率会有所降低。今天,让我们来谈谈一个好的 Git、SVN 提交信息是怎样规范出来的。 |
| 5 | +
|
| 6 | +在团队协作中,使用版本管理工具 Git、SVN 几乎都是这个行业的标准。当我们提交代码的时候,需要编写提交信息(commit message)。 |
| 7 | + |
| 8 | +而提交信息的主要用途是:**告诉这个项目的人,这次代码提交里做了些什么**。如,我更新了 React Native Elements 的版本,那么它就可以是:``[T] upgrade react native elements``。对应的我修改的代码就是:``package.json`` 和 ``yarn.lock`` 中的文件。一般来说,建议**小步提交**,即按自己的 Tasking 步骤来的提交,每一小步都有对应的提交信息。这样做的主要目的是:**防止一次修改中,修改过多的文件,导致后期修改、维护、撤销等等困难**。 |
| 9 | + |
| 10 | +而对于不同的团队来说,都会遵循一定的规范,本文主要会介绍以下几种写法: |
| 11 | + |
| 12 | + - 工作写法 |
| 13 | + - 常规写法 |
| 14 | + - 开源库写法 |
| 15 | + |
| 16 | +那么,先从我习惯的做法说起。 |
| 17 | + |
| 18 | +工作写法 |
| 19 | +--- |
| 20 | + |
| 21 | +在我的第一个项目里,我们使用 Jira 作为看板工具,Bamboo 作为持续集成服务器,并采用结对编程的方式进行。 |
| 22 | + |
| 23 | +在 Jira 里每一个功能卡都有对应的卡号,而 Bamboo 支持使用 Jira 的任务卡号关联的功能。即在持续构建服务器上示例对应的任务卡号,即相应的提交人。 |
| 24 | + |
| 25 | +因此,这个时候我们的规范稍微有一些特别: |
| 26 | + |
| 27 | +``` |
| 28 | +[任务卡号] xx & xx: do something |
| 29 | +``` |
| 30 | + |
| 31 | +比如:``[PHODAL-0001] ladohp & phodal: update documents``,解释如下: |
| 32 | + |
| 33 | + - ``PHODAL-0001``,业务的任务卡号,它可以帮我们找到某个业务修改的原因,即点出相应 bug 的来源 |
| 34 | + - ``ladohp & phodal`` ,结对编程的两个人的名字,后者(phodal)一般是写代码的人,出于礼貌就放在后面了。由于 Git 的提交人只显示一个,所以写上两个的名字。当提交的人不在时,就可以问另外一个人修改的原因。 |
| 35 | + - ``update documents``,我们做了什么事情 |
| 36 | + |
| 37 | +缺点:而对于采用看板的团队来说,并不存在任务卡号这种东西,因此就需要一种额外的作法。 |
| 38 | + |
| 39 | +常规写法 |
| 40 | +--- |
| 41 | + |
| 42 | +对于我来说,我则习惯这种的写法: |
| 43 | + |
| 44 | +``` |
| 45 | +[任务分类] 主要修改组件(可选):修改内容 |
| 46 | +``` |
| 47 | + |
| 48 | +示例 1,``[T] tabs: add icons`` 。其中的 ``T`` 表示这是一个技术卡,``tabs`` 表示修改的是 Tabs,``add icons`` 则表示添加了图标。 |
| 49 | + |
| 50 | +示例 2,``[SkillTree] detail: add link data``。其中的 ``SkillTree`` 表示修改的是技能树 Tab 下的内容,``detail`` 则表示修改的是详情页,``add link data`` 则表示是添加了技能的数据 |
| 51 | + |
| 52 | +这样做的主要原因是,它可以轻松也帮我** filter 出相应业务的内容**。 |
| 53 | + |
| 54 | +缺点:要这样做需要团队达到一致,因此付出一些额外的成本。 |
| 55 | + |
| 56 | +开源应用、开源库写法 |
| 57 | +--- |
| 58 | + |
| 59 | +与我们日常工作稍有不同的是:工作中的 Release 计划一般都是事先安排好的,不需要一些 CHANGELOG 什么的。而开源应用、开源库需要有对应的 CHANELOG,则添加了什么功能、修改了什么等等。毕竟有很多东西是由社区来维护的。 |
| 60 | + |
| 61 | +因此,这里以做得比较好的开源项目 Angular 中为例展示。Angular 团队建议采用以下的形式: |
| 62 | + |
| 63 | +``` |
| 64 | +<type>(<scope>): <subject> |
| 65 | +<BLANK LINE> |
| 66 | +<body> |
| 67 | +<BLANK LINE> |
| 68 | +<footer> |
| 69 | +``` |
| 70 | + |
| 71 | +诸如:``docs(changelog): update change log to beta.5`` 中: |
| 72 | + |
| 73 | + - docs 则对应修改的类型 |
| 74 | + - changelog 则是影响的范围 |
| 75 | + - subject 则是对应做的事件 |
| 76 | + |
| 77 | +对应的类型有: |
| 78 | + |
| 79 | + - build: 影响构建系统或外部依赖关系的更改(示例范围:gulp,broccoli,npm) |
| 80 | + - ci: 更改我们的持续集成文件和脚本(示例范围:Travis,Circle,BrowserStack,SauceLabs) |
| 81 | + - docs: 仅文档更改 |
| 82 | + - feat: 一个新功能 |
| 83 | + - fix: 修复错误 |
| 84 | + - perf: 改进性能的代码更改 |
| 85 | + - refactor: 代码更改,既不修复错误也不添加功能 |
| 86 | + - style: 不影响代码含义的变化(空白,格式化,缺少分号等) |
| 87 | + - test: 添加缺失测试或更正现有测试 |
| 88 | + |
| 89 | +同时还对应了 20+ 的 Scope,可以说这种提交比上面的提交更有挑战。 |
| 90 | + |
| 91 | +(以上的 10 个类型,感谢 Google Translate 提供的快速翻译支持) |
| 92 | + |
| 93 | +而这样做的优点是,它可以轻松地生成一个 CHANGELOG。与些同时还有一个名为 ``Conventional Commits`` 的规范,建议采用相似的形式。 |
| 94 | + |
0 commit comments