4. 多人协助：Commit 规范，Issue，和 Pull Request

[Tinellie]

在多人协助下，对 Commit 信息做出规范就很重要。

此外 GitHub 也提供了 Issue 和 Pull Request 等多人协助的工具（你现在看的文章其实就是一个 Issue）。

[Tinellie]

Commit 规范

目前我本人习惯使用规范如下（参考了一些其他的规范）

[提交类型]: 标题
空行
1. 更改1
2. 更改2
3. 更改3
……

提交类型主要分为以下几种：

• feat：新的内容，新的特性（也包括对内容做出更改）
• fix：修复Bug
• style：修改格式（不影响代码运行的变动）
• refactor：重构（既不是新增内容，又不是修bug的代码改动，例如改善代码可读性，优化程序性能）
• docs：修改了文档
• test：添加了测试用的代码/内容

还有这两种比较特殊的：

[merge]: merge [branch-A] into [branch-B]

1. 分支说明1
2. 分支说明2
3. 分支说明3
……

• revert：回滚到旧版本
• merge：合并分支

[Tinellie]

Issue

在 GitHub 仓库的 Issues 页面可以创建撰写 Issue，用于描述项目出现的问题，需求的新功能等。

Issue 的编辑使用 Markdown 语法。

右侧的版面可以给 Issue 添加标签、分配负责成员 等。

引用 Issue

#[issue编号]，可以这样引用 Issue，如 → #1

被引用的 Issue 下，也会出现相关信息（如图所示，#1下出现了「被#6（本issue）引用」的信息）

git 的 commit 信息也可以引用 Issue

关闭 Issue

当 Issue 描述的 问题 / 需求 被解决，就需要关闭这个 Issue。
当然关闭了的 Issue 也可以重新打开。

在 Issue 最下方可以找到 Close / Reopen 的按钮。

在提交中，也可以自动关闭 Issue，只需要 加上 close #[issue编号]

close 也可以被下列关键字替代

• close / closes / closed
• fix / fixes / fixed
• resolve / resolves / resolved

如下所示，6f3dda8 这次提交信息包含了 close #6，所以你现在被阅读的这个 Issue 被自动关闭了。

[Tinellie]

Pull Request

类似于一种特殊的 Issue。

有时候我们会将某些 branch 保护起来。（如 master）

↓

之后我们如果在本地对这个 branch 进行了提交，是没法直接 push 这个 branch 到远程仓库的。（如图，我把 develop merge 到 master，然后 push master 报错了）

所以我们需要在 GitHub 仓库的 Pull Requests 页面，创建 PR，可以参考这个 #7

由于我设置了必须要有一名自己以外的成员审核 PR，而且仓库拥有者不能跳过规则，所以这里是显示还不能 merge 的。

于是我开了小号提交 review。

同意之后，可以看见已经能够 merge 了。

之后只需要输入一段 merge 提交信息，就完成了。