git-bump - create Git release commits and tags with changelogs

gitbump [--force|-f] [major | minor | point | VERSION]

           Bump the version according to the argument:

           •   major: bump the first number in the previous version, and reset everything afterwards to zero

           •   minor: bump the second number in the previous version, and reset everything afterwards to zero

           •   point: bump the third number in the previous version, and reset everything afterwards to zero

           •   VERSION: bump to the exact version VERSION

           •   no  argument:  bump  the rightmost number in the previous version. For example, 1.2.3-rc4 becomes
               1.2.3-rc5, while 6.7 becomes 6.8

           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.

       gitbumplog [...]

           Show the Git log since the last release. Any arguments are passed to gitlog.

       gitbumpnext

           Show the version number that would be released without performing any actual changes.

       gitbumpredo

           Amend the previous release and re-tag. Can only be used directly at the previous release commit.

       gitbumpshow [--version-only] [VERSION]

           Show the most recent or given release. By default, prints the commit message.  Use --version-only  to
           print the version number instead.

       gitbumphelp [COMMAND]

           Print a short usage notice.

       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                                        GIT-BUMP(1)

gitbump automates the best practices for doing releases for code bases stored in Git:

       •   Update version-related minutiae in the code base.

       •   Commit with a message like projectname 1.2.3.

       •   Create a signed, annotated tag with the same message with a name like v1.2.3.

       •   Include release notes in the release commit.

       git-bump - create Git release commits and tags with changelogs

gitbump [major | minor | point | VERSION]

       gitbumploggitbumpnextgitbumpredogitbumpshow [VERSION]

       gitbumphelp [COMMAND]

Initialrelease
       Stage  the  changes  needed to create the release (this could be the entire repository if it's an initial
       commit), and run gitbump<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.

   Secondrelease
       This is where the fun begins. Stage the changes necessary for release, and run gitbump.

       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 gitbump won't bother you with it again.

   Subsequentreleases
       On subsequent releases, if no changes are staged, gitbump  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.

   Existingprojects
       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 gitbump normally.