我曾经读过一篇文章，说git提交信息应该使用现在时的祈使语态，例如"Add tests for x"。然而，我总是使用过去时，例如"Added tests for x"，这对我来说感觉更自然。
以下是最近John Resig的一次提交记录，其中包含两种不同的提交信息：
Tweak some more jQuery set results in the manipulation tests. Also fixed the order of the expected test results.
这有关紧要吗？我应该使用哪个？
你的项目应该 几乎总是 使用过去式。无论如何，为了保持一致性和清晰度，项目应始终使用相同的时态。
我理解一些其他人提出使用现在时态的论点，但它们通常不适用。以下是写在现在时态中的常见论点以及我的回应。
这是使用现在时态的最正确的原因，但只适用于特定类型的项目。这种思考方式将所有提交(commit)都视为可选的改进或功能，您可以自由决定在特定存储库中保留哪些提交(commit)，并拒绝哪些提交(commit)。
如果您正在处理真正分布式的项目，则此论点有效。如果您正在处理分布式项目，则可能正在处理开源项目。如果真的是一个非常大的项目，那么这可能是Linux内核或Git。由于Linux很可能是引起Git传播和流行的原因，因此很容易理解为什么人们认为其风格具有权威性。是的，这种风格在这两个项目中很有意义。或者，一般来说，它适用于大型、开源、分布式项目。
尽管如此，大多数源代码控制的项目不是这样工作的。对于大多数存储库而言，通常是不正确的。这是提交的现代思考方式：Subversion(SVN)和CVS存储库几乎无法支持这种存储库检入(check-in)样式。通常，集成分支处理过滤掉的错误检入(check-in)，但这些通常被认为不是“可选”或“好玩”的功能。
在大多数情况下，当您向源代码库提交更改时，您正在撰写一篇日志记录，描述这次更新的变化，以便其他人在将来更容易理解为什么进行了更改。这通常不是可选的更改 - 项目中的其他人需要合并或基于它进行重置。你不会写一个像“亲爱的日记，今天我见到了一个男孩，他向我打招呼”这样的日记记录，而是写“我遇到了一个男孩，他向我打招呼。”我从未见过一个好的论点，认为使用不恰当的时态/语法因为它更短。对于标准的50个字符的消息，你可能只会平均节省3个字符。话虽如此，现在时态平均来说可能会少几个字符。
问题被写成正在发生的事情（例如，应用正在显示错误行为），或者需要在未来完成的事情（例如，文本将需要编辑审查）。
历史记录（即提交消息）是以过去完成的事情作为基础编写的（例如，问题已经被修复）。
我在365git上写了一篇更详细的描述。
使用祈使句和现在时态需要一点适应时间。当我开始提起这个问题时，会遇到一些抵制。通常是“提交记录应该记录我的操作”。但是，Git是一个分布式版本控制系统，有很多地方可以获取更改。与其编写记录你做了什么的消息；考虑把这些消息作为应用提交的指令。因此，不要使用下面标题的提交：
重命名iVars并去除公共前缀使用如下标题：
将iVars重命名以去除公共前缀这样可以告诉使用者应用提交后会发生什么而不是你做了什么。此外，如果查看存储库历史记录，可以看到Git生成的消息也是使用这种时态的-“合并”而不是“已合并”，“变基”而不是“已变基”，所以使用相同的时态可以保持一致性。虽然一开始感觉奇怪，但它确实有道理（可以提供证明），并且最终会变得自然。
话虽如此-这是你的代码，你的存储库：因此请设置自己的指南并坚持遵守。
如果您决定采用这种方法，可以考虑使用具有重命名选项的
git rebase -i。
坚持使用现在时的祈使句，因为
你写这条信息给谁？那个读者通常是在提交代码之前还是之后阅读这条信息的？
我认为从两个角度都给出了好的答案，但可能不会建议对于每个项目都有最佳答案。投票结果可能暗示了这一点。
即总结如下：
这条信息主要是给其他人的，通常是在他们假定更改之前某个时间阅读的：关于采取变化会对他们现有的代码产生什么影响的提议。
这条信息主要是作为自己（或团队）的日志/记录，但通常是从假定更改的角度阅读并回顾发生了什么。
也许这将引导您的团队/项目的动力。
重要吗？人们通常足够聪明，能正确解释消息。如果他们不能理解，你也不应该让他们访问你的存储库！
由您决定。只需按照您的意愿使用提交信息即可。 但是，如果您不在时间和语言之间切换，那么这将更容易。
如果您是团队开发，请进行讨论并设置固定规则。
