将最有用的提交消息提取到变更日志的策略
这个问题需要
- 为经理/客户提供一个变更日志：
- 包含“让用户拥有其他地址”
- 不包括“修复了由于X导致地址被覆盖的错误”
- 避免必须查看完整的日志历史记录来查找最重要的提交（大多数情况下，每个版本都向后不兼容，
- 使其易于阅读，就像典型的游戏变更日志（“修复平衡问题：X”和“图形驱动程序Y缓慢地渲染游戏”） ")
今天，我们在提交消息中使用标志，例如
用于常规提交的 Add|Ref|Rem|Fix:。
因此，我的第一个尝试是向这些标志添加另一个层，例如
CL-Add: feature X（CL = 变更日志），然后解析 ^CL 的所有提交消息-(Add|Ref|Rem|Fix) 添加到变更日志。
但是，您将如何处理仅为变更日志编写提交消息的可能性（即太高的级别）？或涉及同一变更日志问题的多条消息。也许应该在合并功能分支时提取变更日志消息？ SCM:s（例如 git）是否有可以为您处理此问题的功能？
简而言之：是否有行业标准策略或工具，可以轻松地将有用的提交消息提取到变更日志中？
The needs for this question is to
- have a changelog for managers/customers that:
- does include "Let users have additional addresses"
- does not include "Fixed the bug where addresses were overwritten due to X"
- avoid having to look through complete log history to find the most important commits (most often backwards incompatible) for each build
- make it as easy to read as the typical game changelog ("Fixed balance issues: X" and "Graphics driver Y rendered the game slowly")
Today, we're using flags in commit messages such as
Add|Ref|Rem|Fix: <msg> for the usual commit.
As such, my first stab at this would be to add another tier to those flags, for example
CL-Add: feature X (CL = changelog) and then parse all commit messages for ^CL-(Add|Ref|Rem|Fix) to add to the changelog.
But then, how would you approach the possibility of having commit messages written just for changelogs (i.e. too high level); or multiple messages concerning the same changelog issue. Perhaps the changelog messages should rather be extracted when feature-branches are merged? Are there features of SCM:s (for example git) that handles this issue for you?
Simply put: is there an industry standard strategy, or tool, for extracting useful commit messages into changelogs with ease?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
过去我自己也尝试过，但运气不佳。基本上，让每个开发人员在每次提交时思考他们的提交消息是否对客户来说太可怕，实际上是更多的工作。开发人员通常不是做出该决定的合适人选，而且一次只做一点是低效的。
经过大量的实验后，对我有用的东西是微不足道的：在每次发布之前，让一个人浏览自上次发布以来的 git 日志，并将所有有趣的内容写到一个变更日志文件中。这实际上并不比其他方式更多的工作；大部分工作是决定，而不是措辞。决策过程需要特定的心态，因此让一个人批量完成比一群开发人员一次做一小部分更有效。 （这样想：您不必不断地将作业的“提交消息客户检查”部分进出缓存。）
如果您确实想使用此类信息标记提交消息，您应该至少考虑使用 git Notes 而不是原始提交消息来完成此操作。然后，如果有人通过错误地将提交标记为错误/功能/等而搞砸了，您可以通过更新注释来修复它。
I've tried this myself with little luck in the past. Basically, it's actually more work to have every developer think, for every commit, about whether their commit message is too scary for customers or not. Developers are generally not the right person to make that decision, and doing it a bit at a time is inefficient.
After a lot of experimentation, what has worked for me is trivial: just before every release, have one person go through the git log since the last release and write down all the interesting stuff into a changelog file. This really isn't more work than the other way; most of the work is deciding, not phrasing. And the decision process requires a particular mindset, so it's more efficient to have one person do it in a big batch than a bunch of developers doing a tiny bit at a time. (Think of it this way: you don't have to keep swapping the "commit message customer checking" part of the job in and out of cache.)
If you really want to tag commit messages with this sort of information, you should at least consider doing it with
git notesinstead of the raw commit message. Then if someone screws it up by marking the commit incorrectly as bug/feature/etc, you can fix it by updating the annotation.我不知道有任何这样的标准工具，但由于您有一段时间没有得到答案，这里有一些想法：
所以首先，正如您所建议的，尝试避免 CHANGELOG 文件通常可能是一个好主意因为此类文件往往会导致所有合并冲突。 （除非您碰巧有一个智能自动合并工具。）
诸如 CL: 或 Log: 之类的前缀以便于提取可能是个好主意。关于Add/Ref/Rem/Fix：（我假设
Ref和Rem代表“重构”和“删除”，对吧？）当你编写变更日志时，我宁愿坚持使用自由格式的条目。例如，我不确定重构是否属于变更日志，并且足以保证变更日志条目的高级功能通常不会被彻底删除 - 它们而是会更改为其他形式。我想说，将 (
CL:-tagged) 高级描述放在提交消息的一个段落中，将较低级别的技术描述放在另一段落中。我们正在谈论这样的事情，对吗？
这就是我认为“自动变更日志”事情变得棘手的地方。除非您愿意在事后重新设置和编辑提交消息（例如从上面的提交（1）中删除“CL：”），否则我建议唯一实用的方法是，每次发布版本时，从 git 日志中提取自上次发布以来的所有标记段落，并手动编辑结果列表，将上面的 (1) 和 (2) 之类的内容合并在一起，然后转动，例如“Fixed #145”、“Fixed #153” ”、“修复#164”合并为一行“修复#145、#153 和#164”。
希望我能够提供一些灵感。让我们知道您最终会做什么！
I don't know of any such standard tool, but since you haven't gotten an answer for a while, here are some ideas:
So first, trying to avoid a CHANGELOG file, as you suggest, is probably a good idea in general because of all the merge conflicts such a file tends to cause. (Unless you happen to have a smart automatic merge tool.)
Something like a CL: or Log: prefix for easy extraction is probably a good idea. Regarding Add/Ref/Rem/Fix: (I assume that
RefandRemstand for "Refactor" and "Remove", right?) When you're writing a changelog, I'd rather stick with free-form entries. For example, I'm not sure that refactorings belong into a changelog, and features that are high-level enough to warrant changelog entries don't usually get removed outright -- they rather get changed into some other form.I'd say, put the (
CL:-tagged) high-level description in one paragraph of the commit message, and the lower level technical description in another paragraph.We're talking about something like this, right?
And this is where I think the "automatic changelog" thing gets tricky. Unless you're willing to rebase and edit commit messages after the fact (like removing "CL:" from commit (1) above), I'd suggest that the only practical way to go about this is, every time you make a release, to extract all tagged paragraphs from the git log since your last release, and manually edit the resulting list, merging things like (1) and (2) above together, and turning, say, "Fixed #145", "Fixed #153", "Fixed #164" into a single line "Fixed #145, #153, and #164."
Hope I've been able to provide some inspiration. Let us know what you end up doing!
查看 vclog。
Have a look at vclog.