团队中的 Git 规范

版本

版本格式：主版本号.次版本号.修订号

版本号递增规则如下：

主版本号：当你做了不兼容的 API 修改
次版本号：当你做了向下兼容的功能性新增
修订号：当你做了向下兼容的问题修正

先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。

主版本号为零（0.yz）的软件处于开发初始阶段，一切都可能随时被改变。这样的公共API 不应该被视为稳定版。

每当次版本号递增时，修订号 “必须MUST” 归零。

每当主版本号递增时，次版本号和修订号 “必须MUST” 归零。

被标上先行版本号则表示这个版本并非稳定而且可能无法达到兼容的需求。范例：1.0.0-alpha、1.0.0-alpha.1、 1.0.0-0.3.7、1.0.0-x.7.z.92。

版本编译信息 “可以MAY” 被标注在修订版或先行版本号之后，先加上一个加号再加上一连串以句点分隔的标识符号来修饰。范例：1.0.0-alpha+001、1.0.0+20130313144700、1.0.0-beta+exp.sha.5114f85。

版本的优先层级指的是不同版本在排序时如何比较。范例：1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0- rc.1 < 1.0.0。

Commit Message

代码要有代码的规范，协作要有协作的规范，Commit Message 也可以有自己的参考规范。

前端 JS 框架 Angular：

前端知名 JS 框架 MingGeJS

想想我们自己的 Commit Message，更像哪一个？

接下来我们来分析下 Angular 的 Commit Message!

Commit Message 格式

<type>(<scope>): <subject>
<空行>
<body>
<空行>
<footer>

分成标题、内容详情、结尾三个部分，各有各的用处，没有多余项。

标题(header)

标题是可以直接在页面中预览的部分，分为 type、scope、subject 三部分。

type

feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style：格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动

scope

用来说明本次 Commit 影响的范围，即简要说明修改会涉及的部分。

subject

用来简要描述本次改动，概述就好了，因为后面还会在 body 里给出具体信息。但最好遵循下面三条:

以动词开头，使用第一人称现在时，比如change，而不是changed或changes
首字母不要大写
结尾不用句号(.)

内容详情(body)

是对上面 subject 里内容的展开，在此做更加详尽的描述，内容里应该包含修改动机和修改前后的对比。

结尾(footer)

主要放置不兼容变更和 Issue 关闭的信息。

Revert

如果是撤销之前的 Commit，那么本次 Commit Message 必须以 revert：开头。

body 中必须要记录所撤销的 Commit 的 SHA 值。

辅助工具 Commitiz

commitizen ruanyifeng jianshu

mambat / blog