评论提交的最佳做法是什么？
一点背景。
我们的政策是评论你提交的所有内容，但我们中的一些人最近反对反对这个想法。
评论所有内容的问题有两个方面，它的工作量更大，而且用处不大。以下是我们看到的问题：
它鼓励人们发表评论，其中包含已经在版本控制中的内容（即我改变了第42行做了等等）。你可以比较得到相同的信息！
或者，它会用无用的评论填写您的评论流，如果您想要搜索评论，这将是一个巨大的痛苦。
这些事情中的任何一个都会增加很多时间，并且不会增加任何价值。评论仅在它们具有足够的特定性且足够稀少以便您可以扫描所有内容时才有用。
我们被告知Git以比Subversion更聪明的方式处理这个问题，并且我们愿意改变，显然拥有本地开发环境并且只提交批量更改也会有所帮助，但根据我们的用例，可能是效率方面的净损失。
我很想听听人们评论提交内容的最佳做法，感谢任何反馈！
答案 0 :(得分：9)
Git不会为你解决问题;你需要回答这个问题＆＃34;简单＆＃34;问题：如何增加评论的价值？
一些指导原则：
如果您发现自己经常处于需要在一次提交中提交多个修复程序的情况，那么您需要学会专注。在更改代码时，请不要随心所欲。做一件事，完成它，提交它。然后做下一件事。
如果您在途中偶然发现了某些事情，请记下（在纸上或额外的文本编辑器中，您一直悬停在屏幕的一角）。 不要总是打断你的工作！多任务/递归代码编辑会对质量和压力水平产生严重影响。
你仍然可以获得很长的＆＃34;固定IE8边距＆＃34;承诺，但这本身并不是一个问题。当您说＆＃34;我们想要搜索评论＆＃34;时，您必须想出一种方法将有用的信息放入评论中，以便在搜索评论时合理。例如，始终对错误ID使用相同的格式。纯文本对于搜索是不好的，尤其是提交应该简洁的消息。
只是省略评论不是解决方案，它是懒惰还是反社会的标志（＆＃34;谁关心别人是否有问题？＆＃34;）或坏训练（＆＃34;我不知道写些什么＆＃34;）。
第一个和最后一个可以通过培训解决。第二个是摆脱风险（即解雇那个人）。
世界上没有任何版本控制工具可以帮助您。
答案 1 :(得分：2)
我的理念是：
所有这些都是每个团队成员遵循的个人纪律问题。如果他们破坏了构建，那么“鼓励”构建管理员会在午夜唤醒他们。
答案 2 :(得分：2)
我的经验法则是，如果我不能在不到两个句子中总结提交的更改，那么自上次提交以来它已经太长了。
至于在该句中写什么，我从不说任何特定于行或文件的内容，因为该信息嵌入在提交中。我通常会提到普通英语的具体变化，就像我会向那些不属于该项目的人解释一样。
这非常有效，因为无论是我或其他几个月后，他们都可以阅读提交日志，就像项目开发的故事一样。我甚至做过博客文章，只是复制和粘贴我的提交日志。
答案 3 :(得分：1)
所有签到都应该有一个评论，但它本身不应该真正改变。评论应该是关于更改内容的快速一般性评论，而不是变更实施的细节，正如您所说，可以在变更本身中找到。