这道题的需求是
- 为经理/客户准备一份变更日志:
- 确实包括“让用户有额外的地址”
- 不包括“修复了由于 X 而导致地址被覆盖的错误”
- 避免必须查看完整的日志历史记录才能为每个构建找到最重要的提交(通常向后不兼容)
- 让它像典型的游戏变更日志一样易于阅读(“修复平衡问题:X”和“图形驱动程序 Y 渲染游戏速度慢”)
今天，我们在提交消息中使用标志，例如
Add|Ref|Rem|Fix: <msg>对于通常的提交。
因此，我的第一个尝试是为这些标志添加另一层，例如
CL-Add: feature X (CL = changelog) 然后解析 ^CL-(Add|Ref|Rem|Fix) 的所有提交消息添加到变更日志。
但是，您将如何处理只为变更日志编写提交消息的可能性(即太高级别)；或关于同一变更日志问题的多条消息。也许应该在 merge 功能分支时提取更改日志消息？是否有 SCM:s(例如 git)的功能可以为您处理这个问题？
简单地说:是否有行业标准的策略或工具可以轻松地将有用的提交消息提取到变更日志中？
最佳答案
我过去曾自己尝试过，但运气不佳。基本上，更多的工作实际上是让每个开发人员在每次提交时都考虑他们的提交信息是否对客户来说太可怕了。开发人员通常不是做出该决定的合适人选，一次做一点是低效的。
经过大量实验，对我有用的是微不足道的:在每次发布之前，让一个人检查自上次发布以来的 git 日志，并将所有有趣的内容写到一个变更日志文件中。这实际上并不比其他方式更有效；大多数工作是决定性的，而不是措辞。决策过程需要特定的思维方式，因此让一个人批量完成比一群开发人员一次做一小部分更有效率。 (这样想:您不必一直在缓存中交换作业的“提交消息客户检查”部分。)
如果你真的想用这种信息标记提交消息，你至少应该考虑使用 git notes 而不是原始提交消息。然后，如果有人通过错误地将提交标记为错误/功能/等来搞砸它，您可以通过更新注释来修复它。
关于git - 将最有用的提交消息提取到变更日志的策略，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3793643/