git-cliff release workflow help

[awatterson22]

Hi I have a similar question to this discussion. What would be the best way to use generate a CHANGELOG.md with multiple sections like the following:

## [1.0.1] - 2021-07-18

### 🚜 Refactor

- *(parser)* Expose string functions

### ⚙️ Miscellaneous Tasks

- *(release)* Add release script

## [1.0.0] - 2021-07-18

### ⛰️  Features

- *(parser)* Add ability to parse arrays

### 🐛 Bug Fixes

- *(args)* Rename help argument due to conflict

### 📚 Documentation

- *(example)* [**breaking**] Add tested usage example
- *(project)* Add README.md

when your application generates a new release after every merge to develop? Currently my application has an automation to generate a release after every merge to develop, but it uses a squash merge so it will produce only one commit like this:

## [1.0.1] - 2021-07-18

### 🚜 Refactor

- *(parser)* Expose string functions <PR LINK>

## [1.0.0] - 2021-07-18

### ⛰️  Features

- *(parser)* Add ability to parse arrays <PR LINK>

So each release will have only one commit line, but I wanted to see if it would be possible to generate multiple sections by putting the commits from the PR in the extended body section and each commit in the body section could be treated as it's own message.

[ZX41R]

For the squash-merge shape, the option you probably want to try first is:

[git]
split_commits = true

That tells git-cliff to split a commit message on newlines and treat each line as a separate commit entry. There is a test fixture for exactly that behavior in the repo: a single commit message like

feat: add feature 1
feat: add feature 2
fix: fix feature 1

ends up grouped as separate Features/Bug Fixes entries.

The important constraint is that the lines in the squash commit message still need to be parseable by your commit_parsers. So this works well if your squash commit body contains plain conventional-commit lines, for example:

feat(parser): add ability to parse arrays
fix(args): rename help argument
refactor(parser): expose string functions

It will not automatically understand arbitrary PR markdown unless you either normalize it with commit_preprocessors or add parser rules that match your chosen body format.

So I would set up the release flow like this:

1. Keep the squash commit subject as the PR-level summary.
2. Put one changelog line per PR commit/change in the squash commit body, using conventional commit syntax.
3. Enable split_commits = true.
4. Keep your existing group template based on commits | group_by(attribute="group").

That gives you multiple changelog sections from one squash commit without needing to preserve every original commit in the final branch history.