约定式提交不能拯救你的提交信息

在互联网上快速搜索会发现大量教你如何写提交信息的文章。这些文章中有 90% 告诉你要使用约定式提交。然而，许多开发者仍在为此挣扎。他们知道应该遵循这些约定，但在实践中应用它们很困难。每次提交代码时，他们都会纠结于到底是写“重构”还是“杂务”。我甚至见过一些项目的提交信息列表完全由相同的信息组成：“特性：添加页面”，因为对他们来说，写提交信息太具挑战性，他们干脆放弃了。

现在谈论约定式提交还为时尚早#

我不是说约定式提交不好。它们有许多众所周知的好处：

• 它们提供了统一的格式，使提交信息更加标准化
• 它们易于自动化工具解析，支持自动生成变更日志
• 它们帮助团队成员理解代码更改的目的和范围
• 它们允许快速识别不同类型的代码更改

然而，当开发者即使使用了约定式提交仍然难以写出好的提交信息时，仅仅向他们抛给一篇关于如何使用约定式提交的文章，教他们“feat”类型是什么意思，“fix”类型是什么意思，其实毫无意义。这就像没有教会某人如何使用基本材料和工具，就给他们一本高级食谱。但这样的文章在互联网上比比皆是。却鲜有人知道，只有当开发者有了清晰的思维和精准分割任务的能力时，约定式提交才能真正发挥作用。

所以，约定式提交不是不好，但在我们谈论它之前，我们需要建立正确的开发心态，并用科学的开发者思维来做事。

写好提交信息的关键思维#

代码更改应该一次做一件事情#

在软件开发中，“一次做一件事”是一个重要的原则。这不仅适用于写代码，也适用于提交代码。当我们专注于一次完成一个具体任务或更改时，我们的代码变得更清晰，我们的意图更明确。这个方法不仅提高了代码的可读性，还大大简化了代码审查过程。审查人员能够更容易地理解和核实每项更改的目的。

更重要的是，这种方法为潜在的代码回滚提供了便利。如果出现问题，我们可以更容易地定位和恢复特定的更改，而不会影响到其他无关的部分。最重要的是，当每个更改只做一件事情时，描述该更改的提交信息自然变得更加准确和有意义。

在实践中，这意味着我们在开始编码之前需要明确定义要完成的任务。在完成一个任务后，我们应该立即提交代码，而不是等到多个任务完成后再一起提交。如果我们在完成当前任务时发现其他需要修改的地方，最好的做法是记下来并在完成当前任务后单独处理这些修改。例如，当你正在实现一个功能时，发现了一些现有的错误，你不应该立刻在新功能代码中修复错误，而是应该先实现这个功能，然后在另一个提交中修复发现的错误，或者先修复错误再提交功能。

提交信息实际上在编写代码之前就存在#

许多开发者只有在完成代码之后才开始思考如何写提交信息，但实际上，提交信息应该在我们开始编码之前就存在。这是因为提交信息本质上反映了我们完成任务的步骤。换句话说，它们是我们的 todo 列表。

当我们开始一个任务时，首先应该思考完成此任务需要哪些具体步骤。这些步骤是我们的 todo 列表，同时也是我们未来的提交信息。有了这个 todo 列表，我们的每个代码更改都有一个明确的目的，让我们在编码时保持专注，防止偏离任务。

更重要的是，这种方法可以大大提高我们的效率。当我们完成一个步骤时，对应的提交信息已经准备好了，我们可以直接使用它，从而减少思考如何描述更改的时间。同时，由于这些提交信息是在我们对任务有一个全面了解时完成的，它们通常更高质量且信息更丰富。

假设你需要实现一个新的用户注册功能。你可以这样规划任务步骤：

1. 重构现有表单组件，使其更通用且可重用
2. 创建用户注册表单
3. 实现用户注册的 API 集成
4. 为用户注册功能添加单元测试
5. 更新用户注册功能的文档

这些任务步骤对应的提交信息可能是：

1. 重构：增强现有表单组件可重用性
2. 特性：创建用户注册表单
3. 特性：实现用户注册 API 集成
4. 测试：为用户注册添加单元测试
5. 文档：更新用户注册功能的文档

这样，在你开始编码之前，你就已经有了清晰的任务步骤和相应简洁的提交信息。这些提交信息实际上就是你的 todo 列表，引导你完成整个功能实现的过程。

当你完成每个步骤时，可以使用相应的提交信息来提交代码。这不仅帮助你更好地组织和执行任务，还确保每个提交都关注于一个特定的步骤，使整个开发过程更加清晰和可管理。如果在实际编码过程中需要对提交信息稍作调整，可以进行小幅修改以更准确地描述实际更改。

约定式提交成为自然选择#

当我们养成正确的开发心态后，使用约定式提交变得很自然。在这个阶段，你会发现选择适当的类型前缀（如 feat、fix、refactor 等）变得毫不费力，因为你的提交信息已经清楚地反映了你的任务步骤。

如果你想了解更多关于如何使用约定式提交，可以在网上找到许多优秀的文章。但请记住，这些标准只有在建立在正确的开发心态的基础上才能真正有效。

结论#

写好提交信息不仅仅是遵循某种格式。它需要我们在开发过程中保持清晰的思维，明确每次更改的目的，并在开始编码之前考虑如何描述我们的工作。

约定式提交确实是一个有用的工具，但只有与正确的开发心态相结合时才能发挥最大的效果。通过实践“一次做一件事”和“提前考虑提交信息”这两个原则，我们不仅可以提高提交信息的质量，还可以提高整体开发效率和代码质量。

我希望这篇文章能帮助你重新思考你的开发过程，并鼓励你尝试这些方法。记住，良好的开发习惯需要时间来培养，但一旦形成，它们将极大地提高你的工作效率和代码质量。