这个问题的需要是
今天，我们在提交消息中使用标志，例如
Add|Ref|Rem|Fix: <msg>对于通常的提交。
因此，我的第一个尝试是为这些标志添加另一层，例如
CL-Add: feature X（CL = 变更日志），然后解析所有提交消息^CL-(Add|Ref|Rem|Fix)以添加到变更日志。
但是，您将如何处理仅为更改日志编写提交消息的可能性（即太高级别）？或有关同一变更日志问题的多条消息。也许应该在合并特征分支时提取更改日志消息？是否有 SCM:s（例如 git）的功能可以为您处理这个问题？
简而言之：是否有行业标准策略或工具可以轻松地将有用的提交消息提取到变更日志中？
过去，我自己尝试过这种方法，但运气不佳。基本上，让每个开发人员在每次提交时思考他们的提交信息是否对客户来说太吓人实际上是更多的工作。开发人员通常不是做出该决定的合适人选，一次做一点是低效的。
经过大量的实验，对我有用的是微不足道的：就在每次发布之前，让一个人检查自上次发布以来的 git 日志，并将所有有趣的内容写到变更日志文件中。这实际上并不比其他方式更多。大部分工作是决定性的，而不是措辞。而且决策过程需要一种特殊的思维方式，因此让一个人大批量地做比一群开发人员一次做一点点更有效。（这样想：您不必一直在缓存中交换作业的“提交消息客户检查”部分。）
如果您真的想使用此类信息标记提交消息，您至少应该考虑使用git notes而不是原始提交消息来执行此操作。然后，如果有人通过将提交错误地标记为错误/功能/等来搞砸它，您可以通过更新注释来修复它。
我不知道任何这样的标准工具，但是由于您有一段时间没有得到答案，所以这里有一些想法：
因此，首先，正如您所建议的那样，尝试避免 CHANGELOG 文件通常可能是一个好主意，因为这样的文件往往会导致所有合并冲突。（除非你碰巧有一个智能的自动合并工具。）
像 CL: 或 Log: 这样的前缀以便于提取可能是一个好主意。关于 Add/Ref/Rem/Fix：（我假设Ref并Rem代表“重构”和“删除”，对吗？）当您编写变更日志时，我宁愿坚持使用自由格式的条目。例如，我不确定重构是否属于变更日志，并且足以保证变更日志条目的高级功能通常不会被彻底删除——它们宁愿被更改为其他形式。
但是，您将如何处理仅为更改日志编写提交消息的可能性（即太高级别）？
我想说，将（CL:-tagged）高级描述放在提交消息的一段中，将较低级别的技术描述放在另一段中。
或有关同一变更日志问题的多条消息。
我们正在谈论这样的事情，对吧？
这就是我认为“自动更改日志”变得棘手的地方。除非您愿意在事后重新设置和编辑提交消息（例如从上面的提交（1）中删除“CL：”），否则我建议唯一可行的方法是，每次发布时，从您上次发布以来的 git 日志中提取所有标记的段落，并手动编辑结果列表，将上面的 (1) 和 (2) 之类的内容合并在一起，然后转动，比如说，“Fixed #145”，“Fixed #153 "、"Fixed #164" 合并成一行 "Fixed #145、#153 和 #164"。
希望我已经能够提供一些灵感。让我们知道你最终做了什么！
看看vclog。