我应该在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