Git Basics - tagging
Label
Like other version control systems (VCS), Git can label a submission in the warehouse history as important. Typically, people will use this function to mark publishing nodes (v1.0, v2.0, etc.). In this section, you will learn how to list existing tags, how to create and delete new tags, and what different types of tags are.
List labels
Listing existing tags in Git is very simple. You only need to enter git tag (with optional - l option -- list):
$ git tag v1.0 v2.0
This command lists labels alphabetically, but the order in which they are displayed is not important.
You can also find tags according to specific patterns. For example, Git's own source code repository contains more than 500 tags. If you are only interested in the 1.8.5 series, you can run:
$ git tag -l "v1.8.5*" v1.8.5 v1.8.5-rc0 v1.8.5-rc1 v1.8.5-rc2 v1.8.5-rc3 v1.8.5.1 v1.8.5.2 v1.8.5.3 v1.8.5.4 v1.8.5.5
Note
The - l or -- list option is required to list labels according to wildcards
If you only want a complete list of tags, running git tag will assume that you want a list by default, and it will list it directly for you. At this time, - l or -- list is optional.
However, if you provide a wildcard pattern that matches the signature of the signature, then - l or -- list is mandatory.
create label
Git supports two types of tags: lightweight and annotated.
Lightweight label
Much like a branch that won't change -- it's just a reference to a particular commit.
Note tags are a complete object stored in the Git database. They can be verified, including the name, e-mail address, date and time of the tagger. In addition, there is a tag information, which can be signed and verified by GNU Privacy Guard (GPG). It is usually recommended to create a note tag so that you can have all the above information. But if you just want to use a temporary tag, or you don't want to save this information for some reason, you can also use a lightweight tag.
Note label
Creating annotation labels in Git is simple. The simplest way is to specify the - a option when you run the tag command:
$ git tag -a v1.4 -m "my version 1.4" $ git tag v0.1 v1.3 v1.4
-The m option specifies a piece of information that will be stored in the tag. If you do not specify a message for the note tag, Git will launch the editor and ask you to enter the message.
You can see the tag information and the corresponding submission information by using the git show command:
$ git show v1.4
tag v1.4
Tagger: Ben Straub <ben@straub.cc>
Date: Sat May 3 20:19:12 2014 -0700
my version 1.4
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date: Mon Mar 17 21:52:11 2008 -0700
changed the version number
The output displays the information of the tagger, the date and time of the tagging, the note information, and then the specific submission information.
Lightweight label
Another way to label submissions is to use lightweight labels. Lightweight tags essentially store the commit checksum in a file -- without saving any other information. To create a lightweight label, you do not need to use the - A, - s or - m options, but only need to provide the label name:
$ git tag v1.4-lw $ git tag v0.1 v1.3 v1.4 v1.4-lw v1.5
At this time, if you run git show on the tag, you will not see additional tag information. The command displays only the submission information:
$ git show v1.4-lw
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date: Mon Mar 17 21:52:11 2008 -0700
changed the version number
Post labeling
You can also label past submissions. Suppose the submission history is as follows:
$ git log --pretty=oneline 15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment' a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support 0d52aaab4479697da7686c15f77a3d64d9165190 one more thing 6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment' 0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function 4682c3261057305bdd616e23b64b0857d832627b added a todo file 166ae0c4d3f420721acbb115cc33848dfcc2121a started write support 9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile 964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo 8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme
Now, suppose in V1 At 2:00, you forgot to label the project, that is, submit it in "updated rake file". You can fill in the label later. To label that submission, you need to specify the submitted checksum (or partial checksum) at the end of the command:
$ git tag -a v1.2 9fceb02
You can see that you have labeled that submission:
$ git tag
v0.1
v1.2
v1.3
v1.4
v1.4-lw
v1.5
$ git show v1.2
tag v1.2
Tagger: Scott Chacon <schacon@gee-mail.com>
Date: Mon Feb 9 15:32:16 2009 -0800
version 1.2
commit 9fceb02d0ae598e95dc970b74767f19372d61af8
Author: Magnus Chacon <mchacon@gee-mail.com>
Date: Sun Apr 27 20:43:35 2008 -0700
updated rakefile
...
Shared Tags
By default, the GIT push command does not transfer labels to the remote warehouse server. After creating the tag, you must explicitly push the tag to the shared server. This process is like sharing a remote branch -- you can run git push origin < tagName >.
$ git push origin v1.5 Counting objects: 14, done. Delta compression using up to 8 threads. Compressing objects: 100% (12/12), done. Writing objects: 100% (14/14), 2.05 KiB | 0 bytes/s, done. Total 14 (delta 3), reused 0 (delta 0) To git@github.com:schacon/simplegit.git * [new tag] v1.5 -> v1.5
If you want to push many tags at once, you can also use the git push command with the -- tags option. This will transfer all tags that are not on the remote warehouse server there.
$ git push origin --tags Counting objects: 1, done. Writing objects: 100% (1/1), 160 bytes | 0 bytes/s, done. Total 1 (delta 0), reused 0 (delta 0) To git@github.com:schacon/simplegit.git * [new tag] v1.4 -> v1.4 * [new tag] v1.4-lw -> v1.4-lw
Now, when others clone or pull from the warehouse, they can also get your tags.
Note
git push pushes two kinds of tags
Using git push < remote > -- tags to push tags does not distinguish between lightweight tags and annotation tags. There is no simple option to push only one tag.
delete a tap
To remove the tag from your local warehouse, use the command git tag - d < tagName >. For example, you can delete a lightweight label using the following command:
$ git tag -d v1.4-lw Deleted tag 'v1.4-lw' (was e7d5add)
Note that the above command will not remove this tag from any remote warehouse. You must update your remote warehouse with git push < remote >: refs / tags / < tagName >
First kind
The variant is git push < remote >: refs / tags / < tagName >
$ git push origin :refs/tags/v1.4-lw To /git@github.com:schacon/simplegit.git - [deleted] v1.4-lw
The meaning of the above operation is to push the null value before the colon to the remote tag name, so as to delete it efficiently.
Second
A more intuitive way to delete remote tags is:
$ git push origin --delete <tagname>
Check out label
If you want to check the file version pointed to by a tag, you can use the git checkout command, although this will make your warehouse in the "detached HEAD" state - this state has some bad side effects:
$ git checkout 2.0.0 Note: checking out '2.0.0'. 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> HEAD is now at 99ada87... Merge pull request #89 from schacon/appendix-final $ git checkout 2.0-beta-0.1 Previous HEAD position was 99ada87... Merge pull request #89 from schacon/appendix-final HEAD is now at df3f601... add atlas.json and cover image
In the "split header pointer" state, if you make some changes and submit them, the label will not change, but your new submission will not belong to any branch and will not be accessible unless it is accessed through the exact submission hash. Therefore, if you need to make changes, such as fixing errors in the old version, you usually need to create a new branch:
$ git checkout -b version2 v2.0.0 Switched to a new branch 'version2'
If another commit is made after that, the version 2 branch will move forward because of this change, and it will be the same as v2 The 0.0 tag is slightly different, so be careful.