Skip to content

Commit 3ec99f9

Browse files
committed
[T] update toc
1 parent 1622f37 commit 3ec99f9

14 files changed

+2993
-2707
lines changed

chapters/04-commit-message.md

Lines changed: 94 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,94 @@
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+
File renamed without changes.
File renamed without changes.
Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,6 @@
11
开源项目维护
22
===
33

4+
5+
Release
6+
---

chapters/10-git-tools.md

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
Git 工具推荐
2+
===
3+
4+
至于我的日常用的 Git 观看工具,一个是 WebStorm 和 Intellij IDEA 自带的,一个则是 SourceTree。
5+
6+
由于日常用的开发工是 Intellij IDEA 企业版,所以就有点依赖于这个工具了。最常用的功能便是:**修复 Bug 时,对于文件修改的追溯**。了解某行代码修改的原因,对应的修改人等等。
7+
8+
而 SourceTree 则方便用来查看一些非我写的项目,寻找其中的一些问题。个中缘由便是:**Intelli IDEA 刚打开某个项目的时候,需要花费大量的时间 index**,只可惜现有的 SourceTree 客户端都需要登录 Atlassian 账户了。
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.

0 commit comments

Comments
 (0)