mirror of
https://github.com/ZJDoc/GitGuide.git
synced 2026-07-25 05:10:25 +08:00
docs(message): add
This commit is contained in:
zjkjzj
102
docs/message/angular-commit.md
Normal file
102
docs/message/angular-commit.md
Normal file
@@ -0,0 +1,102 @@
|
||||
|
||||
# Angular提交规范
|
||||
|
||||
目前最受开发人员肯定的规范是前端框架`Angular`提出的[Angular提交信息规范](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)
|
||||
|
||||
提交格式如下：
|
||||
|
||||
<type>(<scope>): <subject>
|
||||
<BLANK LINE>
|
||||
<body>
|
||||
<BLANK LINE>
|
||||
<footer>
|
||||
|
||||
每次提交可以包含页眉(`header`)、正文(`body`)和页脚(`footer`)，每次提交**必须包含页眉内容**
|
||||
|
||||
每次提交的信息不超过`100`个字符
|
||||
|
||||
详细文档：[AngularJS Git Commit Message Conventions](https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#)
|
||||
|
||||
## 页眉设置
|
||||
|
||||
页眉的格式指定为提交类型(`type`)、作用域(`scope`，可选)和主题(`subject`)
|
||||
|
||||
### 提交类型
|
||||
|
||||
提交类型指定为下面其中一个：
|
||||
|
||||
1. `build`：对构建系统或者外部依赖项进行了修改
|
||||
2. `ci`：对CI配置文件或脚本进行了修改
|
||||
3. `docs`：对文档进行了修改
|
||||
4. `feat`：增加新的特征
|
||||
5. `fix`：修复`bug`
|
||||
6. `pref`：提高性能的代码更改
|
||||
7. `refactor`：既不是修复`bug`也不是添加特征的代码重构
|
||||
8. `style`：不影响代码含义的修改，比如空格、格式化、缺失的分号等
|
||||
9. `test`：增加确实的测试或者矫正已存在的测试
|
||||
|
||||
### 作用域
|
||||
|
||||
范围可以是任何指定提交更改位置的内容
|
||||
|
||||
### 主题
|
||||
|
||||
主题包括了对本次修改的简洁描述，有以下准则
|
||||
|
||||
1. 使用命令式，现在时态：“改变”不是“已改变”也不是“改变了”
|
||||
2. 不要大写首字母
|
||||
3. 不在末尾添加句号
|
||||
|
||||
## 正文设置
|
||||
|
||||
和主题设置类似，使用命令式、现在时态
|
||||
|
||||
应该包含修改的动机以及和之前行为的对比
|
||||
|
||||
## 页脚设置
|
||||
|
||||
### Breaking changes
|
||||
|
||||
不兼容修改指的是本次提交修改了不兼容之前版本的`API`或者环境变量
|
||||
|
||||
所有不兼容修改都必须在页脚中作为中断更改块提到，以`BREAKING CHANGE`:开头，后跟一个空格或者两个换行符，其余的信息就是对此次修改的描述，修改的理由和修改注释
|
||||
|
||||
BREAKING CHANGE: isolate scope bindings definition has changed and
|
||||
the inject option for the directive controller injection was removed.
|
||||
|
||||
To migrate the code follow the example below:
|
||||
|
||||
Before:
|
||||
|
||||
。。。
|
||||
。。。
|
||||
|
||||
After:
|
||||
|
||||
。。。
|
||||
。。。
|
||||
|
||||
The removed `inject` wasn't generaly useful for directives so there should be no code using it.
|
||||
|
||||
### 引用提交的问题
|
||||
|
||||
如果本次提交目的是修改`issue`的话，需要在页脚引用该`issue`
|
||||
|
||||
以关键字`Closes`开头，比如
|
||||
|
||||
Closes #234
|
||||
|
||||
如果修改了多个`bug`，以逗号隔开
|
||||
|
||||
Closes #123, #245, #992
|
||||
|
||||
## 回滚设置
|
||||
|
||||
当此次提交包含回滚(`revert`)操作，那么页眉以`"revert:"`开头，同时在正文中添加`"This reverts commit hash"`，其中`hash`值表示被回滚前的提交
|
||||
|
||||
revert:<type>(<scope>): <subject>
|
||||
<BLANK LINE>
|
||||
This reverts commit hash
|
||||
<other-body>
|
||||
<BLANK LINE>
|
||||
<footer>
|
||||
123
docs/message/conventional-commit.md
Normal file
123
docs/message/conventional-commit.md
Normal file
@@ -0,0 +1,123 @@
|
||||
|
||||
# Conventional提交规范
|
||||
|
||||
[Conventional Commits](https://www.conventionalcommits.org)(约定式提交)脱胎于`Angular`提交信息准则，提供了更加通用、简洁和灵活的提交规范
|
||||
|
||||
提交格式如下：
|
||||
|
||||
<类型>[可选的作用域]: <描述>
|
||||
# 空一行
|
||||
[可选的正文]
|
||||
# 空一行
|
||||
[可选的脚注]
|
||||
|
||||
## 页眉设置
|
||||
|
||||
强制支持的类型名是`fix`和`feat`，同样支持`Angular`准则中推荐的其他类型
|
||||
|
||||
常规提交规范还推荐使用类型`improvement`，表示在不添加新功能或修复`bug`的情况下改进当前的实现
|
||||
|
||||
## 页尾设置
|
||||
|
||||
强制支持在页脚使用`BREAKING CHANGES`
|
||||
|
||||
## 提交规范
|
||||
|
||||
结合[RFC2019](https://www.ietf.org/rfc/rfc2119.txt)，在下面规范中使用关键字来指示需求级别
|
||||
|
||||
* `MUST`（必须）
|
||||
* `MUST NOT`（禁止）
|
||||
* `REQUIRED`（需要）
|
||||
* `SHALL`（应当）
|
||||
* `SHALL NOT`（不应当）
|
||||
* `SHOULD`（应该）
|
||||
* `SHOULD NOT`（不应该）
|
||||
* `RECOMMENDED`（推荐）
|
||||
* `MAY`（可以）
|
||||
* `OPTIONAL`（可选）
|
||||
|
||||
1. 每次提交**必须**添加类型名为前缀。类型名是一个名词，比如`feat、fix`，后跟冒号和一个空格
|
||||
2. 类型`feat`**必须**在提交新特征时使用
|
||||
3. 类型`fix`**必须**用于修复`bug`的提交
|
||||
4. 类型后面**可以**添加一个可选的作用域。作用域名是一个短语，表示代码库中的一个小节，比如`fix(parser)`
|
||||
5. 在类型/作用域前缀后面**必须**跟上一个简短描述，关于本次提交的代码修改，比如`fix: 字符串中包含多个空格时的数组分析问题`
|
||||
6. **可以**在描述后面添加一个长的正文，用于提供额外的上下文信息。正文内容**必须**在短描述后空一行开始
|
||||
7. **可以**在正文后空一行开始页脚，页脚**应该**包含这次代码修改的相关问题，比如`Fixes #13`
|
||||
8. 不兼容修改(`breaking change`)**必须**放置在提交的页脚或正文部分的最开始处，**必须**使用大写文本`BREAKING CHANGE`作为前缀，后跟冒号和一个空格
|
||||
9. 在`BREAKING CHANGE:`后面**必须**提供一个描述，关于`API`的修改，比如`BREAKING CHANGE: 环境变量目前优先于配置文件`
|
||||
10. 页脚**必须**包含不兼容修改、额外链接、问题引用和其他元信息
|
||||
11. 除了`feat`和`fix`以外的类型**可以**在提交信息中使用
|
||||
|
||||
## 徽章
|
||||
|
||||
使用了常规提交规范可以添加徽章在`README`
|
||||
|
||||
[](https://conventionalcommits.org)
|
||||
|
||||
## 实现示例
|
||||
|
||||
只有页眉和页尾
|
||||
|
||||
feat: allow provided config object to extend other configs
|
||||
|
||||
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
|
||||
|
||||
只有页眉
|
||||
|
||||
docs: correct spelling of CHANGELOG
|
||||
|
||||
使用了作用域
|
||||
|
||||
feat(lang): added polish language
|
||||
|
||||
修复了`bug`
|
||||
|
||||
fix: minor typos in code
|
||||
|
||||
see the issue for details on the typos fixed
|
||||
|
||||
fixes issue #12
|
||||
|
||||
## `FAQ`
|
||||
|
||||
问：在最初开发阶段如何处理提交信息？
|
||||
|
||||
建议像已发布产品一样处理。即使是你的软件开发伙伴在使用软件过程中，也想知道那些被修复了，那些是不兼容修改。
|
||||
|
||||
问：提交头的类型名是大写还是小写？
|
||||
|
||||
无所谓，不过最好保持一致（一直大写或一直小写）
|
||||
|
||||
**问：如果提交内容适用于多个类型怎么办？**
|
||||
|
||||
尽可能返回并进行多次提交。常规提交准则的优势在于它有能力驱动我们进行更加组织化的提交和`PR`
|
||||
|
||||
问：这是否是不鼓励快速开发和快速迭代？
|
||||
|
||||
它不鼓励以无序的方式快速开发。它帮助你在有多个开发者的多个项目中进行长期开发
|
||||
|
||||
**问：常规提交准则是否会限制提交的类型?**
|
||||
|
||||
常规提交准则鼓励开发者使用更多有确切含义的类型。除此以外，准则的灵活性允许开发组提出更多适用于自己的类型，并随着时间的推移更改这些类型
|
||||
|
||||
问：这个准则和[SemVer](https://semver.org/lang/zh-CN/)的联系？
|
||||
|
||||
`fix`类型应该翻译成`PATCH`版本。`feat`类型应该翻译成`MINOR`版本。如果提交信息中包含`不兼容修改`，不管哪种类型，都应该翻译成`MAJOR`版本
|
||||
|
||||
问：如何将扩展版本转换为常规提交规范?
|
||||
|
||||
我们建议使用`SemVer`发布您自己对本规范的扩展（并鼓励您进行这些扩展！）
|
||||
|
||||
**问：如果我不小心使用了错误的提交类型，该怎么办？**
|
||||
|
||||
1. 使用了规范中的类型但是没有使用正确的类型，比如使用`fix`替代了`feat`
|
||||
|
||||
在合并或者发布这个错误之前，推荐使用`git rebase -i`进行提交历史编辑。发布之后，依据使用的工具或流程进行清理
|
||||
|
||||
2. 当使用了规范外的类型，比如使用了`feet`替代了`feat`
|
||||
|
||||
如果提交不符合常规提交规范，它只是意味着基于规范的工具将错过这次提交
|
||||
|
||||
**问：是否我的所有贡献者都需要使用常规提交规范?**
|
||||
|
||||
如果使用基于`squash`的`Git`工作流，主管维护者可以在合并时清理提交信息——这不会对普通提交者产生额外的负担。常见的工作流程是让`git`系统自动从`pull request`中`squash`出提交，并向主维护者提供一份表单，用以在合并时输入适合的`git`提交信息。
|
||||
83
docs/message/gitmessage.md
Normal file
83
docs/message/gitmessage.md
Normal file
@@ -0,0 +1,83 @@
|
||||
|
||||
# [gitmessage]提交模板
|
||||
|
||||
## 默认模板
|
||||
|
||||
在提交时打开编译器，默认会出现一段模板信息，提示你编辑提交信息，同时会提示当前修改的文件
|
||||
|
||||
$ git commit
|
||||
|
||||
# Please enter the commit message for your changes. Lines starting
|
||||
# with '#' will be ignored, and an empty message aborts the commit.
|
||||
# On branch master
|
||||
# Your branch is ahead of 'origin/master' by 1 commit.
|
||||
# (use "git push" to publish your local commits)
|
||||
#
|
||||
# Changes to be committed:
|
||||
# modified: ...
|
||||
# deleted: ...
|
||||
#
|
||||
|
||||
## 自定义模板
|
||||
|
||||
可以自己编辑一个模板文件，比如新建`~/.gitmessage`，编辑一段关于提交规范的注释
|
||||
|
||||
$ vim ~/.gitmessage
|
||||
|
||||
# head: <type>(<scope>): <subject>
|
||||
# - type: feat, fix, docs, style, refactor, test, chore
|
||||
# - scope: can be empty (eg. if the change is a global or difficult to assign to a single component)
|
||||
# - subject: start with verb (such as 'change'), 50-character line
|
||||
#
|
||||
# body: 72-character wrapped. This should answer:
|
||||
# * Why was this change necessary?
|
||||
# * How does it address the problem?
|
||||
# * Are there any side effects?
|
||||
#
|
||||
# footer:
|
||||
# - Include a link to the ticket, if any.
|
||||
# - BREAKING CHANGE
|
||||
#
|
||||
|
||||
修改全局配置文件`~/.gitconfig`，添加
|
||||
|
||||
[commit]
|
||||
template = ~/.gitmessage
|
||||
|
||||
再次提交时显示的模板如下
|
||||
|
||||
# head: <type>(<scope>): <subject>
|
||||
# - type: feat, fix, docs, style, refactor, test, chore
|
||||
# - scope: can be empty (eg. if the change is a global or difficult to assign to a single component)
|
||||
# - subject: start with verb (such as 'change'), 50-character line
|
||||
#
|
||||
# body: 72-character wrapped. This should answer:
|
||||
# * Why was this change necessary?
|
||||
# * How does it address the problem?
|
||||
# * Are there any side effects?
|
||||
#
|
||||
# footer:
|
||||
# - Include a link to the ticket, if any.
|
||||
# - BREAKING CHANGE
|
||||
#
|
||||
|
||||
# Please enter the commit message for your changes. Lines starting
|
||||
# with '#' will be ignored, and an empty message aborts the commit.
|
||||
# On branch master
|
||||
# Your branch is ahead of 'all/master' by 2 commits.
|
||||
# (use "git push" to publish your local commits)
|
||||
#
|
||||
# Changes to be committed:
|
||||
# new file: .gitignore
|
||||
#
|
||||
# Untracked files:
|
||||
# package.json
|
||||
#
|
||||
|
||||
## 文件解析
|
||||
|
||||
在仓库内的`.git/COMMIT_EDITMSG`文件中保存了最近一次提交的日志（包括模板信息）
|
||||
|
||||
## 相关阅读
|
||||
|
||||
* [优雅的提交你的 Git Commit Message](https://zhuanlan.zhihu.com/p/34223150)
|
||||
15
docs/message/index.md
Normal file
15
docs/message/index.md
Normal file
@@ -0,0 +1,15 @@
|
||||
|
||||
# 引言
|
||||
|
||||
每次进行`git`提交时，需要写提交说明，规范提交说明的好处如下
|
||||
|
||||
1. 更加结构化的提交历史
|
||||
2. 保证每次信息都有确切的含义
|
||||
3. 方便直接生成`changelog`
|
||||
4. 方便信息搜索和过滤
|
||||
|
||||
## 相关阅读
|
||||
|
||||
* [Commit message 和 Change log 编写指南](http://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html)
|
||||
* [如何写好 Git commit log?](https://www.zhihu.com/question/21209619)
|
||||
* [优雅的提交你的 Git Commit Message](https://zhuanlan.zhihu.com/p/34223150)
|
||||
Reference in New Issue
Block a user