查看所有的標簽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