我应该在git commit消息中使用过去或现在式吗？
我读过一次 ，git commit消息应该是现在时态，例如“为x添加testing”。 我总是发现自己使用过去式，例如“为x添加testing”，这对我来说更自然。
以下是John Resig最近提交的一个消息：
在操作testing中调整一些更多的jQuery设置结果。 还修复了预期testing结果的顺序。
有关系吗？ 我应该用哪个？
现在时，命令式的提交消息的偏好来自Git本身。 从Git 仓库中的Documentation / SubmittingPatches ：
描述你在命令式的情绪上的变化，比如“make xyzzy do frotz”，而不是“这个补丁让xyzzy做frotz”或者“我改变了xyzzy做frotz”，就好像你正在命令代码库改变它行为。
所以你会看到很多用这种风格写的Git commit消息。 如果你在一个团队或开源软件上工作，如果每个人都坚持这种风格的一致性，这将是有帮助的。 即使你正在做一个私人项目，而且你是唯一一个能够看到你的git历史的人，那么使用必要的情绪会很有帮助，因为它build立了良好的习惯，当你和别人一起工作的时候，这些习惯会被人认识。
你的项目应该总是使用过去式 。 在任何情况下，项目应始终使用相同时态来保持一致性和清晰度。
我理解一些其他争论使用现在时的论据，但他们通常不适用。 下面的要点是用现在时的写法和我的回答的共同论点。
- 用现在时的写法告诉某人应用这个承诺会做什么 ，而不是你做了什么。
这是使用现在时的最正确的原因，但只有正确的项目风格。 这种思维方式将所有提交视为可选的改进或function，并且可以自由决定在特定存储库中保留哪些提交和哪些提交。
如果你正在处理一个真正的分布式项目，这个观点是有效的 如果您正在处理分布式项目，那么您可能正在开发一个开源项目。 如果它真的是分布式的，它可能是一个非常大的项目。 事实上，这可能是Linux内核或Git。 由于Linux很可能是Git传播和普及的原因，很容易理解为什么人们会认为它的风格是权威。 是的，这两个项目的风格是有意义的。 或者，一般来说，它可以与大型开源的分布式项目一起工作。
这就是说，大多数源代码控制项目不这样工作。 对于大多数存储库通常是不正确的。 这是一种对提交进行思考的现代方式：Subversion（SVN）和CVS存储库几乎不支持这种存储库签入方式。 通常，一个集成分支处理过滤错误的签入，但通常不被认为是“可选的”或“很好的特性”。
在大多数情况下，当您向源存储库提交时，您正在编写日志条目，描述此更新所做的更改，以便将来的其他人更容易理解为什么进行更改。 这通常不是一个可选的变化 – 项目中的其他人需要合并或重组。 你不要写日记，比如“亲爱的日记，今天我遇到一个男孩，他跟我打招呼”，而是写下“我遇见一个男孩，他跟我打招呼。”
最后，对于这样的非分布式项目，一个人读取提交信息的时间有99.99％是用于阅读历史的 – 历史是以过去式读取的。 0.01％的时间将决定他们是否应该应用此提交或将其集成到其分支/存储库中。
- 一致性。 这就是很多项目（包括git本身）的原因。 另外git工具生成提交（如混帐合并或git恢复）做到这一点。
不，我向你保证，大部分曾经login过版本控制系统的项目都有过去式（我没有参考，但考虑到现在时态是Git以来的新论点）。 现在时态的“修订”信息或提交信息在真正分布的项目中才开始有意义 – 参见上面的第一点。
- 人们不仅阅读历史来了解“这个代码库发生了什么”，而且还回答了“当我挑选这个提交时会发生什么”等问题，或者“由于这些提交，我的代码库会发生什么样的新事情我将来可能会也可能不会合并“。
看第一点。 99.99％的人读取提交信息的时间是阅读历史 – 历史是以过去式读取的。 0.01％的时间将决定他们是否应该应用此提交或将其集成到其分支/存储库中。 99.99％胜过0.01％。
- 通常比较短
我从来没有见过一个很好的说法，说使用不适当的时态/语法，因为它更短。 标准的50个字符的消息平均可能只保存3个字符。 也就是说，现在时态平均可能会缩短几个字。
- 您可以在问题/function跟踪器中更加一致地提交提交内容的标题（不使用过去式，尽pipe有时是将来的）
门票被写为当前正在发生的事情（例如，当我点击这个button时，应用程序显示错误的行为），或将来需要做的事情（例如，文本需要编辑审查）。
历史（即提交消息）被写为过去完成的事情（例如，问题是固定的）。
我写了一个关于365git的更全面的描述。
使用必要的，现在时是一个稍微习惯。 当我开始提到它时，遇到了阻力。 通常沿着“提交消息logging我已经完成”的行。 但是，Git是一个分布式版本控制系统，可能有很多地方可以从中进行更改。 而不是写消息说你做了什么; 考虑这些消息作为应用提交将执行的指令。 而不是有一个承诺的标题：
Renamed the iVars and removed the common prefix.有这样一个人：
Rename the iVars to remove the common prefix这告诉某人应用提交将做什么，而不是你做了什么。 另外，如果你看看你的版本库历史logging，你会看到Git生成的消息也是用这种时态写的 – “合并”而不是“合并”，“重新编译”而不是“重新编译”，所以用相同的时间写作保持一致。 起初感觉很奇怪，但它确实是有意义的（应用程序提供了certificate），并最终变得自然。
说了这么多 – 这是你的代码，你的存储库：所以build立你自己的指导方针并坚持下去。
但是，如果你决定这样做，那么用reword选项来
git rebase -i将是一件好事情。
坚持现在时态势在必行
- 有一个标准是很好的
- 它会在错误跟踪器中匹配自然具有“实现某些东西”，“修复某些东西”或“testing某些东西”的forms的故障单。
你在给谁写信息？ 那么读者通常是在阅读前或后的所有者自己拥有的提交信息？
我认为这里给出的答案都是从两个angular度来看的，我可能没有提出每个项目都有最好的答案。 分裂投票可能会表示同样多的。
即总结：
-
信息是否主要是针对其他人的，通常是在他们接受改变之前的某个时刻读取的：提出改变的方法将对现有的代码产生影响。
-
信息主要是作为你自己（或者你的团队）的期刊/logging，但是通常从已经接受变化和回顾发现事情的angular度来阅读。
也许这将导致你的团队/项目的动机，无论哪种方式。
有关系吗？ 人们通常足够聪明地正确地解释消息，如果他们不是，你可能不应该让他们访问您的资料库！
它是由你决定。 只要使用提交消息，如你所愿。 但是，如果不在时间和语言之间切换，则会更容易。
如果你在一个团队中发展，应该讨论和设定。
我想你可以自由地使用任何一个时态。 我甚至使用Present Present有时Adding feature X
