Tagging
Like most VCS, Git can also be marked on the label to release some point in time. When people release a version of the software (such as v1.0, etc.) often do so. In this section we learn together how to list all of the available tags, how to create a difference between the labels, as well as a variety of different types of labels.
Prints existing label
The command lists the existing labels is very simple, run directly git tag to:
$ git tag
v0.1
v1.3
Label displayed in alphabetical order, so that the label does not have to represent the importance of severity.
We can list qualified label with a specific search mode. Git repository project in itself, with more than 240 labels, if you are only interested in the 1.4.2 version of the series, you can run the following command:
$ git tag -l 'v1.4.2.*'
v1.4.2.1
v1.4.2.2
v1.4.2.3
v1.4.2.4
New Label
Git tags used are of two types: lightweight (Lightweight) containing annotated (annotated). Lightweight label like a branch will not change, in fact it is a reference point to submit specific object. The label containing notes, in fact, is an independent objects stored in the warehouse, it has its own checksum information, the label contains the name, email address, and date and label instructions, the tag itself also allows the use of GNU Privacy Guard (GPG) to sign or verify. Generally, we recommend using a type of label containing notes, in order to preserve relevant information; of course, if only temporary filling label, or no marginal notes additional information, lightweight tags with no problem.
Notes with labels
Create a note type of label contains very simple to use -a (translation: Take annotated the first letter) to specify the label name:
$ git tag -a v1.4 -m 'my version 1.4'
$ git tag
v0.1
v1.3
v1.4
The -m option specifies the corresponding label instructions, Git will be saved together in this description label object. If this option is not given, Git launches a text editor for you to enter the label instructions.
You can use git show the command to view the version information of the corresponding label, and submit along with the display of objects when playing tag.
$ git show v1.4
tag v1.4
Tagger: Scott Chacon <[email protected]>
Date: Mon Feb 9 14:45:11 2009 -0800
my version 1.4
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
Merge: 4a447f7... a6b4c97...
Author: Scott Chacon <[email protected]>
Date: Sun Feb 8 19:02:46 2009 -0800
Merge branch 'experiment'
We can see the object in submitting the above information, the label lists the submitter and submission time, and the corresponding label.
Signed label
If you have your own private key, you can also use GPG to sign the label, just put before the -a change -s (translation: Take signed the first letter) to:
$ git tag -s v1.5 -m 'my signed 1.5 tag'
You need a passphrase to unlock the secret key for
user: "Scott Chacon <[email protected]>"
1024-bit DSA key, ID F721C45A, created 2009-02-09
Now run git show will also see a corresponding GPG signature attached to it within:
$ git show v1.5
tag v1.5
Tagger: Scott Chacon <[email protected]>
Date: Mon Feb 9 15:22:20 2009 -0800
my signed 1.5 tag
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEABECAAYFAkmQurIACgkQON3DxfchxFr5cACeIMN+ZxLKggJQf0QYiQBwgySN
Ki0An2JeAVUCAiJ7Ox6ZEtK+NvZAj82/
=WryJ
-----END PGP SIGNATURE-----
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
Merge: 4a447f7... a6b4c97...
Author: Scott Chacon <[email protected]>
Date: Sun Feb 8 19:02:46 2009 -0800
Merge branch 'experiment'
Later we'll learn how to verify signed tags.
Lightweight Label
Lightweight tag is actually a preserved file checksum information submitted corresponding object. To create such a label, a -a, -sor -m options do not directly given label name to:
$ git tag v1.4-lw
$ git tag
v0.1
v1.3
v1.4
v1.4-lw
v1.5
Now run git show to see this tag information, only the corresponding objects Abstract submission:
$ git show v1.4-lw
commit 15027957951b64cf874c3557a0f3547bd83b3ff6
Merge: 4a447f7... a6b4c97...
Author: Scott Chacon <[email protected]>
Date: Sun Feb 8 19:02:46 2009 -0800
Merge branch 'experiment'
Verify tag
You can use git tag -v [tag-name] (translation: Take verify the first letter) way to verify the label signed. This command will call GPG to verify the signature, so you need a signer's public key, stored in the keyring in order to verify:
$ git tag -v v1.4.2.1
object 883653babd8ee7ea23e6a5c392bb739348b1eb61
type commit
tag v1.4.2.1
tagger Junio C Hamano <[email protected]> 1158138501 -0700
GIT 1.4.2.1
Minor fixes since 1.4.2, including git-mv and git-http with alternates.
gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A
gpg: Good signature from "Junio C Hamano <[email protected]>"
gpg: aka "[jpeg image of size 1513]"
Primary key fingerprint: 3565 2A26 2040 E066 C9A7 4A7D C0C6 D9A4 F311 9B9A
If there is no signer's public key, it will report an error like this below:
gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A
gpg: Can't check signature: public key not found
error: could not verify the tag 'v1.4.2.1'
The late filling tag
You can even label in the late filling of a commit earlier. For example, in the following submission show history:
$ 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
We forget that after submitting marked "updated rakefile" this project version v1.2, it does not matter, but now they do. Just keep checking the corresponding object and submit (or the first few characters) playing tag when you can:
$ git tag -a v1.2 9fceb02
We can see that we have up on the label:
$ 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 <[email protected]>
Date: Mon Feb 9 15:32:16 2009 -0800
version 1.2
commit 9fceb02d0ae598e95dc970b74767f19372d61af8
Author: Magnus Chacon <[email protected]>
Date: Sun Apr 27 20:43:35 2008 -0700
updated rakefile
...
Share Tags
By default, git push no label will transfer to the remote server, only by an explicit command to share the label to a remote warehouse. The format is like pushing a branch, run git push origin [tagname] to:
$ git push origin v1.5
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 [email protected]:schacon/simplegit.git
* [new tag] v1.5 -> v1.5
If you want to push all the new local label up, you can use --tags the options:
$ git push origin --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 [email protected]: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
Now, after others shared repository clone or pull data synchronization, you will see these labels.