PHP获取git提交信意_Git 的提交信息怎么写？

用 Git 和 Angular 了解语意提交信息

让我们解释一下语意提交一词， 然后演示一个提交消息案例，最后谈谈规范的提交信息和 Angular 约定给予我们的启发。

许多项目决定通过使用约定等方式对提交信息进行标准化。这种实践并不新颖，最近几年也被越来越多的使用。你很有可能之前也在某些项目中遇到过此类提交信息。

最早出现规范的项目之一便是 AngularJS。团队创建了详细的文档，详细说明了想要达成的目标及应当采用的方法。这样约定提交的方式非常流行，你们之中的一些人也可能通过 Karma 指南了解到。但是, jQuery, JSHint, Ember, Angular 等等(受 angularJS 启发的增强版提交规范)的约定也有所不同。

可以很清楚的看到上面各种的提交约定，这无疑给了标准化正式规范的一个不错的理由。Conventional Commits 就是这样的规范，在实践中，简化了 Angular 约定，并且清晰的指出了提交约定信息的要点。

通过这篇文章中，我们将介绍“语意提交”背后的想法，并演示具体的示例，用 Git 和 Angular 规范提交。记录中，我们仅使用它们来阐明概念，显然，这就意味着版本控制工具和规范由你自己来决定。

我们开始吧！ 👨🏻‍🏫

动机

让我们从定义一般术语开始：语意提交是人类和机器都可读的提交信息，遵循特定的约定。

这意味着，它仅仅是提交信息的指南，因此：

提交信息是具有语意性的 - 因为这些消息的类型都是有意义的，表达提交的本质。

提交信息是规范的 - 因为对于开发者和工具，这些消息均采用一致和公认的方式进行格式化！

此外，通常我们执行以下操作时，语意提交可能会派上用场：

1、允许维护者和贡献者清楚的浏览项目历史记录并了解更改的本质，同时按照提交消息类型忽略不重要的更改。

2、强制执行受限的提交，从而鼓励针对特定目的执行小的提交。

3、提交项目信息明确，不会混淆措辞。

4、根据提交信息类型自动发布软件包版本。

5、自动生成 CHANGLOG 并发布注释。

总结起来，语意提交致力于实现更好的可读性，效率和自动化。

话虽如此，有些人并不认为这些约定的信息具有可读性或信息性，或许也有充分的理由。如果我们不需要这些额外的便利，在项目中强制执行这样的规范显然也是没有意义的！

好了，是时候了解我们如何在实践中遵循这些约定了！

免责声明：从现在开始，我们将参考 Angular 提交规范信息和它的便利。

提交信息格式

Angular 规范要求按照以下结构来调整提交信息：

上图向我们说明了提交信息由三部分组成，分别为 Header、Body 和 Footer。

让我们详细说明每一部分。

Header

Header 是必填项，简单描述做出更改的目的(最多一百个字符)。

更好的是，它本身就包含三个部分。

1、Type - 代表更改类型的简短前缀。

2、Scope - 代表更改上下文的可选信息(附加到前缀)。

3、Subject - 代表对实际更改的简洁描述。

实际上，就 Git 而言，它仅仅只是提交消息的第一行：git commit -m "fix(core): remove deprecated and defunct wtf* apis"

我们插入一条以 ： 作为分割线的单行信息。假设我们将左分区称为“前缀” - 即 fix 和 core(受影响的软件包)分别是 type 和 scope。另一方面，右分区显然构成了 subject。

简而言之，以上消息的含义是“此更改通过删除不推荐使用和不存在的 wtf* api 修复了 Core package 中的问题”。

The Body

Body 是可选项，它介绍了做出更改背后的动机或者仅仅粗略描述了更详细的信息。

让我们以刚才的示例为例，并添加一个 body。git commit -m "fix(core): remove deprecated and defunct wtf* apis" -m "These apis have been deprecated in v8, so they should stick around till v10, but since they are defunct we are removing them early so that they don't take up payload size."

现在我们在消息上增加了几句话，详细的说明了目的。

请注意以下几点：

我们使用多个 -m 来连接段落而不是简单的行。

Header 和 Body 应该用空白行分割(由于段落的缘故，这显然是正确的)。

注意：尽管我们可以用其他的方式把消息分成几行，但为了简单起见，后面的例子中我们依然会使用多个 -m (并且可以展示一个不易察觉的解决方案)。

The Footer

Footer 是一个可选项，其中提及了更改带来的后果，例如宣布突破性的更改，链接已经解决的问题，提及贡献者等等。

这里对刚刚的消息添加了页脚：git commit -m "fix(core): remove deprecated and defunct wtf* apis" -m "These apis have been deprecated in v8, so they should stick around till v10, but since they are defunct we are removing them early so that they don't take up payload size." -m "PR Close #33949"

在这个例子中，很明显，我们添加了对相关拉取组件的引用，而不是其他内容。

最后，让我们看看完整的提交日志：

你可能会推断，此提交实际上是在 Angular 存储库中进行的。

常见类型

除了定义提交信息格式之外，Angular 信息提交规范还指定了一系列有用的类型，涵盖了各种更改。

在我们开始之前，我们应该区分两种类型的分类。

Development - 维持变更的分类类型，以供开发人员使用，这些更改实际上并不影响生产环境的代码，是开发环境的工作流程。

Production - 变更增强的分类类型，针对最终用户，仅仅影响生产环境的代码。

现在我们来介绍和解释这些可用的类型。

注意：以下示例直接取自 Angular 存储库的提交日志。

👷build

build 类型(以前称之为 chore )用于标识构建系统(涉及脚本、配置和方法)软件包依赖关系相关的开发和更改。

💚CI

CI  类型用于标示持续集成和部署系统相关的开发和更改 - 涉及脚本、配置和方法。

📝DOSC

DOSC 类型用于标示与项目相关的文档更改 - 无论是外部供最终用户使用(如果是库)，还是内部供开发人员使用。

✨feat

feat 类型用于标示新版向后兼容的能力或者功能对于生产环境的更改。

🐛fix

fix 类型用于标示与向后兼容问题修复的相关生产环境的更改。

⚡️ perf

perf 类型用于标示与向后兼容性能改进有关的生产环境的更改。

♻️refactor

refactor 类型用于标示与修改代码库相关的开发环境的更改，该修改既不添加功能也不修复错误 - 例如删除冗余代码，简化代码，重命名变量等。

🎨 style

style 类型用于标示与代码库样式相关的开发环境更改，不论含义如何 - 例如缩进、分号、尾部逗号等等。

✅test

test 类型用于标示开发环境测试相关的更改 - 例如重构现有测试或添加新的测试。

Benefit

现在我们已经熟悉了规范 - 让我们来看看两种从中受益的方法。

浏览记录

Git 为我们提供了浏览存储库提交历史的功能 - 因此我们能够弄清楚实际发生了什么以及贡献者等等。

让我们看看这些约定如何简化浏览：git log --oneline --grep "^feat\|^fix\|^perf"

我们对提交消息的类型进行过滤，因此仅显示生产环境的更改(所有以 feat、fix、 perf 开头的消息)。

另一个例子：git log --oneline --grep "^feat" | wc -l

我们只打印出 feat 类型变更的总数。

需要指出的是 - 提交消息的格式非常结构化，我们在浏览或过滤提交历史记录的时候可以有效的利用该格式。

简而言之，高效能！ 💪🏻

自动发布

提交信息的格式化对于自动执行发布过程的步骤同样有效。

事实上，这是有可能的，诸如 Standard Version  和  Semantic Release 等工具严格的遵循 Semantic Versioning 这一提交规范(Conventional Commits 和 Angular conventions respectively)。他们之间主要的区别在于方法，但是让我们把关注点放在语意发布上。

因此，基于提交信息(尤其是类型)- 语意发布能够：

切换至下一个语意包版本(当 fix 导致补丁，feat 和 perf 切换分支，以及明显的 - 切换到主进程)。

生成 CHANGLOG 文件并发布包含相关生产环境变更的说明。

为新版本创建 Git 标签。

发版和部署会排版至 npm 注册表中。

是不是非常酷呢？

例如， lonic 的angular-toolkit 项目，集成了Semantic Release 用于自动执行发布过程(因此遵循了 Angular 约定的提交)。

我们注意到，生成了带有正确的标签和说明的发行版 - 但这是自动完成的。 🤖

Miscellaneous

让我们看一些东西，用于充分利用语意提交方式。

使用表情符号

将表情符号附加到提交信息中可能会进一步提高可读性，因为这样我们可以在浏览历史提交记录中快速、轻松的识别它们。 💯

查看以下的链接：

CLI 工具

Commitizen 这种工具可以使用命令行强制格式化提交信息。

Linter

commitlint这种工具可以确保哪种提交信息格式符合约定。

VS Code 扩展工具

如果你想使用自定义的VS code 扩展名，你可能会对以下内容感兴趣。

Summary

今天我们通过遵循 Angular 提交信息约定的具体实例介绍了“语音提交”一词，并解释了此类消息的结构。

要点汇总：

语意提交是提交有意义信息，对于开发者和工具，都要遵循特定的约定。

语意提交(及其基于工具的帮助)可以增加可读性，效率和自动化程度。

常规提交是一种规范，详细说明了遵循轻量级约定的语意提交。

Angular 的指南详细说明了遵循项目约定的提交，包括：

一个格式化的信息包括 header、body 和 footer。

提交类型的不同，取决于是生产或者开发。

在浏览提交历史记录方面，我们可以方便的从约定的提交信息中获益。

针对自动发布，我们也可以从约定的提交信息中获益。

最后，无论你是否接受这样的约定 - 你都可能偶尔遇到它们，因此请记住以上几点。 😉