我已经使用Git有一段时间了，最近我开始使用它来标记我的版本，这样我就可以更容易地跟踪更改，并能够看到每个客户端正在运行的版本(不幸的是，当前的代码要求每个客户端都有自己的PHP站点副本;我正在改变这个，但它进展缓慢)。
在任何情况下，我们开始建立一些势头，我认为能够向人们展示自上个版本以来发生了什么变化是非常好的。问题是，我一直没有维护变更日志，因为我不知道如何去做。对于这个特定的时间，我可以遍历日志并手动创建一个，但这会很快让人厌倦。
我试着在谷歌上搜索“git变更日志”和“git管理变更日志”，但我没有找到任何真正谈论代码变更工作流的内容，以及它是如何与变更日志相一致的。我们目前正在遵循Rein Henrichs的开发工作流程，我希望能有一些与之相关的东西。
我是否遗漏了一个标准的方法，或者这是一个每个人都做自己事情的领域?
当前回答
GNU风格变更日志
对于GNU风格的更改日志，我已经烹煮了这个函数:
gnuc() {
{
printf "$(date "+%Y-%m-%d") John Doe <john.doe@gmail.com>\n\n"
git diff-tree --no-commit-id --name-only -r HEAD | sed 's/^/\t* /'
} | tee /dev/tty | xsel -b
}
用这个:
我定期将我的更改提交到备份中，并在对更改日志进行最终编辑之前重新编制它们 然后执行:gnuc
现在我的剪贴板包含如下内容:
2015-07-24 John Doe <john.doe@gmail.com>
* gdb/python/py-linetable.c (): .
* gdb/python/py-symtab.c (): .
然后使用剪贴板作为更新ChangeLog的起点。
这并不完美(例如，文件应该相对于它们的ChangeLog路径，所以python/py- symtable .c没有gdb/，因为我会编辑gdb/ChangeLog)，但这是一个很好的起点。
更高级的脚本:
GDB维护者Tromey的git-gnu-changelog GCC的contrib / mklog gcc / contrib / mklog
不过我不得不同意Tromey的观点:在更新日志中复制Git提交数据是没有用的。
如果你打算做一个变更日志，那就对正在发生的事情做一个很好的总结，可能就像Keep a changelog中指定的那样。
其他回答
GNU风格变更日志
对于GNU风格的更改日志，我已经烹煮了这个函数:
gnuc() {
{
printf "$(date "+%Y-%m-%d") John Doe <john.doe@gmail.com>\n\n"
git diff-tree --no-commit-id --name-only -r HEAD | sed 's/^/\t* /'
} | tee /dev/tty | xsel -b
}
用这个:
我定期将我的更改提交到备份中，并在对更改日志进行最终编辑之前重新编制它们 然后执行:gnuc
现在我的剪贴板包含如下内容:
2015-07-24 John Doe <john.doe@gmail.com>
* gdb/python/py-linetable.c (): .
* gdb/python/py-symtab.c (): .
然后使用剪贴板作为更新ChangeLog的起点。
这并不完美(例如，文件应该相对于它们的ChangeLog路径，所以python/py- symtable .c没有gdb/，因为我会编辑gdb/ChangeLog)，但这是一个很好的起点。
更高级的脚本:
GDB维护者Tromey的git-gnu-changelog GCC的contrib / mklog gcc / contrib / mklog
不过我不得不同意Tromey的观点:在更新日志中复制Git提交数据是没有用的。
如果你打算做一个变更日志，那就对正在发生的事情做一个很好的总结，可能就像Keep a changelog中指定的那样。
git log --oneline --no-merges `git describe --abbrev=0 --tags`..HEAD | cut -c 9- | sort
是我喜欢用的。它获得自最后一个标记以来的所有提交。Cut去掉了提交散列。如果您在提交消息的开头使用票号，则它们将按sort进行分组。如果你在某些提交前加上fix、typo等前缀，排序也会有帮助。
这是在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
