查看所有的标签git tag
删除某一个标签git tag -d tagName
创建带注释的标签 git tag -a tagName -m "annotate"
轻量级标签 git tag tagName
切换到某一个标签 git checkout tagName
http://blog.csdn.net/feosun/article/details/8064648
Git 的标签管理。跟大多数的 VCS 工具一样，git 也有在历史状态的关键点“贴标签”的功能，一般人们用这个功能来标记发布点（例如’v1.0′）。
列出git中现有标签
要想列出git中现有的所有标签，输入’git tag’命令运行即可：
$ git tag
v0.1
v1.3
这个列表是按照字母表顺序给出的，其实排名先后跟重要程度没有直接联系。
当然，你也可以按照特定表达式搜索某些标签。假如在一个 git 仓库中有超过 240 个标签，而你只想得到 1.4.2 序列的标签，那么你可以：
$ git tag -l v1.4.2.*
v1.4.2.1
v1.4.2.2
v1.4.2.3
v1.4.2.4
创建标签
在 git 中有两种最主要的标签–轻量级标签（lightweight）和带注释的标签（annotated）。轻量级标签跟分枝一样，不会改变。它就是针对某个特定提交的指针。然而，带注释的标签是git仓库中的对象。它是一组校验和，包含标签名、email、日期，标签信息，GPG签名和验证。一般情况下，建议创建带注释的标签，这样就会保留这些信息，但是如果你只是需要临时性标签或者某些原因你不想在标签中附带上面说的这些信息，lightweight标签更合适些。
带注释的标签
在git中创建带注释的标签非常简单，在运行’tag’命令时加上-a就可以了。
$ git tag -a v1.4 -m ‘version 1.4′
$ git tag
v0.1
v1.3
v1.4
‘-m’指明标签信息，跟标签一起存储。如果你不使用-m指明标签信息，git会自动启动文本编辑器让你输入。
可以使用 git show 命令查看相应标签的版本信息，并连同显示打标签时的提交对象。
$ git show v1.4
tag v1.4
Tagger: Scott Chacon
Date: Mon Feb 9 14:45:11 2009 -0800
my version 1.4
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
Merge: 4a447f7… a6b4c97…
Author: Scott Chacon
Date: Sun Feb 8 19:02:46 2009 -0800
Merge branch ‘experiment’
我们可以看到，在提交对象信息上面，列出了此标签的提交者和提交时间，以及相应的标签信息。
有签名的标签。
轻量级标签
轻量级标签实际上就是存在一个文件中的提交校验和–没有附加任何其他信息。创建轻量级标签的方法就是把上面’-a’,'-s’,'-m’这些选项都去掉。
$ git tag v1.4-lw
$ git tag
v0.1
v1.3
v1.4
v1.4-lw
v1.5
如果现在对这个标签使用’git show’命令，不会看到像上面那种标签显示的那么多内容，仅仅显示这次提交的有关信息。
$ git show v1.4-lw
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
Merge: 4a447f7… a6b4c97…
Author: Scott Chacon
Date: Sun Feb 8 19:02:46 2009 -0800
Merge branch ‘experiment’
共享标签
默认情况下，’git push’命令不会将标签上传到远程服务器上。为了共享这些标签，你必须在’git push’命令后明确添加-tags选项
[master]$ git push –tags
Counting objects: 50, done.
Compressing objects: 100% (38/38), done.
Writing objects: 100% (44/44), 4.56 KiB, done.
Total 44 (delta 18), reused 8 (delta 1)
To git@github.com:schacon/simplegit.git
* [new tag] v0.1 -> v0.1
* [new tag] v1.2 -> v1.2
* [new tag] v1.4 -> v1.4
* [new tag] v1.4-lw -> v1.4-lw
* [new tag] v1.5 -> v1.5
现在，如果有人克隆或者在线同步你的git仓库的话，标签也会一并同步了。
实战：
$ git checkout v0.11.2
Note: checking out 'v0.11.2'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b new_branch_name
HEAD is now at adadaab... v0.11.2
$ git branch
* (detached from v0.11.2)
chucklu_master
chucklu_zhCN
master
test
2016年11月01日更新
Tag和Commit
https://github.com/chucklu/tools
从当前的commit往后查找
git tag --contains commit-id
$ git tag --contain d9df
1.0.0.0
1.0.0.1
1.0.0.2
1.0.0.3
1.0.0.4
从当前的commit往前查找
git describe --tags commit-id
$ git describe --tags 601f
1.0.0.0-2-g601fe8a
$ git describe --tags d493
1.0.0.0-3-gd493bdf
$ git describe --tags b627
1.0.0.0-1-gb627c33
$ git describe --tags 16ec
1.0.0.0
$ git describe --exact-match --tag 16ec
1.0.0.0
push a tag to remote
https://stackoverflow.com/questions/5195859/how-to-push-a-tag-to-a-remote-repository-using-git
To push a single tag:
git push origin <tag_name>
And the following command should push all tags (not recommended):
git push --tags
How to see remote tags?
git ls-remote --tags origin
show tag with commit date(not the created date of tag)
https://stackoverflow.com/questions/6900328/git-command-to-show-all-lightweight-tags-creation-dates
git log --tags --simplify-by-decoration --pretty="format:%ai %d"
git tag policy
https://stackoverflow.com/questions/9900889/git-tag-release-version
You can choose a policy similar to Git itself (see its tags in the GitHub repo):
v1.7.2-rc0
v1.7.2-rc1
v1.7.2-rc2
v1.7.2-rc3
v1.7.2
The idea (as described in Choosing a good version numbering policy) can go along the lines of:
The ‘
master’ branch will be the one containing the code marked to be production ready in a given moment, ‘master’ must be always compilable.
Code in the ‘master’ branch must have an even tag number.For the version number, it will be created using the git describe command, since it’s a sort of standard de facto.
See Canonical Version Numbers with Git:
git describe –tags –long
This gives you a string like (in the case of one of my projects)
2.1pre5-4-g675eae1
which is formatted as
{last reachable tag name}-{# of commits since that tag}-#{SHA of HEAD}
This gives you a ‘canonical version number’ (spelling corrected) that is monotonically increasing by commits, and unique across multiple repositories of development. If we’re all on the same HEAD, it will return the same value. If we all share the same most-recent-tag, but have different commits, the SHA will be different.
You can strive for having on master only version numbers like
{last reachable tag name}-0-#{SHA of HEAD}
(ie tagged commits only)
But the idea is that this kind of version number (tag + SHA) is completely unambiguous.
Delete all tags on remote or local
1. Delete All local tags. (Optional Recommended)
git tag -d $(git tag -l)
2. Fetch remote All tags. (Optional Recommended)
git fetch
3. Delete All remote tags.
git push origin --delete $(git tag -l) # Pushing once should be faster than multiple times