GIT-BUMP(1)

📦 version 1.1.0, in debian bookworm, debian trixie, ubuntu jammy, ubuntu noble, ubuntu resolute, ubuntu stonking

💖 GIT-BUMP(1) 💖

okay bestie, pull up a chair, because we're talking about git-bump — the little script that does your releases for you so you don't have to ✨

🌸 NAME 🌸

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

✨ SYNOPSIS ✨

git bump [major | minor | point | VERSION]

git bump log

git bump next

git bump redo

git bump show [VERSION]

git bump help [COMMAND]

💅 DESCRIPTION 💅

okay so git bump is literally just the best-practices release workflow for your Git repo, automated. no cap. it handles all of this for you:

  • it updates all the version-related minutiae scattered around your code base 🔍
  • it commits with a message like projectname 1.2.3
  • it creates a signed, annotated tag with that same message, named like v1.2.3 👑
  • and it tucks your release notes right into the release commit 🎀

like... it's giving "release manager who actually has their life together". obsessed.

🔥 COMMANDS 🔥

  • git bump [--force|-f] [major | minor | point | VERSION] — bump the version according to whatever you pass it:
    • major: bumps the first number in the previous version, and resets everything after it to zero
    • minor: bumps the second number in the previous version, and resets everything after it to zero
    • point: bumps the third number in the previous version, and resets everything after it to zero
    • VERSION: bumps straight to the exact version VERSION
    • no argument: bumps the rightmost number in the previous version. so 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's nothing staged, the changes from the previous release commit get replayed, with the appropriate version numbers swapped in. cute right?

the commit message body gets pre-populated with a bulleted list of commit messages since the previous release 📝

see USAGE for way more deets 👇

  • git bump log [...] — shows you the Git log since the last release. any arguments you pass get forwarded straight to git log 🫶
  • git bump next — shows you the version number that would be released, without actually doing any of the changes. a lil sneak peek, a vibe check, if you will 👀
  • git bump redo — amends the previous release and re-tags it. ⚠️ it can only be used when you're directly at the previous release commit. nowhere else, bestie.
  • git bump show [--version-only] [VERSION] — shows the most recent release, or the one you name. by default it prints the commit message. use --version-only if you just want the version number instead 💜
  • git bump help [COMMAND] — prints a short usage notice. the classic.

🌈 USAGE 🌈

🎀 Initial release

stage everything you need for the release (and honestly, if this is your very first commit, that could be the entire repository), then run git bump <version>, where <version> is the version you wanna release — try 1.0.0, it's a classic.

you'll be greeted with a very 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 you need to, then save and quit your editor. your commit and tag get created, and you'll be shown instructions for pushing once you're sure everything is okay 🫶

🦋 Second release

this is where the fun begins, fr fr. 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 — bin the worthless messages like typo fixes, and squish related commits into a single bullet point. and if that practice isn't your thing? just delete the body, and git bump won't bother you with it again 💅

🌸 Subsequent releases

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 yourself 😭

💀 Existing projects

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. periodt. 👑

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 🫶

okay that's the whole thing bestie!! this page is from 2022-01-03 and it's the GIT-BUMP(1) manual — go forth and release something iconic ✨💖🎀

📦 where this page comes from