Menu
List Local Git Tags. In order to list Git tags, you have to use the “git tag” command with no arguments. You can also execute “git tag” with the “-n” option in order to have an extensive description of your tag list. Optionally, you can choose to specify a tag pattern with the “-l” option followed by the tag pattern.
Tags and branch are completely unrelated, since tags refer to a specific commit, and branch is a moving reference to the last commit of a history. Branches go, tags stay. So when you tag a commit, git doesn't care which commit or branch is checked out, if you provide him the SHA1 of what you want to tag.
Tags are ref's that point to specific points in Git history. Tagging is generally used to capture a point in history that is used for a marked version release (i.e. v1. 0.1). A tag is like a branch that doesn't change. Unlike branches, tags, after being created, have no further history of commits.
They are stored in the . git/refs/tags directory, and just like branches the file name is the name of the tag and the file contains a SHA of a commit 3. An annotated tag is an actual object that Git creates and that carries some information. For instance it has a message, tagger, and a tag date.
Version 1.0.0 of Semantic Versioning, by Tom Preston-Werner of GitHub fame, had a sub-specification addressing this:
Tagging Specification (SemVerTag)
This sub-specification SHOULD be used if you use a version control system (Git, Mercurial, SVN, etc) to store your code. Using this system allows automated tools to inspect your package and determine SemVer compliance and released versions.
- When tagging releases in a version control system, the tag for a version MUST be "vX.Y.Z" e.g. "v3.1.0".
However, after discussion this was removed, and is no longer present in the latest version of the SemVer spec (2.0.0 at the time of writing). A later discussion thread in the same place went into greater depth, and resulted in a new Is "v1.2.3" a semantic version? being added to the FAQ in SemVer's master branch, although at the time of writing (over 2 years later) this change is still not present in the officially released spec.
There appear to be two dominating conventions (assuming you also abide by some reasonable standard for numbering the releases themselves):
v1.2.31.2.3The advantages of v1.2.3 are that the Git documentation (and also the Mercurial documentation) uses that format in its examples, and that several "authorities" such as the Linux kernel and Git itself use it. (The mentioned Semantic Versioning used to use it but doesn't any more.)
The advantages of 1.2.3 are that gitweb or GitHub can automatically offer a tarball or zip download of the form packagename-$tag.tar.gz (and I think it's quite established that a tarball should not be named package-v1.2.3.tar.gz). Alternatively, you can use git describe directly to generate tarball version numbers. For lightweight projects without a formal release process, these possibilities can be quite convenient. It should also be noted that Semantic Versioning is by no means the only or a universally accepted standard for version numbering. And notable projects such as GNOME as well as countless other projects do use the 1.2.3 tag naming.
I think it's probably too late to consolidate these positions. As always, be consistent and make sense.
Update: As mentioned in this comment, GitHub now offers a tarball name with the 'v' stripped off of the tag.
The reason for the preceding 'v' is historical. Older SCCS (cvs,rcs) could not distinguish between a tag identifier and a revision number. Tag identifiers were restricted to not begin with a numeric value so that revision numbers could be detected.
Not that I know of.
But Git will not allow a tag and a branch of the same name at the same time, so if you have a branch "1.1" for 1.1 works, do not put a tag "1.1", use for instance "v1.1"
New package managers advice to tag versions without prefix v (like composer for PHP projects).
SemVer 2.0 has nothing about tag specification. It's done intentionally due avoiding conflicts. However it's advised to add prefix v in documentation and text references. As example format v1.0.4 instead of full version 1.0.4 or ver. 1.0.4 is enough verbose and elegant in documentation.
We use branches and tags for release-specific work followed by the actual release, respectively:
o---o-----o---o---o--- ... master
\ / /
\ / /
o-------o--- ... 1.6 branch
Every developer makes a mental decision about whether the work they're about to commit is applicable just to master or if it's also relevant to the branch. You can see that changes that are made to the branch are merged back on master, but some changes on master will never go on the branch (that is, those not intended for the 1.6 release, in this example).
When we're ready to release, we tag it and then merge back one last time, and we name the tag with the same name as the branch, but with an extra identifier about what particular version it is, e.g. "1.6-release" or "1.6-beta" or "1.6-rc2", et cetera.
... ------o---o---o--o---o--- ... master
/ /
/ /
... ---o------(*)--- ... 1.6 branch
1.6-release
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With