我已经使用Git有一段时间了，最近我开始使用它来标记我的版本，这样我就可以更容易地跟踪更改，并能够看到每个客户端正在运行的版本(不幸的是，当前的代码要求每个客户端都有自己的PHP站点副本;我正在改变这个，但它进展缓慢)。
在任何情况下，我们开始建立一些势头，我认为能够向人们展示自上个版本以来发生了什么变化是非常好的。问题是，我一直没有维护变更日志，因为我不知道如何去做。对于这个特定的时间，我可以遍历日志并手动创建一个，但这会很快让人厌倦。
我试着在谷歌上搜索“git变更日志”和“git管理变更日志”，但我没有找到任何真正谈论代码变更工作流的内容，以及它是如何与变更日志相一致的。我们目前正在遵循Rein Henrichs的开发工作流程，我希望能有一些与之相关的东西。
我是否遗漏了一个标准的方法，或者这是一个每个人都做自己事情的领域?
当前回答
这是在2015年，但为了未来的搜索者，现在可以生成华丽的日志:
git log --oneline --decorate
或者，如果你想让它更漂亮(用终端的颜色):
git log --oneline --decorate --color
我目前在我的所有项目中都使用将输出输出到ChangeLog的管道，这简直太神奇了。
其他回答
gitlog-to-changelog脚本可以方便地生成一个gnu风格的ChangeLog。
如gitlog-to-changelog——help所示，您可以使用任一选项选择用于生成ChangeLog文件的提交——因为:
gitlog-to-changelog --since=2008-01-01 > ChangeLog
或者在——之后传递额外的参数，它将被传递给git-log(由gitlog-to-changelog内部调用):
gitlog-to-changelog -- -n 5 foo > last-5-commits-to-branch-foo
例如，我在顶级Makefile中使用以下规则。我的一个项目:
.PHONY: update-ChangeLog
update-ChangeLog:
if test -d $(srcdir)/.git; then \
$(srcdir)/build-aux/gitlog-to-changelog \
--format='%s%n%n%b%n' --no-cluster \
--strip-tab --strip-cherry-pick \
-- $$(cat $(srcdir)/.last-cl-gen).. \
>ChangeLog.tmp \
&& git rev-list -n 1 HEAD >.last-cl-gen.tmp \
&& (echo; cat $(srcdir)/ChangeLog) >>ChangeLog.tmp \
&& mv -f ChangeLog.tmp $(srcdir)/ChangeLog \
&& mv -f .last-cl-gen.tmp $(srcdir)/.last-cl-gen \
&& rm -f ChangeLog.tmp; \
fi
EXTRA_DIST += .last-cl-gen
该规则用于在发布时使用最新的尚未记录的提交消息更新ChangeLog。“.last-cl-gen”文件包含ChangeLog中记录的最近一次提交的SHA-1标识符，存储在Git存储库中。ChangeLog也被记录在存储库中，这样就可以在不改变提交消息的情况下对其进行编辑(例如纠正拼写错误)。
由于为每个版本创建一个标记是最佳实践，您可能希望为每个版本划分您的变更日志。在这种情况下，这个命令可以帮助您:
git log YOUR_LAST_VERSION_TAG..HEAD --no-merges --format=%B
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的作者，我将在下面谈到它。
一个更切题的更新日志:
git log --since=1/11/2011 --until=28/11/2011 --no-merges --format=%B
你可以使用一些git日志来帮助你:
git log --pretty=%s # Only prints the subject
如果你很好地命名你的分支，这样merge to master就会显示为“Merged branch feature-foobar”，你可以通过只显示该消息来缩短内容，而不显示你合并的所有小提交，这些小提交共同构成了这个特性:
git log --pretty=%s --first-parent # Only follow the first parent of merges
您可以使用自己的脚本来增强这一点，可以做一些事情，比如去掉“合并的分支”位，规范化格式等等。当然，有时候你必须自己写。
然后你可以为每个版本创建一个新的章节:
git log [opts] vX.X.X..vX.X.Y | helper-script > changelogs/X.X.Y
然后在你的版本release commit中提交。
如果您的问题是这些提交主题与您想要放入变更日志中的内容完全不同，那么您几乎有两个选择:继续手动完成所有事情(并尝试更定期地跟上它，而不是在发布时追赶它)，或者修复您的提交消息样式。
一种选择是，如果主题不打算为你做这件事，将在你的提交消息的主体中放置像“change: added feature foobar”这样的行，这样以后你就可以做一些像git log——pretty=%B | grep ^change:这样的事情来抓取那些非常重要的消息。
我不完全确定Git还能帮助您创建更改日志。也许我误解了你说的"管理"的意思?
