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

7 回答

• 20

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

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

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

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

  如果您正在处理真正分布式项目，则此参数有效 . 如果您正在处理分布式项目，那么您可能正在开发一个开源项目 . 如果它真的是分布式的，它可能是一个非常大的项目 . 事实上，它很容易理解为什么人们会认为它的风格是权威 . 是的，这两个项目的风格是有道理的 . 或者，通常，它适用于大型开源分布式项目 .

  话虽如此，源代码管理中的大多数项目都不会像这样工作 . 对于大多数存储库而言，它通常是不正确的 . 这是一种考虑提交的现代方式：Subversion（SVN）和CVS存储库几乎不支持这种类型的存储库签入 . 通常，集成分支处理过滤错误签到，但这些通常不被视为“可选”或“可用的功能” .

  在大多数情况下，当您提交到源存储库时，您正在编写一个日记条目，该条目描述了此更新的更改内容，以便将来更容易理解为何进行更改 . 通常不会写日记条目，如“亲爱的日记，今天我遇到一个男孩，他向我问好 . ”", but instead you write "我遇到了一个男孩，他向我问好 . “

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

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

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

  • 人们不仅要阅读历史记录以了解"what happened to this codebase"，还要回答"what happens when I cherry-pick this commit"或"what kind of new things will happen to my code base because of these commits I may or may not merge in the future"等问题 .

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

  • 通常更短

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

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

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

  历史（即提交消息）被写为过去完成的事情（例如，问题已得到修复） .

  回复于 2024-05-01T02:03:32+08:00
• 6

  对于现在时，命令式样提交消息的偏好来自Git本身 . 来自Git回购中的Documentation/SubmittingPatches：

  描述你在迫切情绪中的变化，例如： “make xyzzy do frotz”而不是“[这个补丁]让xyzzy做frotz”或“[我]改变了xyzzy做frotz”，好像你是在给代码库命令来改变它的行为 .

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

  回复于 2024-05-01T02:03:32+08:00
• 14

  我在365git上写了一个更全面的描述 .

  使用命令式现在时是需要一点点习惯的时态 . 当我开始提及它时，遇到阻力 . 通常沿着“提交消息记录我所做的事” . 但是，Git是一个分布式版本控制系统，可能有很多地方需要进行更改 . 而不是写出说出你所做的事情的信息;将这些消息视为应用提交的指令 . 而不是提交 Headers ：重命名iVars并删除公共前缀 . 有一个这样的：重命名iVars删除公共前缀，告诉别人应用提交将做什么，而不是你做了什么 . 此外，如果你查看你的存储库历史记录，你会发现Git生成的消息也是用这个时态写的 - “Merge”不是“Merged”，“Rebase”不是“Rebased”，所以用同一时态写入可以保持一致 . 起初感觉很奇怪但它确实有意义（推荐可在申请时提供）并最终变得自然 . 说完了所有这些 - 这是你的代码，你的存储库：所以 Build 你自己的指导方针并坚持下去 . 但是，如果您决定采用这种方式，那么使用reword选项git rebase -i将是一件好事 .

  回复于 2024-05-01T02:03:32+08:00
• 317

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

  • 有一个标准是好的

  • 它匹配错误跟踪器中的票证，其自然具有"implement something"，"fix something"或"test something."形式

  回复于 2024-05-01T02:03:32+08:00
• 70

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

  我认为这里的好答案都是从两个方面给出的，我或许还没有暗示每个项目都有最好的答案 . 分裂投票可能也表明了这一点 .

  即总结：

  • 该消息主要是针对其他人的，通常是在他们做出改变之前的某个时刻阅读：关于采取更改的内容的建议将对他们现有的代码做什么 .

  • 消息主要是作为自己（或您的团队）的日记/记录，但通常从假设变更的角度阅读并回顾发现发生的事情 .

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

  回复于 2024-05-01T02:03:32+08:00
• 472

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

  回复于 2024-05-01T02:03:32+08:00
• 9

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

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

  回复于 2024-05-01T02:03:32+08:00