我已经使用Git有一段时间了,最近我开始使用它来标记我的版本,这样我就可以更容易地跟踪更改,并能够看到每个客户端正在运行的版本(不幸的是,当前的代码要求每个客户端都有自己的PHP站点副本;我正在改变这个,但它进展缓慢)。

在任何情况下,我们开始建立一些势头,我认为能够向人们展示自上个版本以来发生了什么变化是非常好的。问题是,我一直没有维护变更日志,因为我不知道如何去做。对于这个特定的时间,我可以遍历日志并手动创建一个,但这会很快让人厌倦。

我试着在谷歌上搜索“git变更日志”和“git管理变更日志”,但我没有找到任何真正谈论代码变更工作流的内容,以及它是如何与变更日志相一致的。我们目前正在遵循Rein Henrichs的开发工作流程,我希望能有一些与之相关的东西。

我是否遗漏了一个标准的方法,或者这是一个每个人都做自己事情的领域?


当前回答

我还为此做了一个库。它是完全可配置的胡子模板。能:

存储到一个文件中,如CHANGELOG.md。 发布到MediaWiki 或者直接打印到标准输出

我还做了:

一个Gradle插件 一个Maven插件 Jenkins插件 Bitbucket Server插件 命令行工具

更多详情见GitHub: https://github.com/tomasbjerre/git-changelog-lib

从命令行:

npx git-changelog-command-line -std -tec "
# Changelog

Changelog for {{ownerName}} {{repoName}}.

{{#tags}}
## {{name}}
 {{#issues}}
  {{#hasIssue}}
   {{#hasLink}}
### {{name}} [{{issue}}]({{link}}) {{title}} {{#hasIssueType}} *{{issueType}}* {{/hasIssueType}} {{#hasLabels}} {{#labels}} *{{.}}* {{/labels}} {{/hasLabels}}
   {{/hasLink}}
   {{^hasLink}}
### {{name}} {{issue}} {{title}} {{#hasIssueType}} *{{issueType}}* {{/hasIssueType}} {{#hasLabels}} {{#labels}} *{{.}}* {{/labels}} {{/hasLabels}}
   {{/hasLink}}
  {{/hasIssue}}
  {{^hasIssue}}
### {{name}}
  {{/hasIssue}}

  {{#commits}}
**{{{messageTitle}}}**

{{#messageBodyItems}}
 * {{.}}
{{/messageBodyItems}}

[{{hash}}](https://github.com/{{ownerName}}/{{repoName}}/commit/{{hash}}) {{authorName}} *{{commitTime}}*

  {{/commits}}

 {{/issues}}
{{/tags}}
"

或者用詹金斯的话来说:

其他回答

git log --oneline --no-merges `git describe --abbrev=0 --tags`..HEAD | cut -c 9- | sort

是我喜欢用的。它获得自最后一个标记以来的所有提交。Cut去掉了提交散列。如果您在提交消息的开头使用票号,则它们将按sort进行分组。如果你在某些提交前加上fix、typo等前缀,排序也会有帮助。

你可以使用一些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还能帮助您创建更改日志。也许我误解了你说的"管理"的意思?

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的作者,我将在下面谈到它。

基于bithavoc,下面列出了HEAD之前的最后一个标记。但是我希望列出两个标签之间的日志。

// Two or three dots between `YOUR_LAST_VERSION_TAG` and `HEAD`
git log YOUR_LAST_VERSION_TAG..HEAD --no-merges --format=%B

列出两个标记之间的日志:

// Two or three dots between two tags
git log FROM_TAG...TO_TAG

例如,这将列出从v1.0.0到v1.0.1的日志:

git log v1.0.0...v1.0.1 --oneline --decorate

一个更切题的更新日志:

git log --since=1/11/2011 --until=28/11/2011 --no-merges --format=%B