在 DVCS 中维护 Changelog.txt 文件
我正在开发一个使用大量分支的 git 项目。在大多数情况下，这是一个非常棒的工作流程。我很高兴在分支之间进行合并，喜欢能够挑选代码，以及 git 和其他 dvc 附带的整体生命周期。
我有一个非常痛苦的痛点。如何维护changelog.txt。
我发现每当我进行合并时都会很痛苦（changelog.txt 经常发生冲突），并且当挑选提交时，我意外地设法拾取了真正不需要的更改。
我很想看到这个问题的一个好的答案。
I'm working on a git project that uses lots of branches. For the most part, this has been a really great workflow. I'm happy merging between branches, love being able to cherry-pick code, and the overall lifecycle that comes with git and other dvcs's.
I've got one pain point that is really hurting. How to maintain a changelog.txt.
I've found it hurts whenever I do a merge (the changelog.txt often conflicts), and when cherry-picking commits I've accidentally managed to pickup changes that really weren't desired.
I'd love to see a good answer to this problem.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一旦您准备好发布软件的新版本，您可以注释您的签入评论并解析这些评论（我想这是提供变更日志的最常见用例）。
评论可以通过以下方式构建（显然只有那些属于确实修改了值得注意的内容的提交）：
其中
WHAT可以是FIX用于错误修复CHG 表示更改NEW表示新代码WHERE应该是一个描述模块的单词，其中WHAT已完成。根据这两个信息，您可以提供详细描述修改的DESCRIPTION。准备好发布后，获取自上一个版本以来的日志并解析它们。可以使用 git log tagname_of_last_version.. 获取日志。有关输出和过滤选项，请参阅
git log的手册页。You could annotate your checkin comments and parse these comments once you're ready to ship a new version of your software (I guess that's the most common use case for providing a changelog).
The comments could be built the following way (obviously only those belonging to commits that do modify something noteworthy):
Where
WHATcould beFIXfor bug fixesCHGfor changesNEWfor new codeWHEREshould be one word describing the module whereWHATwas done. Following these two informations, you provide yourDESCRIPTIONdescribing the modification in deep.Once you're ready to ship, get the logs since the last version and parse them. The logs can be obtained using
git log tagname_of_last_version... See the man page ofgit logfor output and filtering options.