用于将最有用的提交的消息提取到更改日志的策略

Question

这个问题的需求是

• 为经理/客户提供以下更改日志:
  • 确实包含"让用户拥有其他地址"
  • 不包括"修复由于X而覆盖地址的错误"
• 避免查看完整的日志历史记录,以便为每个构建查找最重要的提交(通常向后不兼容)
• 使它像典型的游戏更改日志一样容易阅读("固定平衡问题:X"和"图形驱动程序Y慢慢渲染游戏")

今天,我们在提交消息中使用标志,例如

Add|Ref|Rem|Fix: <msg> 通常的提交.

因此,我对此的第一个尝试就是为这些标志添加另一层

CL-Add: feature X(CL = changelog)然后解析所有提交消息^CL-(Add|Ref|Rem|Fix)以添加到更改日志.

但是,您将如何处理为更改日志编写提交消息的可能性(即过高级别); 或有关同一更改日志问题的多条消息.也许在合并功能分支时应该提取更改日志消息？是否有SCM的功能:s(例如git)为您处理此问题？

简单地说:是否有一个行业标准策略或工具,可以轻松地将有用的提交消息提取到更改日志中？

Answer 1

过去我自己也尝试过，但运气不佳。基本上，让每个开发人员在每次提交时思考他们的提交消息是否对客户来说太可怕实际上是更多的工作。开发人员通常不是做出该决定的合适人选，而且一次只做一点是低效的。

经过大量实验后，对我有用的东西是微不足道的：在每次发布之前，让一个人浏览自上次发布以来的 git 日志，并将所有有趣的内容写到一个变更日志文件中。这实际上并不比其他方式更多的工作；大部分工作是决定，而不是措辞。决策过程需要特定的心态，因此让一个人批量完成比一群开发人员一次做一小部分更有效。（这样想：您不必不断地将作业的“提交消息客户检查”部分进出缓存。）

如果您确实想使用此类信息标记提交消息，那么您至少应该考虑使用git notes而不是原始提交消息来执行此操作。然后，如果有人通过错误地将提交标记为错误/功能/等而搞砸了，您可以通过更新注释来修复它。