关于ide:33k-Star实用命令行工具自动生成更新日志文件

【导语】：基于 Git 历史记录主动生成日志变更文件。

git-cliff 可用失常提交记录以及基于正则的自定义解析，从 Git 历史记录生成 changelog 文件，变更日志模板能够应用配置文件进行定制，以匹配所需的格局。

相似的我的项目还有：

git-journal – Git 提交音讯和变更日志生成框架
clog-cli – 从 Git 提交历史生成丑陋的变更日志
relnotes – 为我的项目主动生成发行阐明的工具
cocogitto – 用于惯例提交和 semver 标准的 CLI 工具

我的项目地址：

https://github.com/orhun/git-…

cargo install git-cliff

pacman -S git-cliff

# linux 下依赖 zlib，生成的文件寄存在 `target/release/git-cliff` 目录
CARGO_TARGET_DIR=target cargo build --release

git-cliff [FLAGS] [OPTIONS] [RANGE]

应用 –init 选项能够生成默认的配置文件 cliff.toml

git cliff --init

在我的项目的根目录下，能够很简略地生成 changlog 文件：

# 等价于 `git-cliff --config cliff.toml --repository .`
# 等价于 `git-cliff --workdir .`
git cliff

打 tag：

git cliff --tag 1.0.0

为 git 历史的某个局部生成 changelog：

# 为 latest tag 生成 changelog
git cliff --latest

# 为未公布的外部生成 changelog
git cliff --unreleased
git cliff --unreleased --tag 1.0.0

# 为指定的某个 commit 生成 changelog
git cliff 4c7b043..a440c6e
git cliff 4c7b043..HEAD
git cliff HEAD~2..

指定生成某个目录的 changelog：

git cliff --commit-path project1/

将 changelog 保留到指定文件中

git cliff --output CHANGELOG.md

将新变更追加到 changelog 中：

git cliff --unreleased --tag 1.0.0 --prepend CHANGELOG.md

git-cliff 配置文件反对 TOML（首选）和 YAML 格局。

如果 $HOME/git-cliff/cliff.toml 文件存在，则从配置文件中读取。此地位取决于不同的平台，例如：

# 在 Linux 上：/home/<user>/.config/git-cliff/cliff.toml
# 在 Windows 上：C:\Users\<user>\AppData\Roaming\git-cliff\cliff.toml
# 在 macOS 上：/Users/<user>/Library/Application Support/git-cliff/cliff.toml

changelog 生成的配置选项如下：

[changelog]
header = "Changelog"
body = """{% for group, commits in commits | group_by(attribute="group") %}
    ### {{group | upper_first}}
    {% for commit in commits %}
        - {{commit.message | upper_first}}
    {% endfor %}
{% endfor %}
"""
trim = true
footer = "<!-- generated by git-cliff -->"

header，changelog 的题目
body，changelog 中的主体模板
trim，如果设置为 true，将删除文本中前导和尾随空格
footer，changelog 的页脚文本

git 相干的配置选项：

[git]
conventional_commits = true
commit_parsers = [{ message = "^feat", group = "Features"},
    {message = "^fix", group = "Bug Fixes"},
    {message = "^doc", group = "Documentation"},
    {message = "^perf", group = "Performance"},
    {message = "^refactor", group = "Refactor"},
    {message = "^style", group = "Styling"},
    {message = "^test", group = "Testing"},
]
filter_commits = false
tag_pattern = "v[0-9]*"
skip_tags = "v0.1.0-beta.1"

conventional_commits

如果设置为 true，则依据约定式提交标准进行解析提交。标准参考上面链接地址：

https://www.conventionalcommits.org/en/v1.0.0/

约定式提交标准是一种基于提交信息的轻量级约定。提供一组简略规定来创立清晰的提交历史；这有利于编写自动化工具。通过在提交信息中形容性能、修复和破坏性变更，使这种常规与 SemVer 互相对应。

提交阐明的构造如下所示：

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

# 如：feat(parser): add ability to parse arrays

commit_parsers

提交解析器，用于应用正则表达式确定提交组：

# 如果提交音讯以“feat”结尾，则将提交分组为“Features”。{message = "^feat", group = "Features"}

# 如果提交注释蕴含“security”，则将提交分组为“Security”。{body = ".*security", group = "Security"}

# 如果提交注释和音讯蕴含“deprecated”，则将提交分组为“Deprecation”{message = ".*deprecated", body = ".*deprecated", group = "Deprecation"}

# 如果提交音讯（形容）以“revert”结尾，则跳过解决提交。{message = "^revert", skip = true}

# 如果提交以“doc”结尾，则将提交分组为“Documentation”{message = "^doc", group = "Documentation", default_scope = "other"}

filter_commits

如果设置为 true，则提交解析器不匹配的提交将被过滤掉。

tag_pattern

用于匹配 git 标签的 glob 模式。例如，它解决与以下 git 命令的输入雷同的标签：

git tag --list 'v[0-9]*'

skip_tags

用于跳过解决匹配标签的正则表达式。

开源前哨 日常分享热门、乏味和实用的开源我的项目。参加保护 10 万 + Star 的开源技术资源库，包含：Python、Java、C/C++、Go、JS、CSS、Node.js、PHP、.NET 等。

关于ide:33k-Star实用命令行工具自动生成更新日志文件

简介

装置

从 crates.io 进行装置

应用 pacman

从源码构建

用法

命令格局

例子