应该使用现在还是过去式来编写提交消息？
那么你认为哪个更好，更直观？
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类。
