The preference for present-tense, imperative-style commit messages comes from Git itself. From Documentation/SubmittingPatches in the Git repo:
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.
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.
如果您正在处理真正的分布式项目，那么这个论点就有效。如果您正在处理分布式项目，那么您可能正在处理开源项目。而且如果真的分布式的话，可能是一个非常大的项目。事实上，它可能是 Linux 内核或 Git。由于 Linux 很可能是 Git 传播和流行的原因，因此很容易理解为什么人们会认为它的风格具有权威性。是的，这两个项目的风格很有意义。或者，一般来说，它适用于大型、开源、分布式项目。
Your project should almost always use 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 usually don'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, distributed projects.
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".
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."
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.
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.
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.
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%.
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.
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 showing the wrong behavior when I click this button), or something that needs to be done in the future (e.g. the text will need a review by the editor).
History (i.e. commit messages) is written as something that was done in the past (e.g. the problem was fixed).
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.
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.
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!
发布评论
评论（7）
对现在时、命令式提交消息的偏好来自 Git 本身。来自 文档/SubmittingPatches< /a> 在 Git 存储库中：
所以你会看到很多以这种风格编写的 Git 提交消息。如果您在团队中工作或在开源软件上工作，那么每个人都坚持这种风格以保持一致性会很有帮助。即使您正在开发一个私人项目，并且您是唯一一个能够看到您的 git 历史记录的人，使用命令语气也会很有帮助，因为它会建立良好的习惯，当您与其他人一起工作时，这些习惯会受到赞赏。
The preference for present-tense, imperative-style commit messages comes from Git itself. From Documentation/SubmittingPatches in the Git repo:
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.
您的项目应该几乎总是使用过去时。无论如何，项目应始终使用相同的时态，以保持一致性和清晰度。
我理解其他一些主张使用现在时的论点，但它们通常不适用。以下要点是用现在时写作的常见论点以及我的回应。
这是人们想要使用现在时的最正确原因，但前提是项目风格正确。这种思维方式将所有提交视为可选的改进或功能，您可以自由决定在特定存储库中保留哪些提交以及拒绝哪些提交。
如果您正在处理真正的分布式项目，那么这个论点就有效。如果您正在处理分布式项目，那么您可能正在处理开源项目。而且如果真的分布式的话，可能是一个非常大的项目。事实上，它可能是 Linux 内核或 Git。由于 Linux 很可能是 Git 传播和流行的原因，因此很容易理解为什么人们会认为它的风格具有权威性。是的，这两个项目的风格很有意义。或者，一般来说，它适用于大型、开源、分布式项目。
话虽如此，大多数源代码控制项目并不是这样工作的。对于大多数存储库来说，它通常是不正确的。这是一种思考提交的现代方式：Subversion (SVN) 和 CVS 存储库几乎无法支持这种类型的存储库签入。通常，集成分支会处理过滤不良签入的问题，但这些通常不被视为“可选”或“值得拥有的功能”。
在大多数情况下，当您向源存储库进行提交时，您正在编写一个日志条目来描述此更新所更改的内容，以便其他人将来更容易理解为何进行更改。它通常不是一个可选的更改 - 项目中的其他人需要合并或重新建立基础。您不会写诸如“亲爱的日记，今天我遇到一个男孩，他向我打招呼。”这样的日记条目，而是写“我” >遇到一个男孩，他向我打招呼。”
最后，对于此类非分布式项目，人们阅读提交消息的 99.99% 时间都是为了阅读历史记录 - 历史记录是用过去时态读取的。 0.01% 的时间将决定他们是否应该应用此提交或将其集成到他们的分支/存储库中。
不，我向你保证，大多数曾经登录过版本控制系统的项目都有过去时态的历史（我没有参考资料，但这可能是对的，考虑到现在时态的说法自 Git 以来是新的）。现在时的“修订”消息或提交消息只有在真正的分布式项目中才开始有意义 - 请参阅上面的第一点。
参见第一点。一个人阅读提交消息的 99.99% 的时间都是为了阅读历史 - 历史是以过去时态阅读的。 0.01% 的时间将决定他们是否应该应用此提交或将其集成到他们的分支/存储库中。 99.99% 胜过 0.01%。
我从来没有见过一个好的论点说使用不正确的时态/语法，因为它更短。对于标准的 50 个字符的消息，您可能平均只能节省 3 个字符。话虽这么说，现在时态平均可能会短几个字符。
票证可以写为当前正在发生的事情（例如应用程序正在显示 单击此按钮时的错误行为），或将来需要完成的操作（例如，文本将需要由编辑器审阅）。
历史记录（即提交消息）被写为过去完成的事情（例如问题已已修复）。
Your project should almost always use 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 usually don't apply. The following bullet points are common arguments for writing in the present tense, and my response.
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, distributed projects.
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".
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."
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.
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.
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%.
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.
Tickets are written as either something that is currently happening (e.g. the app is showing the wrong behavior when I click this button), or something that needs to be done in the future (e.g. the text will need a review by the editor).
History (i.e. commit messages) is written as something that was done in the past (e.g. the problem was fixed).
我在 365git 上写了更完整的描述。
I wrote a fuller description on 365git.
坚持使用现在时势在必行，因为
Stick with the present tense imperative because
您为谁写这条消息？该读者通常是在拥有提交之前还是之后阅读消息？
我认为这里从两个角度都给出了很好的答案，我可能无法建议每个项目都有一个最佳答案。分裂投票可能也表明了这一点。
即总结一下：
该消息是否主要针对其他人，通常在他们进行更改之前的某个时候阅读：关于进行更改将对他们现有代码产生什么影响的建议。
该消息主要是作为您自己（或您的团队）的日记/记录，但通常是从假设发生变化并回溯以发现发生了什么的角度进行阅读。
不管怎样，这也许会激发你的团队/项目的动力。
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.
这有关系吗？人们通常足够聪明，能够正确解释消息，如果他们不聪明，您可能无论如何都不应该让他们访问您的存储库！
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!
这取决于你。只需根据需要使用提交消息即可。
但如果您不在时间和语言之间切换，那就更容易了。
如果您在团队中开发，则应该对其进行讨论并进行修复。
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.