提交消息应该使用现在时还是过去时？[关闭]

102

那么，您认为哪个更好，更直观？

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工具或编程语言相关联，而应将其视为应该/可以应用于任何工具和编程语言的事物。

version-control  coding-style 
— 她
source
您工作中的某个人太学究了，希望不是您。无论是谁，都应该考虑当前的完善与当前的不完善之间的关系，以及在提交注释是从键入之时还是从其持久化到存储库之前就读这个哲学难题。如果是后者，则使用目前完美的动作。如果是前者，则对当前活动的完成不完善。
— Heath Hunnicutt
1
不是这个问题的虚伪之处。这只是一个小问题，而不是总体准则。
3
幸运的是，事实并非如此。我在问，试图找出答案，想知道那里的一般做法是什么。如果我必须告诉你真相，这实际上是我曾经在SO上问过的最微不足道的问题，但是，嘿，这仍然是一个问题，不是吗？这个问题本身获得了三票，这对你来说（如果对你来说不是很明显）表明，我并不是唯一一个认为这个问题本身有效的人。我正在寻求建设性的答案，而您根本没有帮助。
— 他的
1
如果您认为人们不应该太担心提交消息中的时态，请说出来，说明您的理由和偏好。比您上面的讽刺评论要有用和有用得多。
— 他的
10
我非常重视这个问题。这是一个很大的问题。开发软件时，保持一致非常重要，所有对此网站主题感兴趣的访问者都应保持一致。那是我的意见。
— Niklas Berglund 2010年

Answers:

39

我认为这些消息就像其他开发人员看到的那样。他们尚未应用更改，并且存在一个隐式问题：“将应用此更改集/补丁做什么？” 它将“修复YYY中的XXX错误”！

对于其他动词，将它们作为命令编写似乎更自然，并且如果您事先有特定的目标，效果会更好—您可以在完成工作之前从字面上编写提交摘要以及前期测试。

我没有对它施加太大的压力，但是对我来说，这是保持一致性的同时阻力最小的途径。

— Roger Pate
source
8
我记得在git文档中遇到过强烈推荐这种时态的事情，但是我仍然感到尴尬。
— keithjgrant
1
这是Git文档的来源。
— sschuberth 2014年
31

我个人使用过去式（“ fixed”），因为到提交该错误时，该错误已修复（或者我不会提交）。

— 克莱图斯
source
你能举个例子吗？
— bzlm
15
一个例子。
— 奇闻趣事牧师
它被称为“提交历史”。历史总是以过去式书写。所以过去式更有意义。当您还浏览某些回购的提交历史记录时，您正在查看过去所做的事情！
— 湿婆神
13

我更喜欢以现在时态查看提交消息。这样，消息将描述差异的作用（因为您可能会将差异甚至整个提交拉到另一个分支中）。因此，提交消息没有描述其“已完成”的工作...它描述了提交本身“已完成”的工作。所以应该是现在时。

想象一下孤立地查看差异，然后尝试确定是否将其应用。以过去时态称呼它是没有意义的。

— TedPavlic
source
1
“的DIFF做什么”，但建立的DIFF由提交其COMMITED，它在提交历史了，所以它已经是“应用”。
— 尤利奥诺夫雷
9

恕我直言，如果您希望在不考虑上下文的​​情况下进行描述，则“固定”绝对是唯一正确的变体。

关于直观性-如果我查看一些变更日志，我一定会明白，您的意思是已修复的错误，因为我知道使用该单词的上下文，但是如果以这种自我方式编写该单词，我的大脑会更快地抓住它。指定方式。

“修复”是恕我直言的最糟糕的选择，因为它不仅可以解释为描述补丁的作用（用途），还可以解释为错误状态，这意味着该补丁正在工作且尚未解决。

— 伊万
source
7 
Fix the XXX bug in YYY
Teach the XXX to be more ZZZ
Correct typos in javadoc

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

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

  • 你打算在这里做什么？
  • 此补丁集有什么作用？
  • 为什么创建此补丁集？（修复xxx错误...）
  • 我需要修复yyy中的xxx错误。在另一个分支上已经有提交了吗？

无论您选择哪种方式，我都会发现一致性极大地提高了可读性。选择一个并坚持下去。

— phord
source
4
很好的理由。我总是认为这就像消息中说的“我是一个补丁，我[消息]”。这样，您总是以命令式动词开头。
— florisla
5

我认为以当前时态编写当前提交是一个好主意，因为当您引用过去时态中的先前提交时，它可以使您更加清楚。

— 肯·布鲁姆
source
1
我同意。如果提交引用自身，则也是如此，如“此提交修复了F00F错误”中所述。
— bzlm
4

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

1）传达正在执行或正在执行的操作，因此可以更轻松地发现错误，可以更轻松地解决问题，并且通常可以更轻松地维护项目。

2）传达已修复的票证（如果有），以便审核员（如果贵公司使用了票证，则可以查看对应于哪些票证的更改）。

最后，如果已修复，则“修复”没有意义，如果您仍在进行修复，则“修复”是不正确的。

— 贡佐牧师
source
1
当然，严格来说，这没关系。但是，如果您必须选择一个，则当您修复本地树中的错误并想要提交所做的更改时，您说的是“固定XXX”还是“固定XXX”或“固定XXX”？
— 他在2009年
1
我认为如果文字太简短就很重要。有时，我会看到提交消息，这些消息使我想知道：1.是否已发现或已实际修复了错误，还是2.已隐瞒或已实际应用了修复程序，还是3.是否已部分或完全修复了复杂的错误行为。有时，几次提交都与同一个错误有关。在“此提交解决了DrawBall（）中的充气问题并关闭票证666”中，时态无关紧要，因为文本是冗长的。但是对于“ DrawBall（）反弹错误”，提交做了什么？
— bzlm
2

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

从编写短提交消息的角度来看，现在时有时/通常节省一些字符？
我实际上认为这有点重要，例如，Git建议在第一次提交消息行时少于50个字符。
另外，更少的文字->阅读速度更快？

— 凯吉·马格努斯（KajMagnus）
source
1

提交消息描述了为什么您编写了要提交的代码。

“固定问题3124”或“固定问题3124”似乎正确，因为它说此代码已修复问题3124。

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

— 帕拉格
source
0

我认为这个问题的最重要答案是：每个人都应使用对特定项目有用的东西，并使它至少保持一点点一致。

尽管我看到了使用现在时的优势（并且实际上偶然发现了这篇文章，因为我在开放源代码项目中看到了一些现在时的消息），但我可能永远不会在我的项目中使用现在时。对于Linux和Git以及其他更大的开源项目，这是推荐的方法，但老实说，我不在乎，只要我不属于这些项目即可。

我是一个独立开发人员，我使用提交消息的第一行作为发行说明，而以下各行中的描述使我对实现细节有所了解。与目前的基于开发人员的时态方法相比，这是一个以用户为中心的工作流程。这样可以节省一些时间。在发行说明中给我的用户指示是极其不自然的。修复错误并添加功能是我的工作。我必须节省时间，因为我是独立人。我的团队中没有“发行说明撰写者”。

如果已经建立了项目规则，请使用它们，但要保持务实，并尽一切可能使您的工作更轻松或更快速。

— 拉斐尔·布加杰夫斯基（Rafael Bugajewski）
source
-1

我认为"Fixes XXX bug"比"Fix XXX bug"使用现在时的原因更有意义，而不是使用“现在时”来描述提交的内容，而不是提交者的内容。

— 技术叶
source
-4

如果是小的提交，我使用现在连续的：

修复错误304

要么

添加评论

如果提交量很大，我会做更多更改日志：

  • 修复了Bug 453、657和324
  • 添加表达式语法
  • 重构了Operator类。
— ster
source
9
换句话说，您将所有这些混合在一起willy-nilly B
— Brian Postow
差不多了 因为最后，提交消息不必是女王英语。
— tster
2
无论如何，您不应该在一个提交中做很多不同的事情。
— florisla
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.