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

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

即总结如下:

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

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

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

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

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

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

这重要吗?人们通常足够聪明，可以正确地解释消息，如果他们不是，你可能不应该让他们访问你的存储库!

我对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.

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

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

即总结如下:

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

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