应该使用现在还是过去式来编写提交消息?

那么你认为哪个更好,更直观?

Fixed the XXX bug in YYY Fix the XXX bug in YYY Fixes the XXX bug in YYY Fixing the XXX bug in YYY 

请提供您的理由。 注意:从总的angular度来看,我并不是想要把它和你喜欢的svn / cvs工具或者编程语言联系起来,而是把它看作是应该/可以应用于任何工具和编程语言的东西。

我想这些消息,因为他们看起来像其他开发人员。 他们还没有应用这些变化,还有一个隐含的问题:“应用这个变更集/补丁程序会做什么?” 它会“修复YYY的XXX错误”!

对于其他动词来说,将它们作为命令看起来更自然,而且如果事先有一个特定的目标,则效果会更好 – 在完成工作之前,可以从字面上将提交摘要和前期testing一起写出来。

我没有把它放在很大的重量上,但对我来说,这是保持一致性的最小阻力的道路。

我个人去过去式(“固定”),因为当我到了犯错误是固定的(或者我不会承诺)。

我更喜欢看现在时态的提交信息。 这样的消息描述了什么差异(因为你可能拉差异,甚至整个提交到不同的分支)。 因此,提交信息并没有描述它“做”了什么…它描述了提交本身“做”做什么。 所以应该是现在时态。

想象一下,单独看差异,并试图决定是否应用它。 它在过去式中有一个标题是没有意义的。

恕我直言,如果你想要它是描述性的,而不需要考虑上下文,那么“固定”绝对是唯一正确的变体。

关于直观性 – 如果我看一些更新日志,我一定会明白,你所说的错误是因为我知道这个单词被使用的上下文而已,但是如果这个单词被写在这个自定义的单词中,指定方式。

“固定”是最差的select恕我直言,因为它可以被解释为不仅描述了什么补丁的(是),而且作为一个错误状态,这将意味着它正在工作,并没有解决。

 Fix the XXX bug in YYY Teach the XXX to be more ZZZ Correct typos in javadoc 

一般来说:{命令式动词} {受影响的对象} {可选限定词}

当我正在考虑一个补丁集时,命令forms适合所有的用例。

  • 你打算在这里做什么?
  • 这个补丁集有什么function?
  • 为什么创build这个补丁集? (修复xxx错误…)
  • 我需要在YYY修复xxx错误。 另一个分支上有提交吗?

无论您select什么,我都会发现一致性极大地提高了可读性。 挑一个,坚持下去。

我觉得写一下现在时态是一个好主意,因为当你提到过去的时态时,它会更加清楚。

我不认为这真的很重要。 目的是:

1)传达正在做什么或正在做什么,这样可以更容易地发现错误,可以更容易地恢复问题,并且通常能够更轻松地维护项目。

2)传达哪些门票是固定的(如果有的话),所以审计人员(如果他们在贵公司使用,可以看到哪些更改与哪些门票相对应)。

最后,如果“已经修好”,“修复”没有意义,如果你还在努力,“修正”是不正确的。

修正错误X ”比“ 修复错误X ”短2个字符。
和3比“ 修复bug X ”短。

从写短消息的angular度来看,现在时有时/通常会保存几个字符?
对于Git推荐的less于50个字符的首先提交的消息行,我认为这其实有点重要。
另外,less文字 – >读书更快?

提交消息描述了你为什么写了正在提交的代码。

“修复问题3124”或“修复问题3124”似乎是正确的,因为它说这个代码修复了问题3124。

但是,语法也可能取决于为什么将错误标记为固定的。 如果您可以在提交之后将错误标记为已修复,那么“固定”就可以了,但是如果在validation您的代码之后该错误将被其他人标记为已修复,则“修复”可能更合适。

我认为对这样一个问题最重要的答案是:每个人都应该使用对某个特定项目有用的东西,并保持至less一致。

虽然我看到使用现在时态的好处(实际上偶然发现了这个post,因为我在开源项目中看到了一些现在时态的信息),但我可能永远不会用现在时态来expression我的项目。 这是Linux和Git推荐的方式,也可能是其他更大的开源项目,但只要我不是这些项目的一部分,我并不在乎。

我是一个独立开发者,我使用提交消息的第一行作为发行注记,而下面的描述给了我关于实现细节的想法。 与现在时基于开发人员的方法相比,这是一个以用户为中心的工作stream程。 我可以节省一些时间。 在发行说明中给我的用户说明是非常不自然的。 这是我的工作,以修复错误和添加function。 我必须节省时间,因为我是独立的。 我的团队中没有“发行笔记作家”。

如果项目已经build立,可以使用项目的规则,但要保持务实,尽一切努力使工作变得更容易或更快。

我认为如果使用现在时态的原因是“使它更多地描述提交的内容”,而不是提交者做什么,那么"Fix XXX bug""Fix XXX bug"更有意义。

如果这是一个小小的承诺,我用现在的连续:

修复错误304

要么

添加评论

如果这是一个大的提交,我会做更多的更改日志:

  • 修复了错误453,657和324
  • 添加expression式语法
  • 重构了Operator类。