当前位置：theitroad>使用 git 管理变更日志的好方法？

使用 git 管理变更日志的好方法？

声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow 原文地址: http://stackoverflow.com/questions/3523534/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示：将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间：2020-09-10 08:55:36 　来源:igfitidea点击:

Good ways to manage a changelog using git?

gitgithubchangelog

提问by Topher Fangio

I've been using Git for a while now, and I recently started using it to tag my releases so that I could more easily keep track of changes and be able to see which version each of our clients are running (unfortunately the code currently mandates that each client have their own copy of the PHP site; I'm changing this, but it's slow-going).

我已经使用 Git 有一段时间了，最​​近我开始使用它来标记我的发布，以便我可以更轻松地跟踪更改并能够查看我们每个客户端正在运行的版本（不幸的是，代码目前要求每个客户都有自己的 PHP 站点副本；我正在更改这一点，但速度很慢）。

In any case, we're starting to build some momentum, I thought it would be really good to be able to show people what has changed since the last release. Problem is, I haven't been maintaining a changelog because I don't have a good idea of how to go about it. For this particular time, I can run through the log and manually create one, but that will get tiring very quickly.

无论如何，我们开始建立一些势头，我认为能够向人们展示自上次发布以来发生的变化真的很好。问题是，我没有维护变更日志，因为我不知道如何去做。在这个特殊的时间里，我可以浏览日志并手动创建一个，但这会很快变得很累。

I tried googling "git changelog" and "git manage changelog" but I didn't find anything that really talked about the workflow of code changes and how that coincides with the changelog. We're currently following Rein Henrichs' development workflowand I would love something that went along with that.

我尝试在谷歌上搜索“git changelog”和“git manage changelog”，但我没有找到任何真正谈论代码更改工作流程的内容以及它与更改日志的一致性。我们目前正在关注Rein Henrichs 的开发工作流程，我会喜欢与之相伴的东西。

Is there a standard approach that I am missing, or is this an area where everybody does their own thing?

是否有我缺少的标准方法，或者这是每个人都做自己的事情的领域？

Thanks very much for your comments/answers!

非常感谢您的评论/回答！

采纳答案by Topher Fangio

This was about 3-4 years ago, but for the sake of future searchers, it's now possible to generate gorgeous logs with:

这是大约 3-4 年前，但为了未来的搜索者，现在可以使用以下方式生成华丽的日志：

git log --oneline --decorate

Or, if you want it even prettier (with color for terminal):

或者，如果你想要它更漂亮（终端颜色）：

git log --oneline --decorate --color

Piping that output to ChangeLog is what I currently use in all my projects, it's simply amazing.

将输出传送到 ChangeLog 是我目前在所有项目中使用的，这简直太棒了。

回答by Cascabel

You can use some flavor of git log to help you out:

你可以使用一些 git log 来帮助你：

git log --pretty=%s                 # only print the subject

If you name your branches nicely, so that a merge to master shows up as something like "Merged branch feature-foobar", you can shorten things by only showing that message, and not all the little commits that you merged, which together form the feature:

如果你很好地命名你的分支，以便与 master 的合并显示为类似“合并分支功能 foobar”的东西，你可以通过只显示该消息来缩短事情，而不是你合并的所有小提交，它们一起形成特征：

git log --pretty=%s --first-parent  # only follow first parent of merges

You might be able to augment this with a script of your own, which could do things like strip out the "Merged branch" bits, normalize formatting, etc. At some point you have to write it yourself though, of course.

您也许可以使用自己的脚本来增强它，它可以执行诸如去除“合并分支”位、标准化格式等操作。当然，在某些时候，您必须自己编写它。

Then you could create a new section for the changelog once per version:

然后，您可以为每个版本的变更日志创建一个新部分：

git log [opts] vX.X.X..vX.X.Y | helper-script > changelogs/X.X.Y

and commit that in your version release commit.

并在您的版本发布提交中提交。

If your problem is that those commit subjects aren't anything like what you'd want to put in a changelog, you pretty much have two options: keep doing everything manually (and try to keep up with it more regularly instead of playing catch-up at release time), or fix up your commit message style. One option, if the subjects aren't going to do it for you, would be to place lines like "change: added feature foobar" in the bodies of your commit messages, so that later you could do something like git log --pretty=%B | grep ^change:to grab only those super-important bits of the messages.

如果您的问题是那些提交主题与您想要放入变更日志的内容不同，那么您几乎有两个选择：继续手动完成所有工作（并尝试更经常地跟上它而不是玩捉迷藏-在发布时更新），或修复您的提交消息样式。一种选择，如果主题不打算为您做，将在提交消息的正文中放置诸如“更改：添加功能foobar”之类的行，以便稍后您可以执行诸如git log --pretty=%B | grep ^change:仅抓取那些超级- 消息的重要部分。

I'm not entirely sure how much more than that git could really help you create your changelogs. Maybe I've misinterpreted what you mean by "manage"?

我不完全确定 git 能真正帮助你创建你的变更日志。也许我误解了您所说的“管理”是什么意思？

回答by vaab

DISCLAIMER:I'm the author of gitchangelogof which I'll be speaking in the following.

免责声明：我是gitchangelog的作者，我将在下面谈到。

TL;DR:You might want to check gitchangelog's own changelogor the ascii outputthat generated the previous.

TL;DR：您可能想要检查gitchangelog 自己的变更日志或生成前一个变更日志的ascii 输出。

If you want to generate a changelog from your git history, you'll probably have to consider:

如果您想从您的 git 历史记录生成变更日志，您可能需要考虑：

  • the output format. (Pure custom ASCII, Debian changelog type, Markdow, ReST...)
  • some commit filtering(you probably don't want to see all the typo's or cosmetic changes getting in your changelog)
  • some commit text wranglingbefore 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, tagging, is not always so easily supported by most of the tools. It depends on how you manage your history.
  • 在输出格式。（纯自定义 ASCII、Debian 变更日志类型、Markdow、ReST...）
  • 一些提交过滤（您可能不希望在您的变更日志中看到所有错字或外观更改）
  • 在包含在更改日志中之前，一些提交文本会发生争执。（确保消息规范化为首字母大写或最后一个点，但也可能删除摘要中的一些特殊标记）
  • 你的git 历史兼容吗？大多数工具并不总是那么容易支持合并、标记。这取决于您如何管理您的历史记录。

Optionaly you might want some categorization (new things, changes, bugfixes)...

可选地，您可能需要一些分类（新事物、更改、错误修正）...

With all this in mind, I created and use gitchangelog. It's meant to leverage a git commit message conventionto achieve all of the previous goals.

考虑到所有这些，我创建并使用了gitchangelog。它旨在利用git commit 消息约定来实现所有先前的目标。

Having a commit message convention is mandatory to create a nice changelog (with or without using gitchangelog).

必须有提交消息约定才能创建一个不错的更改日志（使用或不使用gitchangelog）。

commit message convention

提交消息约定

The following are suggestions to what might be useful to think about adding in your commit messages.

以下是对考虑添加提交消息可能有用的建议。

You might want to separate roughly your commits into big sections:

您可能希望将提交大致分为几个大部分：

  • by intent (for example: new, fix, change ...)
  • by object (for example: doc, packaging, code ...)
  • by audience (for example: dev, tester, users ...)
  • 按意图（例如：新建、修复、更改...）
  • 按对象（例如：文档、包装、代码...）
  • 按受众（例如：开发人员、测试人员、用户...）

Additionally, you could want to tag some commits:

此外，您可能想要标记一些提交：

  • as "minor" commits that shouldn't get outputed to your changelog (cosmetic changes, small typo in comments...)
  • as "refactor" if you don't really have any significative feature changes. Thus this should not also be part of the changelog displayed to final user for instance, but might be of some interest if you have a developer changelog.
  • you could tag also with "api" to mark API changes or new API stuff...
  • ...etc...
  • 作为不应输出到您的更改日志的“次要”提交（外观更改，注释中的小错字......）
  • 如果您真的没有任何有意义的功能更改，则作为“重构”。因此，这不应该也是显示给最终用户的变更日志的一部分，但如果您有开发人员变更日志，则可能会有一些兴趣。
  • 您还可以使用“api”标记来标记 API 更改或新的 API 内容...
  • ...等等...

Try to write your commit message by targeting users (functionality) as often as you can.

尝试通过尽可能多地针对用户（功能）来编写提交消息。

example

例子

This is standard git log --onelineto show how these information could be stored::

这是git log --oneline显示如何存储这些信息的标准：

* 5a39f73 fix: encoding issues with non-ascii chars.
* 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

So if you've noticed, the format I chose is:

所以如果你注意到了，我选择的格式是：

{new|chg|fix}: [{dev|pkg}:] COMMIT_MESSAGE [!{minor|refactor} ... ]

To see an actual output result, you could look at the end of the PyPI page of gitchangelog

要查看实际输出结果，您可以查看gitchangelog的 PyPI 页面的末尾

To see a full documentation of my commit message convention you can see the reference file gitchangelog.rc.reference

要查看我的提交消息约定的完整文档，您可以查看参考文件gitchangelog.rc.reference

How to generate exquisite changelog from this

如何从中生成精美的变更日志

Then, it's quite easy to make a complete changelog. You could make your own script quite quickly, or use gitchangelog.

然后，制作完整的变更日志非常容易。您可以非常快速地制作自己的脚本，或者使用gitchangelog.

gitchangelogwill generate a full changelog (with sectioning support as New, Fix...), and is reasonably configurable to your own committing conventions. It supports any type of output thanks to templating through Mustache, Mako templating, and has a default legacy engine written in raw python ; all current 3 engines have examples of how to use them and can output changelog's as the one displayed on the PyPI page of gitchangelog.

gitchangelog将生成一个完整的更改日志（具有分区支持New，Fix...），并且可以根据您自己的提交约定进行合理配置。由于通过Mustache,进行模板化，它支持任何类型的输出Mako templating，并且具有用原始 python 编写的默认遗留引擎；所有当前的 3 个引擎都有如何使用它们的示例，并且可以输出更改日志作为 gitchangelog 的 PyPI 页面上显示的更改日志。

I'm sure you know that there are plenty of other git logto changelogtools out there also.

我相信你知道还有很多其他git log的changelog工具。

回答by Harshniket Seta

A more to the point CHANGELOG. Tell me if you people like it.

更重要的 CHANGELOG。告诉我你们是否喜欢它。

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

回答by Roland Levillain

The gitlog-to-changelogscript comes in handy to generate a GNU-style ChangeLog.

该gitlog-to-changelog脚本可用于生成 GNU 风格的ChangeLog.

As shown by gitlog-to-changelog --help, you may select the commits used to generate a ChangeLogfile using either the option --since:

如 所示gitlog-to-changelog --help，您可以ChangeLog使用以下任一选项选择用于生成文件的提交--since：

gitlog-to-changelog --since=2008-01-01 > ChangeLog

or by passing additional arguments after --, which will be passed to git-log(called internally by gitlog-to-changelog):

或者在 之后传递额外的参数--，这些参数将被传递给git-log（由 内部调用gitlog-to-changelog）：

gitlog-to-changelog -- -n 5 foo > last-5-commits-to-branch-foo

For instance, I am using the following rule in the top-level Makefile.amof one of my projects:

例如，我在Makefile.am我的一个项目的顶层使用以下规则：

.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

This rule is used at release time to update ChangeLogwith the latest not-yet-recorded commit messages. The file .last-cl-gencontains the SHA1 identifier of the latest commit recorded in ChangeLogand is stored in the Git repository. ChangeLogis also recorded in the repository, so that it can be edited (e.g. to correct typos) without altering the commit messages.

此规则在发布时用于更新ChangeLog最新的尚未记录的提交消息。该文件.last-cl-gen包含记录的最新提交的 SHA1 标识符，ChangeLog并存储在 Git 存储库中。 ChangeLog也记录在存储库中，以便可以在不更改提交消息的情况下对其进行编辑（例如纠正拼写错误）。

回答by bithavoc

Since creating a tag per version is the best practice, you may want to partition your changelog per version. In that case, this command could help you:

由于为每个版本创建标签是最佳实践，因此您可能希望按版本对变更日志进行分区。在这种情况下，此命令可以帮助您：

git log YOUR_LAST_VERSION_TAG..HEAD --no-merges --format=%B

回答by skywinder

For GitHubprojects it might be useful: github-changelog-generator

对于GitHub项目，它可能有用：github-changelog-generator

It generates changelog from tags closed issues,and merged pull-requests.

它从标记关闭的问题和合并的拉取请求生成变更日志。

This CHANGELOG.mdwas generated by this script.

这个CHANGELOG.md是由这个脚本生成的。

Example:

例子：

Changelog

1.2.5(2015-01-15)

Full Changelog

Implemented enhancements:

  • Use milestone to specify in which version bug was fixed #22

Fixed bugs:

  • Error when trying to generate log for repo without tags #32

Merged pull requests:

  • PrettyPrint class is included using lowercase 'pp' #43(schwing)

  • support enterprise github via command line options #42(glenlovett)

变更日志

1.2.5(2015-01-15)

完整更新日志

已实现的增强功能：

  • 使用里程碑指定修复了哪个版本的错误#22

修复了错误：

  • 尝试为没有标签的 repo 生成日志时出错#32

合并拉取请求：

回答by Tomas Bjerre

I also made a library for this. It is fully configurable with a Mustache template. That can:

我还为此创建了一个库。它完全可以使用 Mustache 模板进行配置。这样可以：

I also made:

我还做了：

More details on Github: https://github.com/tomasbjerre/git-changelog-lib

关于 Github 的更多细节：https: //github.com/tomasbjerre/git-changelog-lib

From command line:

从命令行：

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}}
"

Or in Jenkins:

或者在詹金斯：

enter image description here

在此处输入图片说明

回答by orkoden

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

Is what I like to use. It gets all commits since the last tag. cutgets rid of the commit hash. If you use ticket numbers at the beginning of your commit messages, they are grouped with sort. Sorting also helps if you prefix certain commits with fix, typo, etc.

是我喜欢用的。它获取自上一个标签以来的所有提交。cut摆脱提交哈希。如果您在提交消息的开头使用票号，它们将与sort. 如果您在某些提交前加上, 等fix，排序也会有所帮助typo。

回答by Lorenz Lo Sauer

I let the CI server pipe the following into a file named CHANGELOGfor a each new release with the date set in the release-filename:

我让 CI 服务器将以下内容通过管道传输到一个以CHANGELOG发布文件名中设置的日期为每个新版本命名的文件中：

>git log --graph --all --date=relative --pretty=format:"%x09 %ad %d %s (%aN)"

相关推荐

Git：如何从远程源主机更新/检出单个文件？

Git：如何从远程源主机更新/检出单个文件？

Git 不会初始化/同步/更新新的子模块

Git 不会初始化/同步/更新新的子模块

git 如何在同一分支上的两个不同提交之间区分同一文件？

git 如何在同一分支上的两个不同提交之间区分同一文件？

git pull VS git fetch VS git rebase

git pull VS git fetch VS git rebase

相关推荐
最近更新
标签