GIT-BUMP(1) | GIT-BUMP(1) |
git-bump - create Git release commits and tags with changelogs
git bump [major | minor | point | VERSION]
git bump log
git bump next
git bump redo
git bump show [VERSION]
git bump help [COMMAND]
git bump automates the best practices for doing releases for code bases stored in Git:
git bump [--force|-f] [major | minor | point | VERSION]
Use --force to re-tag the release.
If there are no changes staged, changes from the previous release commit will be replayed, replacing the appropriate version numbers.
The commit message body will be pre-populated with a bulleted list of commit messages since the previous release.
See "USAGE" for more details.
git bump log [...]
git bump next
git bump redo
git bump show [--version-only] [VERSION]
git bump help [COMMAND]
Stage the changes needed to create the release (this could be the entire repository if it's an initial commit), and run git bump <version>, where <version> is the version you want to release (try 1.0.0). You'll be greeted with a familiar sight:
spline-reticulator 1.0.0 # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit.
Adjust the project name if necessary, and save and quit the editor. Your commit and tag will be created, and you'll be shown instructions for pushing once you're sure everything is okay.
This is where the fun begins. Stage the changes necessary for release, and run git bump.
The commit message body will be pre-populated with a bulleted list of commit messages since the previous release. A good practice is to heavily edit this into a higher level list of changes by discarding worthless messages like typo fixes and making related commits into a single bullet point. If you aren't interested in this practice, delete the body and git bump won't bother you with it again.
On subsequent releases, if no changes are staged, git bump will replay the previous release commit, replacing the appropriate version numbers. This works fine as long as your version numbers are committed as literal strings. If you're doing something more clever like "MAJOR = 1" and "MINOR = 2", you'll have to do the edit by hand and stage it.
You'll need to create one existing release commit and tag in the proper format by hand, if your project doesn't already have one. After that you can use git bump normally.
Copyright (C) 2014, 2015 Tim Pope <code@tpope.net>
License: MIT/Expat
This manual page is based on the README document by Tim Pope. It was reformatted and adapted by Andrej Shadura <andrewsh@debian.org> for the Debian project, and is distributed under the same license as the original project.
2022-01-03 |