Question

我正在为我们的Subversion用户准备一些SCM指南，并且遇到了与团队争论的问题。有没有一个有效的用例可以让某个人使用相同的消息进行连续提交？

如果采用提交消息应该描述代码的“内容”和“原因”的方法，则很难看到有效的情况。看看我们的历史，发生这种情况的实例似乎更多是出于方便而不是其他任何事情，并且实际上并没有讲述代码正在做什么的故事。

有没有人对此合法性有任何看法？准则（甚至预先提交钩子）是否过于热心或是合理的期望？

编辑让我们假设人们已经离开了良好的提交消息。恕我直言，像“更新”或“拼写错误”这样的单词并不构成令人满意的提交信息。我希望看到更像“更新绿色提交按钮的颜色”或“修复教学副本中的拼写错误”。如果消息是一两个字，那么浏览存储库日志并理解项目中发生的事情是非常困难的，而无需深入研究单个提交。

Answer 1

我想这是技术解决方案无法回答的问题。您始终可以找到有效且工具禁止或相反的情况。

我经常使用的提交消息的一个例子，它讲述了所有故事：

typo

最好的解决方案不是技术性的。这是社会工程。和你的团队谈谈。

Answer 2

我通常会编写非常高抽象的提交消息，因为我并没有真正看到diff所说的相同故事。这有时会导致相同的连续提交消息。

Answer 3

同一个源文件上的相同提交消息... stinks。

不同源文件上的相同提交消息，连续提交：可能没问题，比如“添加额外的日志记录”

Answer 4

如果我在两个不同的目录中进行相关更改（在项目中可能会广泛分离），我会这样做。这比查找公共根目录然后取消选择大量不相关的更改或寻找我想要检查的更改要容易得多。

Answer 5

是。大多数情况下，这是因为对提交消息的使用和目的的培训不足。定期查找此信息并与处理该信息的人员联系，以告知他们良好的描述性提交消息的重要性是一个好主意。如果人们理解如何写出一个好的提交信息，那么你将看到的唯一重复是偶尔心不在焉。

Answer 6

我不明白为什么那么糟糕......你不可能每次都描述你所做的......或者你将花费大部分时间用很多词来描述几乎没有的东西。< / p>

例如：

commented here and there
typo
tidyed something ...

（我头顶的例子......）

因此，例如，“拼写错误” - 意味着，如果我想写好的提交消息，我应该花费10个以上的字符来描述一个字母的变化。最好的形式的Bureocracy ......