Table of contents:
AutoTag can be used whenever you want to create a new tag in your git
project.
Specify a level as major, minor or bug level as per the semvar sequence standard and AutoTag will increment the tag appropriately in your repo.
AutoTag streamlines your process as you no longer have to tasks that are error-prone or easy to forget.
Notes:
This project is based on the Semantic Versioning standard, which you can read about on semver.org.
Here is the format:
vMAJOR.MINOR.BUG
A “bug” and “patch” release are the same thing.
If you are on version v0.1.2
and want to increment the minor version, run:
$ autotag m
Then the tool will increment the minor value by one and set the bug version to zero.
So your new tag will be v0.2.0
.
Note this project is only intended for tag versions with a v
prefix.
Note this was written for Unix-like systems (Linux and macOS).
So you just need Bash shell installed.
The application is a single script. There are no external dependencies.
Inspiration for this project comes from the following:
dtiemann83
.Comparing AutoTag and the
npm version
command
If you’re already using Node.js and NPM and you have a package.json
file in your project, you should not use AutoTag. AutoTag will actually give you an error if it can find a package.json
file.
Rather use NPM CLI’s built-in npm version command - see Reasons to use npm version for why.
For example, to increment a minor version with NPM CLI:
$ npm version minor
Which is similar to running:
$ autotag m
I like to configure aliases to make using npm version
easier.
alias nv='npm version minor'
alias nv-M='npm version major'
alias nv-b='npm version patch'
preversion
, version
and postversion
commands in your package.json
file.version
field in your package.json
. This change requires a commit, which npm version
does for you, using 0.2.0
for example as the commit message as v0.2.0
as the tag.AutoTag is great for repos in any programming language, especially those which don’t use NPM.
AutoTag makes sure to fetch remote tags first, which npm version
does not. Which means npm version
might end up creating a tag locally which already exists on the remote - created as a tag on GitHub directly. Unless one also remembers to edit package.json
on GitHub before making the tag.
However, this risk can be avoided for NPM projects if you make sure to use a "version"
field in your package.json
file and avoid tagging in GitHub directly. This approach will work as if you have the latest master
branch, as the value of the "version"
field will reflect the latest tag on the remote master, even if you don’t have the tag locally.