Version control 提交消息应该用现在时态还是过去时态？

那么你认为哪一个更好、更直观呢

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

---

请提供你的理由。请注意，我是从您的总体角度提出这一问题的，这意味着您不应试图将其与首选的svn/cvs工具或编程语言联系起来，而应将其视为应该/可以应用于任何工具和编程语言的东西。

我认为这并不重要。目的是：

1） 传达正在做或正在做的事情，这样可以更容易地发现bug，更容易地恢复问题，并且通常能够更容易地维护项目

2） 如果有的话，传达哪些票据是固定的，这样审核员（如果他们在贵公司使用的话）就可以看到哪些票据对应哪些变更

---

最后，如果它已经被修复，“修复”没有意义，如果你还在做，“修复”是不正确的。

我个人使用过去时态（“修复”），因为当我开始犯错误时，错误已经修复（或者我不会犯错误）。

我认为用现在时态写当前的提交是个好主意，因为当你用过去时表示之前的提交时，它会更清楚。

我认为这些消息在其他开发人员看来是一样的。他们还没有应用更改，还有一个隐含的问题，“应用此更改集/补丁会做什么？”它将“修复YYY中的XXX错误”

对于其他动词，将它们作为命令来编写似乎更为自然，而且如果您事先有一个特定的目标，那么在工作完成之前，您可以直接编写提交摘要以及预先测试

---

我不会对它施加太大的压力，但对我来说，这是一条阻力最小的道路，同时保持一致性。

如果是一个小的承诺，我使用现在进行时：

修正错误304

或

添加评论

如果是一个大的提交，我会做更多的更改日志：

• 修复了错误453、657和324
• 添加表达式语法
• 重构了操作符类

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

从写短消息的角度来看，现在时态有时/通常保存几个字符？
我实际上认为这有点重要，例如Git建议在第一条提交消息行上少于50个字符。

---

此外，更少的文本——>读得更快了？

imHo。如果你希望它是描述性的，而不需要考虑上下文，那么“固定”绝对是唯一正确的变体。

关于直观性-如果我看一些变更日志，我肯定会明白你的意思是修复的bug，因为我知道这个词的使用上下文，但是如果这个词是以这种自我指定的方式写的，我的大脑会更快地捕捉到它

“修复”是IMHO最糟糕的选择，因为它不仅可以解释为描述补丁的功能（用途），还可以解释为bug状态，这意味着它正在工作，尚未解决

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

一般而言： {命令动词}{受影响的对象}{可选限定词}

当我考虑补丁集时，命令式表单适合所有用例

• 你打算在这里干什么
• 这个补丁集做什么
• 为什么要创建此修补程序集？（修复xxx错误…）
• 我需要修复yyy中的xxx错误。另一个分支上是否有已执行此操作的提交

---

无论您选择哪一种，我发现一致性极大地帮助了可读性。选择一个并坚持使用。

我更喜欢用现在时态查看提交消息。这样，消息描述了diff的作用（因为您可能会将该diff甚至整个commit拉入另一个分支）。因此，提交消息并不描述它“做”了什么。。。它描述了提交本身“做”的事情。所以它应该是现在时态

---

想象一下，孤立地看一个差异，并试图决定是否应用它。标题用过去时是没有意义的。

提交消息描述了编写提交代码的原因

“Fixed issue 3124”或“Fixes issue 3124”似乎是正确的，因为它表示此代码修复了| Fixes issue 3124

---

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

我认为对这样一个问题最重要的答案是：每个人都应该使用适用于特定项目的内容，并保持至少一点点的一致性

虽然我看到了使用现在时的优点（事实上，我偶然发现了这篇文章，因为我在开源项目中看到了一些现在时的信息），但我可能永远不会在我的项目中使用现在时。这是Linux和Git的推荐方式，可能还有其他更大的开源项目，但我真的不在乎，只要我不是这些项目的一部分

我是一名独立开发人员，我使用提交消息的第一行作为发行说明，而下面几行中的描述让我了解了实现细节。与现在时态、基于开发人员的方法相比，它是一个以用户为中心的工作流。这样我可以节省一些时间。在发行说明中给我的用户提供说明是非常不自然的。我的工作是修复bug和添加功能。我必须节省时间，因为我是独立的。我的团队中没有“发行说明撰写人”

如果一个项目的规则已经建立，那么就使用它们，但要保持务实，做任何能让你的工作更容易或更快的事情。

我认为

如果使用现在时态的原因是为了“让它更简单”，那么“修复XXX错误”

比

更有意义