自己记录修订控制消息

对我来说,这取决于修复的性质。有时候,只有一个词。”备份或“复制更改”。但是,如果有什么事情让我非常悲伤,我会更广泛地记录我的变化。如果它是开放源码的,并且我不会在那里呆那么久,那么我将非常广泛地记录我的更改。svn-diff(然后以这种方式记录我的所有更改…:)

由另一个系统中的数字标识的错误修复需要在更改日志中。

我会的,承认“修复的bug”在变更日志中不是很好,但是如果它是一个简单的bug,那么也许它可以做到。

我不认为有一个好的和快速的规则,但是你的输入应该与你花在代码上的时间成比例。副本更改?拼写错误?不需要那么多信息。

你花了2个小时修理一个虫子吗?是的!长提交消息。

我也是一个使用版本控制的独立开发人员。我最近开始使用一个监控消息的问题跟踪系统,所以我的情况有所改善,至少在有问题的时候参考一个问题编号。在剩下的时间里,我至少要试着用一两句话来概括哪些方面发生了变化。

但每隔一段时间,我还是会变得懒惰(或半睡半醒),然后输入“修正错误”之类的内容。

您应该像将消息放入具有多个开发人员的代码中那样放入有意义的消息。别人在几天内看你的变化和你在12个月后看变化之间通常没有什么区别。在这两种情况下,很有可能看起来的人不知道为什么要进行更改:—)

我甚至使用适当的变更控制,甚至是我自己做的事情。这意味着对代码库的每个更改都必须有一个更改请求或一个错误报告(带有完整的文档)。

当我需要理解为什么要做一些事情的时候,这让我的生活变得容易多了。我对我的“湿洁具”有更好的用途,而不是试图记住每一个微小的变化和为什么要做。让机器记住它要好得多——它的记忆好多了。

而且,在我的 意见 如果你做得不好,那就别做了。回到牛仔编码者的心态,省去一些努力。

做对了并不需要那么多额外的努力,而且回报是可观的。这都归结为成本/收益分析。