坚持使用现在时祈使句，因为

有一个标准是很好的 它与bug跟踪器中的票据相匹配，这些票据自然具有“实现某些东西”、“修复某些东西”或“测试某些东西”的形式。

坚持使用现在时祈使句，因为

有一个标准是很好的 它与bug跟踪器中的票据相匹配，这些票据自然具有“实现某些东西”、“修复某些东西”或“测试某些东西”的形式。

这取决于你。只要使用提交消息就可以了。 但如果你不需要在时间和语言之间切换，就会更容易。

如果你是在一个团队中开发，那么这个问题应该讨论并解决。

你的项目应该总是使用过去时。在任何情况下，项目都应该使用相同的时态来保持一致性和清晰度。

我理解其他一些主张使用现在时的论点，但它们通常不适用。以下是常用的现在时写作的理由，以及我的回答。

用现在时写作告诉某人应用commit将做什么，而不是你做了什么。

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

This argument works if you are dealing with a truly distributed project. If you are dealing with a distributed project, you are probably working on an open source project. And it is probably a very large project if it is really distributed. In fact, it's probably either the Linux kernel or Git. Since Linux is likely what caused Git to spread and gain in popularity, it's easy to understand why people would consider its style the authority. Yes, the style makes sense with those two projects. Or, in general, it works with large, open source, distributed projects.

话虽如此，大多数版本控制中的项目都不是这样工作的。对于大多数存储库来说，这通常是不正确的。这是一种考虑提交的现代方式:Subversion (SVN)和CVS存储库几乎不支持这种类型的存储库签入。通常集成分支处理过滤坏的签入，但那些通常不被认为是“可选的”或“不错的特性”。

In most scenarios, when you are making commits to a source repository, you are writing a journal entry which describes what changed with this update, to make it easier for others in the future to understand why a change was made. It generally isn't an optional change - other people in the project are required to either merge or rebase on it. You don't write a diary entry such as "Dear diary, today I meet a boy and he says hello to me.", but instead you write "I met a boy and he said hello to me."

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

一致性。这就是许多项目(包括git本身)中的情况。生成提交的git工具(如git merge或git revert)也会这样做。

不，我向你保证，在版本控制系统中登录的大多数项目都有过去时的历史(我没有参考文献，但这可能是对的，考虑到现在时的参数是Git以来的新参数)。“修订”消息或现在时态的提交消息只在真正的分布式项目中开始有意义——参见上面的第一点。

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

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

通常比较短

我从来没有见过一个好的论点说使用不恰当的时态/语法，因为它更短。对于标准的50个字符的消息，你可能平均只保存3个字符。也就是说，一般现在时可能会短几个字。

你可以在你的问题/特性跟踪器中更一致地命名提交(不使用过去时，尽管有时使用将来时)。

罚单要么是当前正在发生的事情(例如，当我点击这个按钮时，应用程序显示了错误的行为)，要么是未来需要做的事情(例如，文本需要编辑审查)。

历史记录(即提交消息)被写入过去所做的事情(例如，问题已被修复)。

我对365git写了更详细的描述。

The use of the imperative, present tense is one that takes a little getting used to. When I started mentioning it, it was met with resistance. Usually along the lines of “The commit message records what I have done”. But, Git is a distributed version control system where there are potentially many places to get changes from. Rather than writing messages that say what you’ve done; consider these messages as the instructions for what applying the commit will do. Rather than having a commit with the title: Renamed the iVars and removed the common prefix. Have one like this: Rename the iVars to remove the common prefix Which tells someone what applying the commit will do, rather than what you did. Also, if you look at your repository history you will see that the Git generated messages are written in this tense as well - “Merge” not “Merged”, “Rebase” not “Rebased” so writing in the same tense keeps things consistent. It feels strange at first but it does make sense (testimonials available upon application) and eventually becomes natural. Having said all that - it’s your code, your repository: so set up your own guidelines and stick to them. If, however, you do decide to go this way then git rebase -i with the reword option would be a good thing to look into.

你在给谁写信?读者通常是在自己拥有所有权之前还是之后阅读消息?

我认为从两个角度都给出了很好的答案，我可能只是没有建议每个项目都有一个最佳答案。这次分裂的投票可能也说明了这一点。

即总结如下:

消息主要是给其他人的，通常是在他们假设更改之前的某个时候阅读的:对现有代码进行更改会产生什么影响的建议。 信息主要是作为日志/记录给你自己(或你的团队)，但通常是从假设变化的角度来阅读，并回溯发现发生了什么。

不管怎样，这可能会为你的团队/项目带来动力。