commitdog release handles the entire release workflow for you. It detects your project’s language, reads the current version, lets you pick a semver bump, shows you a changelog preview, and then executes every step — version bump, binary builds, commit, tag, push, and release creation — in sequence. If any step fails, commitdog rolls back every completed step in reverse so your repository is always left in a clean state.
Supported version files
When you runcommitdog release, it scans your repository root for a version file in this order:
If no version file is found, commitdog offers to create one for you before proceeding.
Full release workflow
1
Run the release command
From the root of your repository, run:commitdog verifies you are inside a Git repository and that a platform token is configured. If you have not run
commitdog setup yet, it will exit with a prompt to do so.2
Detect or initialize a version file
commitdog scans for a supported version file. If it finds one, it reads the current version and continues. If none is found, you are offered four options:Options 1–3 create a file starting at
0.1.0. Option 4 accepts a one-time semver string without writing any file.3
Check for version drift
If a latest Git tag exists and it does not match the version in your file, commitdog warns you before touching anything:Fix the mismatch or confirm to continue.
4
Pick a version bump
commitdog displays your current version and the three standard bump options:Choose
4 to enter any valid semver string manually.5
Review the changelog preview
Before any changes are made, commitdog shows a grouped changelog of all commits since the last tag:Confirm with
y to proceed, or n to abort without making any changes.6
Execute the release steps
Once confirmed, commitdog runs every step and prints live status:Binary builds and asset uploads only happen for Go projects. For all other languages, commitdog skips directly from the version bump to the commit step.
Atomic rollback — every completed step registers an undo function before the next step runs. If anything fails — a network cut, an API error, a build failure — commitdog rolls back every completed step in reverse order. Your repository is always left clean. After a rollback, fix the underlying issue and run
commitdog release again.Platform-specific behavior
The release command works across GitHub, GitLab, Gitea, and Forgejo. The core workflow is identical on all platforms; only the asset upload mechanism differs.- GitHub
- GitLab
- Gitea
- Forgejo
commitdog creates a GitHub Release via the REST API, then uploads each binary and
checksums.txt individually using the release upload URL..commitdog config file (set by commitdog setup). If no platform is configured, commitdog defaults to GitHub.
Release to mirrors
If your repo has mirror platforms configured, you can publish the same release everywhere instead of only on your primary platform.Release to primary and all mirrors
--all runs the full release workflow on your primary platform first. Then, for each mirror listed in .commitdog, commitdog pushes the tags to that mirror’s remote and creates a release there with the same version, changelog, and build artifacts. Each mirror’s release URL is printed as it completes.
If a mirror fails partway, only that mirror’s steps are rolled back. The primary release and any mirrors that already succeeded stay published.
Publish an existing release to one platform
commitdog release, or to retry a single mirror that failed during --all.
The platform’s remote must already exist. If it does not, commitdog exits with a prompt to add the platform as a mirror via commitdog init. A token for the platform is also required; run commitdog setup if you have not saved one.