我应该在 git commit 消息中使用过去时还是现在时？

Should I use past or present tense in git commit messages?

提问by Skilldrick

I read oncethat git commit messages should be in the imperative present tense, e.g. "Add tests for x". I always find myself using the past tense, e.g. "Added tests for x" though, which feels a lot more natural to me.

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

Here's a recent John Resig commitshowing the two in one message:

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

Tweak some more jQuery set results in the manipulation tests. Also fixed the order of the expected test results.

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

Does it matter? Which should I use?

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

回答by mipadi

The preference for present-tense, imperative-style commit messages comes from Git itself. From Documentation/SubmittingPatchesin the Git repo:

对现在时、命令式提交消息的偏好来自 Git 本身。来自Git 存储库中的文档/提交补丁：

Describe your changes in imperative mood, e.g. "make xyzzy do frotz" instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz", as if you are giving orders to the codebase to change its behavior.

描述你在命令式情绪中的变化，例如“让 xyzzy 做 frotz”而不是“[这个补丁]让 xyzzy 做 frotz”或“[我]改变了 xyzzy 来做 frotz”，就好像你在命令代码库改变它的行为。

So you'll see a lot of Git commit messages written in that style. If you're working on a team or on open source software, it is helpful if everyone sticks to that style for consistency. Even if you're working on a private project, and you're the only one who will ever see your git history, it's helpful to use the imperative mood because it establishes good habits that will be appreciated when you're working with others.

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

回答by Matt Quigley

Your project should almost alwaysuse the past tense. In any case, the project should always use the same tense for consistency and clarity.

您的项目应该几乎总是使用过去时。在任何情况下，项目都应始终使用相同的时态以保持一致性和清晰性。

I understand some of the other arguments arguing to use the present tense, but they usuallydon't apply. The following bullet points are common arguments for writing in the present tense, and my response.

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

• Writing in the present tense tells someone what applying the commit will do, rather than what you did.

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

This is the most correct reason one would want to use the present tense, but only with the right style of project. This manner of thinking considers all commits as optional improvements or features, and you are free to decide which commits to keep and which to reject in your particular repository.

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

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, distributedprojects.

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

That being said, most projects in source control do not work like this. It is usually incorrect for most repositories. It's a modern way of thinking about a commits: Subversion (SVN) and CVS repositories could barely support this style of repository check-ins. Usually an integration branch handled filtering bad check-ins, but those generally weren't considered "optional" or "nice-to-have features".

话虽如此，源代码控制中的大多数项目都不是这样工作的。对于大多数存储库来说，它通常是不正确的。这是考虑提交的现代方式：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 meeta boy and he sayshello to me.", but instead you write "I meta boy and he saidhello to me."

在大多数情况下，当您对源存储库进行提交时，您正在编写一个日志条目来描述此更新的更改内容，以便将来其他人更容易理解更改的原因。它通常不是可选的更改 - 项目中的其他人需要合并或基于它。你不写日记，如“亲爱的日记，今天我满足一个男孩和他说我打招呼。”，而是你写“我遇到了一个男孩，他说我打招呼。”

Finally, for such non-distributed projects, 99.99% of the time a person will be reading a commit message is for reading history - history is read in the past tense. 0.01% of the time it will be deciding whether or not they should apply this commit or integrate it into their branch/repository.

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

• Consistency. That's how it is in many projects (including git itself). Also git tools that generate commits (like git merge or git revert) do it.

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

No, I guarantee you that the majority of projects ever logged in a version control system have had their history in the past tense (I don't have references, but it's probably right, considering the present tense argument is new since Git). "Revision" messages or commit messages in the present tense only started making sense in truly distributed projects - see the first point above.

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

• People not only read history to know "what happened to this codebase", but also to answer questions like "what happens when I cherry-pick this commit", or "what kind of new things will happen to my code base because of these commits I may or may not merge in the future".

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

See the first point. 99.99% of the time a person will be reading a commit message is for reading history - history is read in the past tense. 0.01% of the time it will be deciding whether or not they should apply this commit or integrate it into their branch/repository. 99.99% beats 0.01%.

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

• It's usually shorter

• 它通常更短

I've never seen a good argument that says use improper tense/grammar because it's shorter. You'll probably only save 3 characters on average for a standard 50 character message. That being said, the present tense on average will probably be a few characters shorter.

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

• You can name commits more consistently with titles of tickets in your issue/feature tracker (which don't use past tense, although sometimes future)

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

Tickets are written as either something that is currently happening (e.g. the app is showingthe wrong behavior when I click this button), or something that needs to be done in the future (e.g. the text will needa review by the editor).

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

History (i.e. commit messages) is written as something that was done in the past (e.g. the problem wasfixed).

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

回答by Abizern

I wrote a fuller description on 365git.

我在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 -iwith the reword option would be a good thing to look into.

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

Renamed the iVars and removed the common prefix.

有一个这样的：

Rename the iVars to remove the common prefix

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

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

但是，如果您确实决定采用这种方式，那么git rebase -i使用改写选项将是一件值得研究的好事情。

回答by Craig P. Motlin

Stick with the present tense imperative because

坚持现在时的命令式，因为

• it's good to have a standard
• it matches tickets in the bug tracker which naturally have the form "implement something", "fix something", or "test something."

• 有标准是件好事
• 它匹配错误跟踪器中自然具有“实现某事”、“修复某事”或“测试某事”形式的票证。

回答by wardw

Who are you writing the message for? And is that reader typically reading the message pre- or post- ownership the commit themselves?

你为谁写信息？那个读者通常是在提交自己之前或之后阅读消息吗？

I think good answers here have been given from both perspectives, I'd perhaps just fall short of suggesting there is a best answer for every project. The split vote might suggest as much.

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

i.e. to summarise:

即总结：

• Is the message predominantly for other people, typically reading at some point before they have assumed the change: A proposal of what taking the change will do to their existing code.

• Is the message predominantly as a journal/record to yourself (or to your team), but typically reading from the perspective of having assumed the change and searching back to discover what happened.

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

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

Perhaps this will lead the motivation for your team/project, either way.

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

回答by Michael Baldry

does it matter? people are generally smart enough to interpret messages correctly, if they aren't you probably shouldn't let them access your repository anyway!

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

回答by Andreas Rehm

It is up to you. Just use the commit message as you wish. But it is easier if you are not switching between times and languages.

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

And if you develop in a team - it should be discussed and set fixed.

如果你在一个团队中发展 - 应该讨论并修复它。