-
Notifications
You must be signed in to change notification settings - Fork 36
Devbest tagging
Just an FYI for all of you developer types. When you tag something in Git (i.e. git tag), you should always use a syntax which creates real tag objects and not just lightweight labels. Tag objects are much richer in the type of data they store and enable a wide range of useful Git features like, for example, git describe which basically gives me revision numbering like in Subversion except way smarter and more useful than a silly one-trick incrementing integer:
[openmelody(master)] $ git describe
v1.0.0_beta1-127-gf9fc573
127 commits on the master branch since v1.0.0_beta1. Hot damn!
Learn.GitHub says the following about the different types of Git tags:
There are a two main types of tags in Git - lightweight and annotated. Lightweight tags are very much like branches that don’t change - it’s just a pointer to a specific commit. Annotated tags, however, are stored as full objects in the Git database. They are checksummed, contain the tagger name, email and date, have a tagging message and can be GPG signed and verified. It’s generally recommended to create annotated tags so you can have all this information, but if you want a temporary tag or for some reason don’t want to keep that other information, lightweight tags are available too.
Tag objects are created by using any of the following git tag flags:
-a
Make an unsigned, annotated tag object
-s
Make a GPG-signed tag, using the default e-mail address's key
-u <key-id>
Make a GPG-signed tag, using the given key
-m <msg>
Use the given tag message (instead of prompting). If multiple -m
options are given, their values are concatenated as separate
paragraphs. Implies -a if none of -a, -s, or -u <key-id> is given.
-F <file>
Take the tag message from the given file. Use - to read the
message from the standard input. Implies -a if none of -a, -s, or
-u <key-id>is given.
The minimal level of effort for the desired effect uses the -a or -m flags:
git tag -a v1.0.0
git tag -m"Tagging MyPlugin version 1.1,1" v1.1.1
# This one is redundant
git tag -a v2.1.3 -m"Tagging MyPlugin version 2.1.3"
What you do NOT want to do is this:
git tag v1.9.2
Here's one last tip: If you forget to tag a release or version bump, you can always tag it retroactively like so:
git checkout SHA1_OF_PAST_COMMIT
git tag -m"Retroactively tagging version 1.5" v1.5
And while that's perfectly usable, it has the effect of putting your tags out of chronological order which can screw with build systems that look for the "latest" tag. But have no fear. Linus thought of everything:
# This moves you to the point in history where the commit exists
git checkout SHA1_OF_PAST_COMMIT
# This command gives you the datetime of the commit you're standing on
git show --format=%aD | head -1
# And this temporarily sets git tag's clock back to the date you copy/pasted in from above
GIT_COMMITTER_DATE="Thu Nov 11 12:21:57 2010 -0800" git tag -a 0.9.33 -m"Retroactively tagging version 0.9.33"
# Combining the two...
GIT_COMMITTER_DATE="$(git show --format=%aD | head -1)" git tag -a 0.9.33 -m"Retroactively tagging version 0.9.33"