mirror of
https://github.com/phodal/github
synced 2026-05-22 08:38:23 +00:00
94 lines
4.5 KiB
Markdown
94 lines
4.5 KiB
Markdown
Git 提交信息及几种不同的规范
|
||
===
|
||
|
||
> 受 Growth 3.0 开发的影响，最近更新文章的频率会有所降低。今天，让我们来谈谈一个好的 Git、SVN 提交信息是怎样规范出来的。
|
||
|
||
在团队协作中，使用版本管理工具 Git、SVN 几乎都是这个行业的标准。当我们提交代码的时候，需要编写提交信息（commit message）。
|
||
|
||
而提交信息的主要用途是：**告诉这个项目的人，这次代码提交里做了些什么**。如，我更新了 React Native Elements 的版本，那么它就可以是：``[T] upgrade react native elements``。对应的我修改的代码就是：``package.json`` 和 ``yarn.lock`` 中的文件。一般来说，建议**小步提交**，即按自己的 Tasking 步骤来的提交，每一小步都有对应的提交信息。这样做的主要目的是：**防止一次修改中，修改过多的文件，导致后期修改、维护、撤销等等困难**。
|
||
|
||
而对于不同的团队来说，都会遵循一定的规范，本文主要会介绍以下几种写法：
|
||
|
||
- 工作写法
|
||
- 常规写法
|
||
- 开源库写法
|
||
|
||
那么，先从我习惯的做法说起。
|
||
|
||
工作写法
|
||
---
|
||
|
||
在我的第一个项目里，我们使用 Jira 作为看板工具，Bamboo 作为持续集成服务器，并采用结对编程的方式进行。
|
||
|
||
在 Jira 里每一个功能卡都有对应的卡号，而 Bamboo 支持使用 Jira 的任务卡号关联的功能。即在持续构建服务器上示例对应的任务卡号，即相应的提交人。
|
||
|
||
因此，这个时候我们的规范稍微有一些特别：
|
||
|
||
```
|
||
[任务卡号] xx & xx: do something
|
||
```
|
||
|
||
比如：``[PHODAL-0001] ladohp & phodal: update documents``，解释如下：
|
||
|
||
- ``PHODAL-0001``，业务的任务卡号，它可以帮我们找到某个业务修改的原因，即点出相应 bug 的来源
|
||
- ``ladohp & phodal`` ，结对编程的两个人的名字，后者（phodal）一般是写代码的人，出于礼貌就放在后面了。由于 Git 的提交人只显示一个，所以写上两个的名字。当提交的人不在时，就可以问另外一个人修改的原因。
|
||
- ``update documents``，我们做了什么事情
|
||
|
||
缺点：而对于采用看板的团队来说，并不存在任务卡号这种东西，因此就需要一种额外的作法。
|
||
|
||
常规写法
|
||
---
|
||
|
||
对于我来说，我则习惯这种的写法：
|
||
|
||
```
|
||
[任务分类] 主要修改组件（可选）：修改内容
|
||
```
|
||
|
||
示例 1，``[T] tabs: add icons`` 。其中的 ``T`` 表示这是一个技术卡，``tabs`` 表示修改的是 Tabs，``add icons`` 则表示添加了图标。
|
||
|
||
示例 2，``[SkillTree] detail: add link data``。其中的 ``SkillTree`` 表示修改的是技能树 Tab 下的内容，``detail`` 则表示修改的是详情页，``add link data`` 则表示是添加了技能的数据
|
||
|
||
这样做的主要原因是，它可以轻松也帮我 **filter 出相应业务的内容**。
|
||
|
||
缺点：要这样做需要团队达到一致，因此付出一些额外的成本。
|
||
|
||
开源应用、开源库写法
|
||
---
|
||
|
||
与我们日常工作稍有不同的是：工作中的 Release 计划一般都是事先安排好的，不需要一些 CHANGELOG 什么的。而开源应用、开源库需要有对应的 CHANGELOG，则添加了什么功能、修改了什么等等。毕竟有很多东西是由社区来维护的。
|
||
|
||
因此，这里以做得比较好的开源项目 Angular 为例展示。Angular 团队建议采用以下的形式：
|
||
|
||
```
|
||
<type>(<scope>): <subject>
|
||
<BLANK LINE>
|
||
<body>
|
||
<BLANK LINE>
|
||
<footer>
|
||
```
|
||
|
||
诸如：``docs(changelog): update change log to beta.5`` 中：
|
||
|
||
- docs 则对应修改的类型
|
||
- changelog 则是影响的范围
|
||
- subject 则是对应做的事件
|
||
|
||
对应的类型有：
|
||
|
||
- build：影响构建系统或外部依赖关系的更改（示例范围：gulp，broccoli，npm）
|
||
- ci：更改我们的持续集成文件和脚本（示例范围：Travis，Circle，BrowserStack，SauceLabs）
|
||
- docs：仅文档更改
|
||
- feat：一个新功能
|
||
- fix：修复错误
|
||
- perf：改进性能的代码更改
|
||
- refactor：代码更改，既不修复错误也不添加功能
|
||
- style：不影响代码含义的变化（空白，格式化，缺少分号等）
|
||
- test：添加缺失测试或更正现有测试
|
||
|
||
同时还对应了 20+ 的 Scope，可以说这种提交比上面的提交更有挑战。
|
||
|
||
（以上的 10 个类型，感谢 Google Translate 提供的快速翻译支持）
|
||
|
||
而这样做的优点是，它可以轻松地生成一个 CHANGELOG。与此同时还有一个名为 ``Conventional Commits`` 的规范，建议采用相似的形式。
|
||
|