Flag to avoid creating a new commit for the bump

Description

Since I use git tags to control the version there's no need to create a commit for the new tag when calling bump. Adding the tag to the latest commit would do just fine.

Possible Solution

Adding a flag like --no-commit to not create a commit during the bump, causing the tag to point to the latest existing commit.

cz bump --no-commit

Additional context

No response

Additional context

No response

Can you explain a bit more? Would --files-only work for you? https://commitizen-tools.github.io/commitizen/bump/#-files-only

Commitizen creates a commit because it can update files depending on the version type used, the changelog and files that need to be updated, and all of that end up in the version commit. I wonder how all of that would work if no commit is created.

No --files-only wouldn't work, I do need the tag, but I don't want the extra commit.

My particular use case is a CI workflow that runs on every commit to main. I want to create a tag and do the release but I don't want to push a new commit back to main (and thus retrigger CI. I want the tag to be on the commit that triggered the pipeline.

I know that bump can change files, but if no file changes are actually needed, there should be an option to not create the commit but still create a tag.

I guess for my use case another option would be to do a dry run and get the next version from the output, then create the tag myself, but is there a way to print just the new version of the dry run without anything else so I don't need to parse it? Maybe like a --quiet or --porcelain flag or something

I think you could achieve something like that using the version provider scm, but I'm seeing some bugs on it.

[tool.commitizen]
name = "cz_conventional_commits"
tag_format = "$version"
version_provider = "scm"

with changelog off the version in .cz.toml is not updated and it fails because there's nothing to commit: https://github.com/commitizen-tools/commitizen/blob/master/commitizen/commands/bump.py#LL319C25-L319C25

I'll label this as bug

@Lee-W

@Lee-W @noirbizarre do you have any thoughts on this? how should commitizen behave under this circumstance?

the circumstance:

commitizen reads the version from scm
changelog is not created and no files are modified
.cz.toml doesn't change (because the version is read from scm)

Under those circumstances, running cz bump fails.

I can only think of 2 possibilities at the moment:

Should we just create a tag? This is the one I'd like the most.
Or should we create an empty commit and tag together ? this is the less error prone, as otherwise we'd have to change some behavior here

I prefer option 1. Just to clarify, does using "bump" add a tag to the most recent commit in this scenario?

That is (my) the expected behavior. But it's not working atm. If you update the readme or version files, it's creating the bump commit and everything works fine. If you don't modify anything and you try to bump... it fails.

@abrahammurciano

I am currently in the process of deploying this kind of solution on enterprise projects, and it's working damn well. The solution I chose is the following (using pdm but should work with any project/package manager supporting scm versioning).

I have the following in my pyproject.toml:

[tool.pdm.version]
source = "scm"
write_to = "<package name>/_version.py"
write_template = '__version__ = "{}"'

[tool.commitizen]
version_provider = "scm"

and the content of <package name>/_version.py is:

from __future__ import annotations

try:
    import importlib.metadata as importlib_metadata

    __version__ = importlib_metadata.version("<distrib name>")
except (importlib_metadata.PackageNotFoundError, ImportError):
    __version__ = "0.0.0.dev"

Release is fully automated using a GitHub action workflow like this:

name: Release

on:
  workflow_dispatch:
    inputs:
      prerelease:
        type: choice
        description: Pre-release type (optional)
        options:
          - ''
          - alpha
          - beta
          - rc
        default: ''
        required: false
      increment:
        type: choice
        description: Kind of increment (optional)
        options:
          - ''
          - MAJOR
          - MINOR
          - PATCH
        default: ''
        required: false

jobs:
  release:
    name: Bump version and create changelog with commitizen
    runs-on: ubuntu-latest

    steps:
      - name: Clone
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
          token: ${{ secrets.RELEASE_TOKEN }}

      - name: Bump using commitizen
        uses: commitizen-tools/commitizen-action@master
        with:
          github_token: ${{ secrets.RELEASE_TOKEN }}
          changelog_increment_filename: body.md
          extra_requirements: <commitizen plugins>
          prerelease: ${{ github.event.inputs.prerelease }}
          increment: ${{ github.event.inputs.increment }}

      - name: Github Release
        uses: softprops/action-gh-release@v1
        with:
          body_path: "body.md"
          tag_name: ${{ env.REVISION }}
        env:
          GITHUB_TOKEN: ${{ secrets.RELEASE_TOKEN }}

This will trigger a cz bump with changelog and then a CI build for the pushed tag.

Adding a tag on the last commit is not enough to me because I will have at least a bump commit. The only exception that I know of is when you don't commit versioned files, including changelog.

However, I have one use-case that may require a --no-commit flag: release candidates: most of the time, the last rc release just become the X.Y.0. I still have to bump committed files, but I need commitizen to accept to produce a changelog without new commits/entries (which is currently failing, but it depends on the changelog rule, if the commits are ignored from changelog, it fails).
But for this case, I would love to be able to drop all RC's entries from changelog to replace with a single X.Y.0 entry.

For @abrahammurciano case (you seem to use commitizen only for version detection and tag bump, no file change), the --no-commit would be legit, but maybe something simpler would be enough, something like:

NEXT_VERSION=`cz next`
git tag $NEXT_VERSION
git push $NEXT_VERSION

Where cz next command is simply giving the next expected version according to the rule (the question here is whether it's simpler to have a --no-commit flag or simply a command giving the next version with the same parameters).
This will trigger a CI build for the tag only (but you need to clone and push using a PAT instead of the built-in GitHub provided token)

TLDR: --no-commit might be necessary, but I wonder if this shouldn't be the default (--no-commit being the default and having a flag to enforce new commit between bumps). Lack of new changelog entry while there are new commits in the tree should not prevent a bump (maybe with a fallback entry like "only internal changes" or something like that). For the tag only bump approach, it would solve the issue.

(Those are on the fly thinking, I might take some more time to study this case a bit more)

@abrahammurciano

I'm also looking for a --no-commit option, for similar reasons to @abrahammurciano. Saving versions into files creates merge conflicts, and in our continuously integrated gitflow process, it generates noise in our commit history. Many build tools support reading the version from the latest git tag on deployment, so writing to a file is increasingly optional.

I'm happy to implement this feature if we can agree on the behavior. Some thoughts:

@noirbizarre 's cz next suggestion would work for me. I may start with since it has fewer strings attached and other use cases. I would add an option to format the version using the tag_format configuration option. e.g. cz next --as-tag
for cz bump are there 3 commit scenarios: always, never, and when_dirty? The third case is essentially "commit if there are outstanding changes, but don't require a commit".

I did some testing with the scm provider, trying to use a gitflow branching structure with commitizen and the scm provider. There's a pretty serious bug with the SCM provider which makes it pretty useless as is, but I've made a PR to address that here: #975

For now I'm just parsing the version using --dry-run:

version=$(cz bump --dry-run | grep tag | sed 's/tag to create: \(.*\)/\1/')

With my PR and #799 to fix prereelase behavior I have a good POC.

Mark it as wait-for-implementation as it is mentioned in #1073

I ran into this problem today. We really want to work without an additional commit. Unfortunately, this is probably not possible with commitizen.

I would love to get this feature out. FWIW. I used these commands to create a new tag:

git tag "v$(cz bump --yes --get-next)"
git push --tags

Triage from #1964: Confirmed still valid on master (4.15.1). No --no-commit flag exists in BumpArgs. Suggesting we relabel as type: feature. Implementation outline: skip git.commit() (and the corresponding error handling in commitizen/commands/bump.py lines 385-394) and tag whatever the user has staged manually.

I ran into this problem as well - I had assumed that because the scm provider is advertised as read-only, it wouldn't require any git changes either.

Navigation Menu

Repository navigation

Flag to avoid creating a new commit for the bump #753

Description

Possible Solution

Additional context

Additional context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Flag to avoid creating a new commit for the bump #753

Description

Description

Possible Solution

Additional context

Additional context

Activity

woile commented on May 29, 2023

abrahammurciano commented on May 29, 2023

woile commented on May 31, 2023

woile commented on Jun 3, 2023

Lee-W commented on Jun 4, 2023

woile commented on Jun 4, 2023

noirbizarre commented on Jun 6, 2023

chadrik commented on Jan 28, 2024

chadrik commented on Jan 30, 2024

Lee-W commented on May 20, 2024

mrclrchtr commented on Apr 17, 2025

mlataza commented on Nov 13, 2025

bearomorphism commented on May 9, 2026

theinditector commented on Jun 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions