我广泛使用版本控制。当我独自工作时，我仍然使用它，并找到许多有关它的好东西。我知道我'应该'放入好消息等，但发现通常提交的日期和检查差异的所有工具等都足够了。我经常最终收到像“变化”这样的垃圾邮件。
我想这是一个奇怪的问题，但是，当他们在只有他们正在使用的存储库中进行提交时，其他人使用什么作为他们的日志消息？不留信息有什么问题吗？
我碰巧使用git，但这个问题更为笼统。
答案 0 :(得分：1)
我也是使用版本控制的独立开发人员。我最近开始使用一个监控消息的问题跟踪系统，因此我的情况变得更好，并且至少有一个问题编号。其余的时间，我试着至少一般地说明在一两句话中改变了哪些区域。
但每隔一段时间，我仍然会变得懒惰（或半睡半醒）并输入“修复错误”之类的内容。
答案 1 :(得分：1)
您应该将消息放入具有多个开发人员的代码中。在几天内看到你的变化的其他人和你在轨道上看了12个月之后看起来通常没什么区别。在这两种情况下，很有可能看上去的人不知道为什么要做出改变： - ）
我甚至可以使用适当的变化控制，即使对于我独自完成的事情也是如此。这意味着对代码库的每次更改都必须包含更改请求或错误报告（包含完整文档）。
当我需要理解为什么要做的事情时，这会让我的生活变得更轻松。对于我的“湿件”，我有更好的用途，而不是试图记住每一个小变化以及为什么要这样做。让机器记住它好得多 - 它的记忆力要好得多。
而且，在我的意见中，如果你不能为正确行事而烦恼，那就不要这样做了。只需恢复牛仔编码器的心态，省去一些努力。
做得好并不需要那么多额外的努力，而且奖励是巨大的。这一切都归结为成本/收益分析。
答案 2 :(得分：1)
对我来说，这取决于修复的性质。有时，它只是一个字。 “备份”或“复制更改”。但是，如果某些事情让我感到非常悲伤，我会更广泛地记录我的变化。如果它是开源的，我不会那么久，我会非常广泛地记录我的变化。 svn -diff（然后以那种方式记录我所有的变化......）。
由另一个系统中的号码标识的错误修复，需要位于更改日志中。
我会告诉你“修复bug”在更改日志中不是很好，但是如果它是一个简单的bug那么可能会这样做。
我认为没有一条好的快速规则，但您的输入应该与您执行代码所花费的时间成比例。副本改变？拼写错误？没有那么多的消息需要。
您花了2个小时修复错误吗？是的！长提交消息。