我应该在git提交消息中使用过去或现在时吗？

Question

我应该在git提交消息中使用过去或现在时吗？

Ski*_*ick 491 git commit-message

我读过一次 git提交消息应该是命令现在时,例如"为x添加测试".我总是发现自己使用过去时,例如"为x添加测试",这对我来说感觉更自然.

这是最近的John Resig提交,显示了二合一消息:

在操作测试中调整一些jQuery set结果.还修复了预期测试结果的顺序.

有关系吗？我应该使用哪个？

Answer 1

mip*_*adi 555

对于现在时,命令式风格的提交消息的偏好来自Git本身.来自Git 仓库中的Documentation/SubmittingPatches:

描述你在命令式情绪中的变化,例如"make xyzzy do frotz"而不是"[This patch] make xyzzy do frotz"或"[I]将xyzzy改为frotz",好像你是在给代码库命令更改它行为.

所以你会看到很多以这种风格编写的Git提交消息.如果您正在团队或开源软件上工作,那么每个人都坚持这种风格以保持一致性会很有帮助.即使你正在从事一个私人项目,并且你是唯一一个能够看到你的git历史的人,但是使用命令式的情绪是有帮助的,因为它建立了良好的习惯,当你与他人合作时会受到赞赏.

您可以将提交视为一组有关如何从先前状态转到新状态的指令; 但我认为它更像是代码演变的一个检查点.对我来说,提交消息是自上次提交以来对代码所做的事情的日志; 对于日志,过去时更有意义.如果你真的认为提交消息应该是一组指令,那么命令式时态就是要走的路.我真的不这么想. (114认同)
我认为这是一个很好的选择.以diff的形式思考提交的内容:一组关于如何从先前状态转到新状态的指令.正如差异说"在此处添加此行,在此处删除此行"一样,提交消息在定性方面表示"进行此更改".(是的,git确实将提交存储为具有元数据的树,但对于人类而言,提交的重要部分是差异.) (84认同)
提交消息应该是命令式的,呈现时态,因为使用git你或其他人可能最终做`rebase`或`cherry-pick`,在这种情况下,提交可以在其原始上下文之外使用.因此,提交消息应该是独立编写的,而不期望读者查看任何周围的提交消息.当您选择补丁时,应用"修复快速排序算法"或"排序:提高性能"而不是"修复错误#124"或"修改排序以提高性能"更有意义. (43认同)
@oschrenk:该文件的后续版本给出了一个理由:"描述你在命令式情绪中的变化,例如'make xyzzy do frotz'而不是'[This patch]使xyzzy do frotz'或'[I]改变xyzzy做frotz ',好像你是在给代码库发号子来改变它的行为." (10认同)
我几乎赞成这个答案，但我认为“git 项目本身推荐它”不是一个足够好的理由。我真的不在乎任何一种方式（命令式或过去式），只是它应该在项目中保持一致。恕我直言，这个答案会很棒，如果它给出了更好的解释*为什么*命令式比过去时更好。 (6认同)
我想到的方式是,如果我选择将此提交应用于我的分支,该消息应告诉我将会发生什么变化.我不认为它是一个日志,但作为我可以移动的状态,我需要知道当我选择一个特定的状态时会发生什么. (5认同)
但提交都在 git 历史记录中，而历史已经过去了！ (3认同)
@MikkoRantalainen：“当你挑选补丁时，应用“修复快速排序算法”更有意义......而不是“修复[快速排序算法]”`为什么？ (3认同)
“*来自 git 本身*”是一个极其糟糕的论点。因此，如果 git 由于某种原因做错了，那么其他人也必须做错吗？正如伯特兰·罗素（Bertrand Russell）曾经说过的“*即使每个人都同意，每个人都可能是错的。*”我在这里错过了一个真正的论点，为什么命令式比替代式更好。 (3认同)
不幸的是，我的问题作为一个重复的问题被关闭了，虽然我知道它是用现在时完成的，因为 Git 文档说所以没有解释为什么。 (2认同)
+1作为参考.如果包括@ mipadi的评论那就太好了. (2认同)
当我在退房之前看到日志时,命令让我觉得这是我在退房后应该做的事情,而过去时使我觉得这就是为提交所做的事情. (2认同)
提交是事件，因为它代表存储库中发生的事情（并且事件源在检查特定变更集时会相应地修改文件系统）。因此，把它们写在过去更有意义。如果您将提交解释为命令，那么将它们写在当前，但命令代表可以执行或不执行的意图。无论您选择哪一个，都坚持使用其中一个。 (2认同)

Answer 2

Mat*_*ley 337

您的项目几乎总是使用过去时态.在任何情况下,项目应始终使用相同的时态以保持一致性和清晰度.

我理解其他一些争论使用现在时的论点,但它们通常不适用.以下要点是用现在时写作的常见论据,以及我的回答.

用现在时写作告诉某人应用提交会做什么,而不是你做了什么.

这是人们想要使用现在时的最正确的理由,但只有正确的项目风格.这种思维方式将所有提交视为可选的改进或功能,您可以自由决定在特定存储库中保留哪些提交以及拒绝哪些提交.

如果您正在处理真正分布式项目,则此参数有效.如果您正在处理分布式项目,那么您可能正在开发一个开源项目.如果它真的是分布式的,它可能是一个非常大的项目.实际上,它可能是Linux内核或Git.由于Linux可能是导致Git传播和普及的原因,因此很容易理解为什么人们会认为它的风格是权威.是的,这两个项目的风格是有道理的.或者,通常,它适用于大型开源分布式项目.

话虽这么说,源代码管理中的大多数项目都不会像这样工作.对于大多数存储库来说,它通常是不正确的.这是一种思考提交的现代方式:Subversion(SVN)和CVS存储库几乎不支持这种类型的存储库签入.通常,集成分支处理过滤不良签入,但这些通常不被视为"可选"或"可用的功能".

在大多数情况下,当您提交到源存储库时,您正在编写一个日记条目,该条目描述了此更新的更改,以便将来更容易理解为何进行更改.它通常不是可选的变更 - 项目中的其他人需要合并或变更.如"亲爱的日记,今天我不写日记条目满足一个男孩和他说我打招呼.",而是你写"我遇到了一个男孩,他说我打招呼."

最后,对于此类非分布式项目,一个人阅读提交消息的99.99%的时间用于阅读历史记录 - 历史记录以过去时态读取.0.01%的时间决定是否应该应用此提交或将其集成到其分支/存储库中.

一致性.这就是许多项目(包括git本身)的方式.还有生成提交的git工具(比如git merge或git revert)就可以了.

不,我向你保证,在版本控制系统中登录的大多数项目都有过去时的历史记录(我没有引用,但它可能是正确的,考虑到现在的时态参数是自Git以来的新内容).现在时的"修订"消息或提交消息只在真正的分布式项目中开始有意义 - 请参阅上面的第一点.

人们不仅要阅读历史记录以了解"此代码库发生了什么",还要回答诸如"我挑选此提交时会发生什么"等问题,或者"由于这些提交,我的代码库会发生什么样的新事物"我将来可能合并或不合并".

见第一点.一个人阅读提交消息的99.99%的时间用于阅读历史记录 - 历史记录以过去时态读取.0.01%的时间决定是否应该应用此提交或将其集成到其分支/存储库中.99.99%击败0.01%.

它通常更短

我从来没有见过一个好的论点,说使用不正确的时态/语法,因为它更短.对于标准的50个字符的消息,您平均只能保存3个字符.话虽如此,现在的时态平均可能会缩短几个字符.

您可以使用问题/功能跟踪器(不使用过去时,尽管有时候未来)中的故障单标题更一致地命名提交

门票被写成当前正在发生的事情(例如,当我点击此按钮时应用程序显示错误的行为),或者将来需要完成的事情(例如,文本需要编辑审阅).

历史(即提交消息)是作为过去完成的事情编写的(例如,问题已得到修复).

我今天第一次听到关于命令式样式提交的假设偏好.对我来说,这听起来如此不自然和奇怪,我决定寻求更多的意见.我很高兴看到我不是唯一一个认为过去时态对于提交消息更自然的人.:) (75认同)
git自动生成的合并和rebase提交消息是必需的和现在时("Merge",而不是"Merged";"Rebase",而不是"Rebased"),因此您可能希望在自己的提交消息中匹配它以保持一致性. (54认同)
势在必行不是"自git以来的新事物".ChangeLog早在git之前就存在了,命令式的使用一直是GNU Project中推荐的样式.http://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html (34认同)
问题是,使用命令式,现在时态适用于大型项目(例如Linux),因此它显然可以扩展.此外,使用过去时态需要相当多的努力.结果,我认为没有任何理由(除了"老人习惯用过去式时写提交消息")除了命令式,现在时态之外还使用其他任何东西.如果你可以学习git命令集,你可以学习必要的,现在时的写作. (26认同)
似乎区别在于关注*软件*的变化 - "通过执行Y修复X" - 或*存储库* - "执行Y来修复X".+1是一个好的论点,但我认为回购通常应该关注自己而不是结果软件. (11认同)
@adl在下一个例子中,http://www.gnu.org/prep/standards/html_node/Simple-Changes.html#Simple-Changes,使用过去时:"所有来电者都改变了"这将是夸大其词说从来没有强制性的紧张,但它肯定不太常见. (7认同)
对于进行代码审查的团队来说,99.99%的断言是不正确的.大多数时候,当我读取提交消息时,它是在代码审查期间,**在应用提交之前**.因此,命令式时态是有道理的. (6认同)
我对人们花99.99%的时间阅读提交消息只是为了审查历史而不是决定如何将提交应用于提交树的说法持怀疑态度.通过实际的经验事实和证据支持这一论点将更加强大. (4认同)
如果你仔细观察，在 GNU 编码标准中，他们在描述所做的事情时总是使用过去时态。现在时用于描述*代码*现在的作用。我总是编写 ChangeLog 条目（我的比 RMS 更详细），然后将它们用于提交消息。我用过去时态。 (3认同)
我参与过的几乎每个工业/商业项目都使用过去时作为标准，因为这是描述“完成”的最明智的方式。根据我的经验，您正确地指出，99% 的时间是在更改历史记录的上下文中读取提交消息，而不是拉取请求（这主要是一种开源开发范例）。 (3认同)
@Cupcake我同意它会有更强的证据,但不知道从哪里得到它.我相信,但我没有数据,几乎所有的软件项目都是作为一个整体,或至少是一个特定的分支.有人从分支机构开始并通过挑选来尝试其他人的变化是非常可行的,但我坚信这种情况发生的次数不到1/10,000次.大多数人都想弄清楚发生了什么.我无法想象任何软件,开源或商业,通过制作樱桃选择而不是分支机构发布. (2认同)
命令式提交评论听起来像Chinglish给我.我认为任何英语母语人士在描述他们*所做的改变时都会用过去时态思考. (2认同)
如果您熟悉 DDD 系统，Git 或任何源代码控制存储库都完全符合“事件应该写在过去”的方法。提交是存储库中已经发生的事情。它应该是不可变的，因此它就像一个事件（过去）。如果我们现在写它，它更像是一个意图（命令），它可能会对系统产生影响，也可能不会（它可能会被拒绝）。如果您签出特定的提交，则先前提交的历史记录将在您的文件系统中一一应用（如事件溯源）。现在没有意义。 (2认同)
我也拒绝了这个答案。质量低下。它引人入胜[提出了问题]（https://en.wikipedia.org/wiki/Begging_the_question）。“当您提交对源存储库的提交时，您正在编写日记条目，该日记条目描述了此更新所做的更改”。它还发明了统计信息（“ 99.99％的时间”）和其他事实，这些事实表明该主题相对不了解（“当前时态参数自Git以来是新的”，“我向您保证，大多数项目都曾经登录过一个版本控制系统具有过去时态的历史（我没有参考...）” (2认同)
我认为马克加拉西提出的观点应该纳入答案中。让提交消息与发行说明保持一致是支持使用过去时态的最强点之一。就我个人而言，我总是使用现在时，因为它更常见，但是当我将提交消息翻译为发行说明时，我希望它们使用相同的时态。 (2认同)

Answer 3

Abi*_*ern 78

我写了一篇关于365git的更全面的描述.

命令式现在时的使用需要一点点习惯.当我开始提及它时,遇到了阻力.通常沿着"提交消息记录我所做的事".但是,Git是一个分布式版本控制系统,可能有很多地方需要进行更改.而不是写出说出你所做的事情的信息; 将这些消息视为应用提交将执行的操作的说明.而不是拥有标题的提交:

Renamed the iVars and removed the common prefix.

有这样一个:

Rename the iVars to remove the common prefix

这告诉某人应用提交会做什么,而不是你做了什么.此外,如果你查看你的存储库历史记录,你会发现Git生成的消息也是用这个时态写的 - "Merge"不是"Merged","Rebase"不是"Rebased",所以用同样的时态写入可以保持一致.起初感觉很奇怪,但确实有意义(申请时提供推荐书)并最终变得自然.

说完了所有这些 - 这是你的代码,你的存储库:所以建立你自己的指导方针并坚持下去.

但是,如果您决定采用这种方式,那么git rebase -i使用reword选项将是一件好事.

好吧,你已经混淆了两个不同的指导方针:Git开源项目,以及Git的常规使用.提供的链接*根本没有提到时态*.官方Git doc仅提到50个字符限制._Git是一个分布式VCS,其中有许多地方可以从中进行更改...将这些消息视为应用提交将执行的操作的说明.这仅适用于实际分布式项目的几个项目.99.999%的Git提交永远不会以这种方式手动应用.在大多数项目中,历史记录是更改日志,应该是过去时态. (6认同)
"并且应该跳过句号" (3认同)

Answer 4

Cra*_*lin 24

坚持目前的紧张命令,因为

有一个标准是好的
它匹配bug跟踪器中的票证,它自然具有"实现某些东西","修复某些东西"或"测试某些东西"的形式.

Answer 5

war*_*rdw 15

你在为谁写信息？并且该读者通常在提交之前或之后阅读消息吗？

我认为从这两个角度给出了很好的答案,我或许还没有提出每个项目都有最好的答案.分裂投票可能也表明了这一点.

即总结:

该消息主要是针对其他人的,通常是在他们做出改变之前的某个时刻阅读:提出改变的内容将对他们现有的代码做什么.
该消息主要是作为您自己(或您的团队)的日记/记录,但通常从假设变更的角度阅读并回顾发现发生的事情.

无论哪种方式,这可能会为您的团队/项目带来动力.

Answer 6

Mic*_*dry 11

有关系吗？人们通常足够聪明,可以正确地解释消息,如果他们不是,你可能不应该让他们访问你的存储库!

对于[某些人](https://github.com/torvalds/linux/pull/17#issuecomment-5659970),类似的事情很重要. (25认同)
@mog链接没有对现在和过去做任何陈述. (2认同)
如果该项目确实花费了大量时间，那么进行代码审阅和错误查找的人员将看到大量提交，因此他们需要您和我提供的所有帮助。现在没有必要节省几秒钟的时间，以免将来由于未编写正确的提交消息而引起严重的头痛。 (2认同)

Answer 7

And*_*ehm 7

它是由你决定.只需使用提交消息即可.但如果您不在时间和语言之间切换,则会更容易.

如果你在一个团队中发展 - 应该讨论并设置固定.

归档时间：	15 年前
查看次数：	85591 次
最近记录：	7 年，9 月前