我已经使用Git有一段时间了，最近我开始使用它来标记我的版本，这样我就可以更容易地跟踪更改，并能够看到每个客户端正在运行的版本(不幸的是，当前的代码要求每个客户端都有自己的PHP站点副本;我正在改变这个，但它进展缓慢)。
在任何情况下，我们开始建立一些势头，我认为能够向人们展示自上个版本以来发生了什么变化是非常好的。问题是，我一直没有维护变更日志，因为我不知道如何去做。对于这个特定的时间，我可以遍历日志并手动创建一个，但这会很快让人厌倦。
我试着在谷歌上搜索“git变更日志”和“git管理变更日志”，但我没有找到任何真正谈论代码变更工作流的内容，以及它是如何与变更日志相一致的。我们目前正在遵循Rein Henrichs的开发工作流程，我希望能有一些与之相关的东西。
我是否遗漏了一个标准的方法，或者这是一个每个人都做自己事情的领域?
当前回答
TL;DR:您可能需要检查gitchangelog自己的更改日志或生成前一个更改日志的ASCII输出。
如果你想从Git历史记录中生成一个更新日志，你可能需要考虑:
the output format. (Pure custom ASCII, Debian changelog type, Markdown, REST, etc.) some commit filtering (you probably don't want to see all the typos or cosmetic changes getting in your changelog) some commit text wrangling before being included in the changelog. (Ensuring normalization of messages as having a first letter uppercase or a final dot, but it could be removing some special markup in the summary also.) is your Git history compatible?. Merging and tagging is not always so easily supported by most of the tools. It depends on how you manage your history.
可选地，您可能需要一些分类(新事物、更改、错误修复等)。
考虑到所有这些，我创建并使用了giitchangelog。它旨在利用Git提交消息约定来实现前面的所有目标。
要创建一个漂亮的变更日志，必须有提交消息约定(无论是否使用gitchangelog)。
提交消息约定
以下是关于在提交消息中添加哪些内容可能有用的建议。
你可能想把你的提交大致分成几个大的部分:
按意图(例如:新的、修复的、改变的等等) 按对象(例如:文档、打包、代码等) 按受众划分(例如:开发人员、测试人员、用户等)
此外，你可能想要标记一些提交:
作为“次要”提交，不应该输出到您的更改日志(装饰性的更改，注释中的一个小错别字，等等)。 作为“重构”，如果你真的没有任何重大的功能变化。因此，这也不应该是显示给最终用户的更改日志的一部分，但是如果您有一个开发人员更改日志，它可能会引起一些兴趣。 你也可以用“API”来标记API的变化或新的API内容… 等……
尽可能多地以用户(功能)为目标来编写提交信息。
例子
这是标准的git日志——一行显示如何存储这些信息:
* 5a39f73 fix: encoding issues with non-ASCII characters.
* a60d77a new: pkg: added ``.travis.yml`` for automated tests.
* 57129ba new: much greater performance on big repository by issuing only one shell command for all the commits. (fixes #7)
* 6b4b267 chg: dev: refactored out the formatting characters from Git.
* 197b069 new: dev: reverse ``natural`` order to get reverse chronological order by default. !refactor
* 6b891bc new: add UTF-8 encoding declaration !minor
如果你注意到，我选择的格式是:
{new|chg|fix}: [{dev|pkg}:] COMMIT_MESSAGE [!{minor|refactor} ... ]
要查看实际的输出结果，可以查看gitchangelog的PyPI页面的末尾。
要查看我的提交消息约定的完整文档，您可以查看引用文件gitchangelog.rc.reference。
如何从中生成一个精致的变更日志
然后，就可以很容易地进行一个完整的更改日志。您可以很快地编写自己的脚本，或者使用gitchangelog。
gitchangelog将生成一个完整的更改日志(支持新建、修复…)，并且可以根据您自己的提交约定进行合理配置。它通过Mustache模板、Mako模板支持任何类型的输出，并有一个用原始Python编写的默认遗留引擎;当前所有三个引擎都有如何使用它们的示例，并且可以输出与gitchangelog的PyPI页面上显示的相同的更改日志。
我相信你知道还有很多其他的git日志变更工具。
免责声明:我是gitchangelog的作者，我将在下面谈到它。
其他回答
这是在2015年，但为了未来的搜索者，现在可以生成华丽的日志:
git log --oneline --decorate
或者，如果你想让它更漂亮(用终端的颜色):
git log --oneline --decorate --color
我目前在我的所有项目中都使用将输出输出到ChangeLog的管道，这简直太神奇了。
一个更切题的更新日志:
git log --since=1/11/2011 --until=28/11/2011 --no-merges --format=%B
git log --oneline --no-merges `git describe --abbrev=0 --tags`..HEAD | cut -c 9- | sort
是我喜欢用的。它获得自最后一个标记以来的所有提交。Cut去掉了提交散列。如果您在提交消息的开头使用票号，则它们将按sort进行分组。如果你在某些提交前加上fix、typo等前缀，排序也会有帮助。
我让CI服务器为每个新版本输送以下内容到名为CHANGELOG的文件中，并在release-filename中设置日期:
git log --graph --all --date=relative --pretty=format:"%x09 %ad %d %s (%aN)"
由于为每个版本创建一个标记是最佳实践，您可能希望为每个版本划分您的变更日志。在这种情况下，这个命令可以帮助您:
git log YOUR_LAST_VERSION_TAG..HEAD --no-merges --format=%B
