624

我曾经读过git commit 消息应该是命令式现在时，例如“为 x 添加测试”。我总是发现自己使用过去时，例如“为 x 添加测试”，这对我来说感觉更自然。

这是最近的 John Resig 提交，在一条消息中显示了两者：

在操作测试中调整更多 jQuery 集结果。还修复了预期测试结果的顺序。

有关系吗？我应该使用哪个？

4

7 回答 7

709

对现在时、命令式提交消息的偏好来自 Git 本身。来自Git repo 中的Documentation/SubmittingPatches ：

用命令式语气描述你的变化，例如“make xyzzy do frotz”而不是“[This patch] makes xyzzy do frotz”或“[I] changed xyzzy to do frotz”，就好像你正在命令代码库改变它行为。

所以你会看到很多以这种风格编写的 Git 提交消息。如果你在一个团队或开源软件上工作，如果每个人都坚持这种风格以保持一致性，那将会很有帮助。即使您正在从事一个私人项目，并且您是唯一一个会看到您的 git 历史的人，使用命令式情绪也是有帮助的，因为它建立了良好的习惯，当您与他人一起工作时会受到赞赏。

于 2010-08-27T01:42:01.677 回答
402

您的项目应该几乎总是使用过去时。无论如何，项目应始终使用相同的时态以保持一致性和清晰性。

我理解其他一些争论使用现在时的论点，但它们通常不适用。以下要点是用现在时写作的常见论据，以及我的回应。

  • 用现在时写作告诉别人应用提交会做什么，而不是你做了什么。

这是人们想要使用现在时的最正确原因，但只能使用正确的项目风格。这种思维方式将所有提交视为可选的改进或功能，您可以自由决定在您的特定存储库中保留哪些提交以及拒绝哪些提交。

如果您正在处理一个真正分布式的项目，则此论点有效。如果您正在处理一个分布式项目，那么您可能正在处理一个开源项目。而且如果真的是分布式的，可能是一个非常大的项目。事实上，它可能是 Linux 内核或 Git。由于 Linux 可能是导致 Git 传播和普及的原因，因此很容易理解为什么人们会认为它的风格是权威。是的，这两个项目的风格很有意义。或者，一般来说，它适用于大型、开源、分布式项目。

话虽如此，源代码控制中的大多数项目都不是这样工作的。对于大多数存储库来说，它通常是不正确的。这是考虑提交的一种现代方式：Subversion (SVN) 和 CVS 存储库几乎无法支持这种存储库签入方式。通常集成分支会处理过滤错误签入，但这些通常不被视为“可选”或“不错的功能”。

在大多数情况下，当您提交到源存储库时，您正在编写一个日志条目，描述此更新的更改内容，以便将来其他人更容易理解为什么进行更改。它通常不是可选的更改 - 项目中的其他人需要合并或重新设置它。您不会写诸如“亲爱的日记，今天我遇到一个男孩，他向我问好。 ”之类的日记条目，而是写“我遇到了一个男孩，他向我问好”。

最后，对于此类非分布式项目，一个人阅读提交消息的 99.99% 时间是为了阅读历史——历史是用过去时态阅读的。0.01% 的时间将决定他们是否应该应用此提交或将其集成到他们的分支/存储库中。

  • 一致性。这就是许多项目（包括 git 本身）的情况。生成提交的 git 工具（如 git merge 或 git revert）也可以做到这一点。

不，我向你保证，大多数登录版本控制系统的项目都有过去时的历史（我没有参考资料，但考虑到现在时态参数自 Git 以来是新的，这可能是正确的）。现在时的“修订”消息或提交消息仅在真正分布式项目中才开始有意义 - 请参阅上面的第一点。

  • 人们不仅阅读历史以了解“这个代码库发生了什么”，而且还回答诸如“当我挑选这个提交时会发生什么”或“由于这些提交我的代码库会发生什么样的新事情”之类的问题我将来可能会也可能不会合并”。

见第一点。99.99% 的人阅读提交信息的时间是为了阅读历史——历史是用过去时态阅读的。0.01% 的时间将决定他们是否应该应用此提交或将其集成到他们的分支/存储库中。99.99% 优于 0.01%。

  • 它通常更短

我从来没有见过一个很好的论点说使用不正确的时态/语法，因为它更短。对于 50 个字符的标准消息，您可能平均只节省 3 个字符。话虽如此，现在时态平均可能会短几个字符。

  • 您可以使用问题/功能跟踪器中的票证标题更一致地命名提交（不使用过去时，尽管有时是将来时）

工单被写成当前正在发生的事情（例如，当我单击此按钮时应用程序显示错误行为），或者将来需要完成的事情（例如，文本需要编辑器审核）。

历史（即提交消息）被写成过去做过的事情（例如问题已解决）。

于 2011-11-09T00:59:10.803 回答
89

我在365git上写了更完整的描述。

命令式现在时的使用需要一点时间来适应。当我开始提到它时，它遭到了抵制。通常按照“提交消息记录我所做的事情”的方式。但是，Git 是一个分布式版本控制系统，可能有很多地方可以从中获取更改。而不是写消息说你做了什么；将这些消息视为应用提交的说明。而不是提交标题：

Renamed the iVars and removed the common prefix.

有一个这样的：

Rename the iVars to remove the common prefix

这告诉某人应用提交会做什么，而不是你做了什么。此外，如果您查看您的存储库历史记录，您会发现 Git 生成的消息也是以这种时态编写的——“Merge”而不是“Merged”，“Rebase”而不是“Rebase”，因此以相同的时态编写可以保持一致。起初感觉很奇怪，但它确实有意义（应用时提供推荐）并最终变得自然。

说了这么多 - 这是你的代码，你的存储库：所以设置你自己的指导方针并坚持下去。

但是，如果您确实决定采用这种方式，那么git rebase -i使用 reword 选项将是一件好事。

于 2011-02-15T13:10:26.407 回答
40

坚持现在时祈使句，因为

  • 有标准就好
  • 它匹配错误跟踪器中自然具有“实施某事”、“修复某事”或“测试某事”形式的票证。
于 2010-11-30T16:26:07.383 回答
20

你在为谁写信？并且该读者通常会在提交所有权之前或之后阅读消息吗？

我认为这里已经从两个角度给出了很好的答案，我可能只是没有建议每个项目都有一个最佳答案。分裂投票可能暗示同样多。

即总结：

  • 信息是否主要针对其他人，通常在他们承担更改之前的某个时间点阅读：关于进行更改将对他们现有代码产生什么影响的建议。

  • 消息是否主要作为给您自己（或您的团队）的日记/记录，但通常是从假设发生变化并回溯以发现发生了什么的角度阅读。

无论哪种方式，也许这都会激发您的团队/项目的动力。

于 2013-03-29T11:01:24.190 回答
13

有关系吗？人们通常足够聪明，可以正确解释消息，如果不是，您可能不应该让他们访问您的存储库！

于 2010-08-26T22:27:09.530 回答
10

它是由你决定。只需根据需要使用提交消息。但是，如果您不在时间和语言之间切换，那就更容易了。

如果你在一个团队中开发 - 它应该被讨论并固定。

于 2010-08-26T22:24:03.227 回答