The tags have been created with commands like:
git tag v1.0.0 -m 'finally a stable release'
git tag v2.0.0 -m 'oops, there was still a major bug!'
should be enough. See
git tag man page
You also have:
git tag -l <pattern>
List tags with names that match the given pattern (or all if no pattern is given).
Typing "git tag" without arguments, also lists all tags.
More recently ("How to sort git tags?", for Git 2.0+)
git tag --sort=<type>
Sort in a specific order.
Supported type is:
refname" (lexicographic order),
version:refname" or "
v:refname" (tag names are treated as versions).
Prepend "-" to reverse sort order.
That lists both:
Note: the git ready article on tagging disapproves of lightweight tag.
Without arguments, git tag creates a “lightweight” tag that is basically a branch that never moves.
Lightweight tags are still useful though, perhaps for marking a known good (or bad) version, or a bunch of commits you may need to use in the future.
Nevertheless, you probably don’t want to push these kinds of tags.
Normally, you want to at least pass the -a option to create an unsigned tag, or sign the tag with your GPG key via the -s or -u options.
That being said, Charles Bailey points out that a '
git tag -m "..."' actually implies a proper (unsigned annotated) tag (option '
-a'), and not a lightweight one. So you are good with your initial command.
This differs from:
git show-ref --tags -d
Which lists tags with their commits (see "Git Tag list, display commit sha1 hashes").
-d in order to dereference the annotated tag object (which have their own commit SHA1) and display the actual tagged commit.