一次提交一个项目，讲述项目的故事

你的提交信息可以讲述一个故事，也可以是垃圾，由你选择

提交信息是在代码修改前添加的信息，你可以在git仓库的历史上看到；听起来很简单，但为什么每个人都对它有如此强烈的感觉。

就我所知，提交信息有两种类型，一种是信息量大、写得好的信息，另一种是 "这里有些改动...... "的信息。

在我和其他许多人看来，拥有清晰的提交信息是我们应该追求的目标，因为它提供了项目中所有变化的透明度。在某种程度上，它是一种简单的记录形式，甚至可以使你成为一个更好的开发者。

关于清晰翔实的提交消息的重要性

在继续讨论如何写好提交信息，甚至与你分享我的提交信息方法之前，让我解释一下为什么在你的项目历史中拥有清晰的提交描述是至关重要的。

我将着重从不同的角度解释提交信息的重要性。

代码审查员

我做过几年的技术负责人，我的部分工作是在多个远程团队中进行代码审查，这些团队距离我有10000多公里，相差10小时。有的时候，我到了办公室会发现一个相当长的PR，是几个开发人员几天的工作，有几百行的代码受到影响，每一个提交都会说 "修复"、"更多的修复"、"这里的修改"、"提交 "之类的话。

除了明显的因素（我不打算讨论为什么PR这么大），当我试着去做的时候，我有很多很多的问题，我不能马上问，因为我的团队已经在家里睡觉了（由于时差的关系）。所以我就坐在那里，试图了解发生了什么，并试图从他们的提交历史中找出变化的过程，以便更清楚地了解发生了什么。

对于像我前面提到的那些提交，这是不可能的，我没有机会，我会以最好的方式审查代码，然后留下评论，让团队第二天再来澄清。这样做的效率很低。

然而，信不信由你，在对我们提交的方式做了一些改变后，通过利用我在文章中详述的系统，我们使代码审查过程的效率提高了许多倍。

新加入者

由于团队设置的性质，我们有一些远程团队成员之间的高度轮换；同样，我不会费力地去解释为什么这只是我们不得不接受的事情。我们的代码库对于团队的规模来说是相当庞大的，对于新加入的人来说是相当可怕的，尤其是对于那些经验不足的开发者来说。我们总是有人帮助他们融入团队，有人在他们的时区，但这并不是一件容易的事。

访问git历史可以帮助任何开发者了解一个特定的页面、服务、文件或方法是如何演变的，或者它可以帮助了解为什么有些东西被添加，或者有些东西何时被删除。但是，在 "修复"、"这里有一些文字"、"没有消息 "的世界中导航可能是非常困难的。

这听起来可能不是很多，但对于所有像我这样在第一次开始工作时就打开项目的git历史的人来说，它有很大的帮助

开发者

是的，有好的提交信息可以帮助你平步青云!有时我们会遇到这样的问题：为什么这个按钮不在这里了，或者那个东西是什么时候被删除或添加的？而我们经常会找一些谈论这个问题的用户故事。但它并不总是在那里，有时我们不小心删除了一些东西，或者我们在Jira或Azure DevOps等工具中添加了一些难以找到的东西。然而，在代码和提交历史中可以超级容易地找到。所以，给自己留点时间，创造出令人惊奇的提交!

我相信还有更多的提交信息可以提供帮助，如果你知道的话，请在评论区告诉我。

提交信息的三种不同工作流程

在我多年工作的团队中，我发现了三种处理提交信息的方法，有趣的是，它们可以成为你的团队从一个类别到另一个类别的步骤，直到你的代码历史看起来像一本艾伦-埃德加-坡的小说。

谁在乎呢？

第一步是那些不太关心的团队，或者他们没有意识到提交信息的重要性，他们只是把他们想要的东西放在那里。

你想提交什么就提交什么，我们在合并的时候会压制提交的内容

有些团队明白提交信息的重要性。但仍有开发者不愿意为写好的提交信息而烦恼，所以他们想提交什么就提交什么，但他们会在PR上提供描述性的评论。这些团队通常会压制提交，所以当你看到历史记录时，你只能看到写在PR上的清晰信息。这样做的好处是，你有一个干净的提交历史；缺点是，任何发生在特性分支上的提交都会消失。

这种方法并不坏，我也很喜欢，肯定比第一阶段要好，但是，审查PR的人不会得到清晰的提交信息的增值，有价值的信息可能会从项目历史中被遗漏。

每条提交信息都很重要

在这一点上，你的团队中的每个开发人员都会写出清晰而有信息量的提交信息，这在代码审查过程中是很有帮助的，而且你不必压制提交，因此你可以访问你的完整项目历史。

不过这可能有点危险，因为你的历史可能会根据开发人员的提交频率而大幅增长。

我的优秀提交信息公式

提交信息的格式

每条提交信息都包括一个页眉、一个正文和一个页脚。头部有一个特殊的格式，包括一个类型、一个范围和一个主题。

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

页眉是必须的，页眉的范围是可选的。

撤销

如果该提交是为了恢复之前的提交，它应该以 "revert: "开头，然后是被恢复的提交的页眉。在正文中，它应该说："它恢复了提交。"，其中哈希值是被恢复的提交的SHA。

类型

必须是以下类型之一：

构建：影响构建系统或外部依赖的变化（例如范围：gulp、broccoli、npm)
ci：对我们的CI配置文件和脚本的修改（例子范围：Circle、BrowserStack、SauceLabs）。
docs。只对文档进行修改
feat:一个新的功能
修复：一个错误修复
perf: 一个可以提高性能的代码修改
重构(refactor)。既不修复错误也不增加功能的代码修改
风格：不影响代码含义的改变（白字、格式化、缺少分号等）。
测试：增加缺失的测试或纠正现有的测试

范围

范围应该是受影响的npm包的名称或模块或组件的名称。

主题

主题包含对变化的简短描述：

使用祈使句，现在时："改变"，而不是 "改变 "或 "改变"
不要将第一个字母大写
结尾不加点（.）。

身体

与主语一样，使用祈使句、现在时："改变"，而不是 "改变 "或 "变化"。主体应包括改变的动机，并将其与以前的行为进行对比。

页脚

页脚应该包含所有关于Breaking Changes的信息，同时也是用Closes或Reference来引用该提交的问题的地方。

突破性变化应该以 BREAKING CHANGE: 字样开始，并加上空格或两个新行。

例子

feat(Subscriptions): Support permission-based subscriptions

Update the audience object to support permission-based

References: #XXXXXX

总结

Git 历史是一个非常有价值的工具。然而，有时我们并不清楚什么是 "好 "的提交信息，什么是 "坏 "的提交信息。另外，我提供的解决方案不一定是最适合你们团队的。这是我提出的解决方案，无论我走到哪里都会尝试实施，而且没有什么已经到位的。要有灵活性；重要的一点是，无论你以何种方式实现，清晰的历史都很重要。

非常感谢你的阅读!

用一个承诺讲述你的项目的故事