您的项目几乎应该总是使用过去时。无论如何，项目应始终使用相同的时态以保持一致性和清晰度。
我理解其他一些争论使用当前时态的论点，但它们通常不适用。以下要点是目前时态写作的常见论点，以及我的回答。
- 使用现在时书写可以告诉某人应用提交将执行的操作，而不是您执行的操作。
这是要使用现在时的最正确的理由，但只能使用正确的项目样式。这种思维方式将所有提交视为可选的改进或功能，您可以自由决定在特定存储库中保留哪些提交以及拒绝哪些提交。
如果您要处理的是真正的分布式项目，则此参数有效。如果要处理分布式项目，则可能正在开发一个开源项目。如果它真的是分布式的，那可能是一个非常大的项目。实际上，它可能是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个字符。话虽如此，现在的平均时态可能会短几个字符。
- 您可以在问题/功能跟踪器中与工单标题更一致地命名提交（不使用过去式，尽管有时是将来）
票证可以写为当前正在发生的事情（例如，当我单击此按钮时应用程序显示错误的行为），或者将来需要做的事情（例如，文本需要编辑人员审阅）。
历史记录（即提交消息）被写为过去所做的事情（例如，问题已解决）。