开源软件名称：

开源软件地址：

开源编程语言：

开源软件介绍：

About

git-cliff can generate changelog files from the Git history by utilizing conventional commits as well as regex-powered custom parsers. The changelog template can be customized with a configuration file to match the desired format.

Installation

From crates.io

git-cliff can be installed from crates.io:

cargo install git-cliff

Minimum supported Rust version is 1.58.1.

Using pacman

If you are using Arch Linux, git-cliff can be installed from the community repository:

pacman -S git-cliff

Binary releases

See the available binaries for different operating systems/architectures from the releases page.

* Release tarballs are signed with the following PGP key: 1D2D410A741137EBC544826F4A92FA17B6619297

Build from source

• Linux dependencies: zlib

# binary will be located at `target/release/git-cliff`
CARGO_TARGET_DIR=target cargo build --release

Usage

Command Line Arguments

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

Flags:

-v, --verbose       Increases the logging verbosity
-i, --init          Writes the default configuration file to cliff.toml
-l, --latest        Processes the commits starting from the latest tag
    --current       Processes the commits that belong to the current tag
-u, --unreleased    Processes the commits that do not belong to a tag
    --date-order    Sorts the tags chronologically
    --context       Prints changelog context as JSON
-h, --help          Prints help information
-V, --version       Prints version information

Options:

-c, --config <PATH>                Sets the configuration file [env: GIT_CLIFF_CONFIG=] [default: cliff.toml]
-w, --workdir <PATH>               Sets the working directory [env: GIT_CLIFF_WORKDIR=]
-r, --repository <PATH>            Sets the git repository [env: GIT_CLIFF_REPOSITORY=]
    --include-path <PATTERN>...    Sets the path to include related commits [env: GIT_CLIFF_INCLUDE_PATH=]
    --exclude-path <PATTERN>...    Sets the path to exclude related commits [env: GIT_CLIFF_EXCLUDE_PATH=]
    --with-commit <MSG>...         Sets custom commit messages to include in the changelog [env: GIT_CLIFF_WITH_COMMIT=]
-p, --prepend <PATH>               Prepends entries to the given changelog file [env: GIT_CLIFF_PREPEND=]
-o, --output <PATH>                Writes output to the given file [env: GIT_CLIFF_OUTPUT=]
-t, --tag <TAG>                    Sets the tag for the latest version [env: GIT_CLIFF_TAG=]
-b, --body <TEMPLATE>              Sets the template for the changelog body [env: GIT_CLIFF_TEMPLATE=]
-s, --strip <PART>                 Strips the given parts from the changelog [possible values: header, footer, all]
    --sort <SORT>                  Sets sorting of the commits inside sections [default: oldest] [possible values: oldest, newest]

Args:

<RANGE>    Sets the commit range to process

Examples

The default configuration file (cliff.toml) can be generated using the --init flag:

# create cliff.toml
git cliff --init

Then simply create a changelog at your projects git root directory:

# same as running `git-cliff --config cliff.toml --repository .`
# same as running `git-cliff --workdir .`
git cliff

Set a tag for the "unreleased" changes:

# it doesn't have to be an existing tag
git cliff --tag 1.0.0

Generate a changelog for a certain part of git history:

# only takes the latest tag into account
git cliff --latest

# only takes the current tag into account
# useful if you checkout a specific tag (e.g. `git checkout v0.0.1`)
# (requires a tag to be present for the current commit (i.e. HEAD))
git cliff --current

# generate changelog for unreleased commits
git cliff --unreleased
git cliff --unreleased --tag 1.0.0

# generate changelog for a specific commit range
git cliff 4c7b043..a440c6e
git cliff 4c7b043..HEAD
git cliff HEAD~2..

Generate a changelog scoped to a specific directory (useful for monorepos):

git cliff --include-path "**/*.toml" --include-path "*.md"
git cliff --exclude-path ".github/*"

Generate a changelog that includes yet unexisting commit messages:

commit_msg="chore(release): update CHANGELOG.md for 1.0.0"

# You might need to include the commit messages that do not exist
# for testing purposes or solving the chicken-egg problem.
git cliff --with-commit "$commit_msg" -o CHANGELOG.md

git add CHANGELOG.md && git commit -m "$commit_msg"

Sort the commits inside sections:

# The oldest commit will be on top.
# (default)
git cliff --sort oldest

# The newest commit will be on top.
git cliff --sort newest

Sort the tags in chronological order:

# Process in chronological order instead of topological.
git cliff --date-order

Save the changelog file to the specified file:

git cliff --output CHANGELOG.md

Print the changelog context as JSON:

# print context to stdout
git cliff --context

# save context to a file
git cliff --context --output context.json

Prepend new changes to an existing changelog file:

# 1- changelog header is removed from CHANGELOG.md
# 2- new entries are prepended to CHANGELOG.md without footer part
git cliff --unreleased --tag 1.0.0 --prepend CHANGELOG.md

Set/remove the changelog parts:

git cliff --body $template --strip footer

Also, see the release script of this project which sets the changelog as a message of an annotated tag.

Docker

The easiest way of running git-cliff (in the git root directory with configuration file present) is to use the available tags from Docker Hub:

docker run -t -v "$(pwd)/.git":/app/ orhunp/git-cliff:latest

Or you can use the image from the GitHub Package Registry:

docker run -t -v "$(pwd)/.git":/app/ docker.pkg.github.com/orhun/git-cliff/git-cliff:latest

Also, you can build the image yourself using docker build -t git-cliff . command.

GitHub Actions

git-cliff-action

It is possible to generate changelogs using GitHub Actions via git-cliff-action.

- name: Generate a changelog
  uses: orhun/git-cliff-action@v1
  with:
    config: cliff.toml
    args: --verbose
  env:
    OUTPUT: CHANGELOG.md

See the repository for other examples.

Also, see the continuous deployment workflow of this project which sets the release notes for GitHub releases using this action.

setup-git-cliff

There is also another GitHub Action which is setup-git-cliff.

While git-cliff-action uses the Docker image generated by docker.yml, setup-git-cliff installs the binary executable in the release artifacts:

- name: Check out repository
  uses: actions/checkout@v2

- name: Set up git-cliff
  uses: kenji-miyake/setup-git-cliff@v1

- name: Run git-cliff
  run: |
    git cliff

See a practical example here.

GitLab CI/CD

It is possible to generate changelogs using GitLab CI/CD.

This minimal example creates artifacts that can be used on another job.

- changelog:
    image:
      name: orhunp/git-cliff:latest
      entrypoint: [""]
    variables:
      GIT_STRATEGY: clone # clone entire repo instead of reusing workspace
      GIT_DEPTH: 0 # avoid shallow clone to give cliff all the info it needs
    stage: doc
    script:
      - git-cliff -r . > CHANGELOG.md
    artifacts:
      paths:
        - CHANGELOG.md

Please note that the stage is doc and has to be changed accordingly to your need.

Configuration File

git-cliff configuration file supports TOML (preferred) and YAML formats.

The configuration file is read from $HOME/git-cliff/cliff.toml if the file exists. This location depends on the platform, for example:

• on Linux: /home/<user>/.config/git-cliff/cliff.toml
• on Windows: C:\Users\<user>\AppData\Roaming\git-cliff\cliff.toml
• on macOS: /Users/<user>/Library/Application Support/git-cliff/cliff.toml

See config/cliff.toml for the default configuration values.

changelog

This section contains the configuration options for changelog generation.

[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

Header text that will be added to the beginning of the changelog.

body

Body template that represents a single release in the changelog.

See templating for more detail.

trim

If set to true, leading and trailing whitespace are removed from the body.

It is useful for adding indentation to the template for readability, as shown in the example.

footer

Footer text that will be added to the end of the changelog.

git

This section contains the parsing and git related configuration options.

[git]
conventional_commits = true
filter_unconventional = 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"
ignore_tags = ""
date_order = false
sort_commits = "oldest"
link_parsers = [
    { pattern = "#(\\d+)", href = "https://github.com/orhun/git-cliff/issues/$1"},
    { pattern = "RFC(\\d+)", text = "ietf-rfc$1", href = "https://datatracker.ietf.org/doc/html/rfc$1"},
]

conventional_commits

If set to true, commits are parsed according to the Conventional Commits specifications.

The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages.

The commit message should be structured as follows:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

e.g. feat(parser): add ability to parse arrays

filter_unconventional

If set to true, commits that are not conventional are excluded. This option can be used to generate changelogs with conventional and unconvential commits mixed together. For example:

conventional_commits = true
filter_unconventional = false
commit_parsers = [
  { message = ".*", group = "Other", default_scope = "other"},
]

With the configuration above, conventional commits are parsed as usual and unconventional commits will be also included in the changelog as "Other".

To completely exclude unconventional commits from the changelog:

# default behaviour
conventional_commits = true
filter_unconventional = true

To include any type of commit in the changelog without parsing:

conventional_commits = false
filter_unconventional = false

commit_preprocessors

An array of commit preprocessors for manipulating the commit messages before parsing/grouping them. These regex-based preprocessors can be used for removing or selecting certain parts of the commit message/body to be used in the following processes.

Examples:

• { pattern = "foo", replace = "bar"}
  • Replace text.
• { pattern = 'Merged PR #[0-9]: (.*)', replace = "$1"}
  • Remove prefix.
• { pattern = " +", replace = " "}
  • Replace multiple spaces with a single space.
• { pattern = "\\(#([0-9]+)\\)", replace = "([#${1}](https://github.com/orhun/git-cliff/issues/${1}))"}
  • Replace the issue number with the link.
• { pattern = "https://github.com/[^ ]/issues/([0-9]+)", replace = "[Issue #${1}]"}
  • Replace the issue link with the number.
• { pattern = "Merge pull request #([0-9]+) from [^ ]+", replace = "PR # [${1}](https://github.com/orhun/git-cliff/pull/${1}):"}
  • Hyperlink PR references from merge commits.
• { pattern = "https://github.com/orhun/git-cliff/commit/([a-f0-9]{7})[a-f0-9]*", replace = "commit # [${1}](${0})"}
  • Hyperlink commit links, with short commit hash as description.
• { pattern = "([ \\n])(([a-f0-9]{7})[a-f0-9]*)", replace = "${1}commit # [${3}](https://github.com/orhun/git-cliff/commit/${2})"}
  • Hyperlink bare commit hashes like "abcd1234" in commit logs, with short commit hash as description.

Custom OS commands can also be used for modifying the commit messages:

• { pattern = "foo", replace_command = "pandoc -t commonmark"}

This is useful when you want to filter/encode messages using external commands. In the example above, pandoc is used to convert each commit message that matches the given pattern to the CommonMark format.

A more fun example would be reversing the each commit message:

• { pattern = '.*', replace_command = 'rev | xargs echo "reversed: $@"' }

$COMMIT_SHA environment variable is set during execution of the command so you can do fancier things like reading the commit itself:

• { pattern = '.*', replace_command = 'git show -s --format=%B $COMMIT_SHA' }

commit_parsers

An array of commit parsers for determining the commit groups by using regex.

Examples:

• { message = "^feat", group = "Features"}
  • Group the commit as "Features" if the commit message (description) starts with "feat".
• { body = ".*security", group = "Security"}
  • Group the commit as "Security" if the commit body contains "security".
• { message = ".*deprecated", body = ".*deprecated", group = "Deprecation"}
  • Group the commit as "Deprecation" if the commit body and message contains "deprecated".
• { message = "^revert", skip = true}
  • Skip processing the commit if the commit message (description) starts with "revert".
• { message = "^doc", group = "Documentation", default_scope = "other"},
  • If the commit starts with "doc", group the commit as "Documentation" and set the default scope to "other". (e.g. docs: xyz will be processed as docs(other): xyz)

filter_commits

If set to true, commits that are not matched by commit parsers are filtered out.

tag_pattern

A glob pattern for matching the git tags.

e.g. It processes the same tags as the output of the following git command:

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

skip_tags

A regex for skip processing the matched tags.

ignore_tags

A regex for ignore processing the matched tags.

While skip_tags drop commits from the changelog, ignore_tags include ignored commits into the next