Git foundation - labeling

tagging

Like other version control systems （VCS） equally ,Git You can tag a submission in the warehouse history , To show importance . What's more representative is that people will use this function to mark publishing nodes （ v1.0 、 v2.0  wait ）. In this section , You will learn how to list existing tags 、 How to create and delete new tags 、 And what are the different types of labels .

List labels

stay Git Listing the existing tags in is very simple , Just input  git tag （ Take the optional  -l  Options  --list）：

$ git tag
v1.0
v2.0
 Copy code 

This command lists tags in alphabetical order , But the order in which they appear is not important .

Create a label

Git Two kinds of tags are supported ： Lightweight label （lightweight） Label with notes （annotated）.

The lightweight label is much like a branch that doesn't change —— It's just a reference to a particular submission .

And the note label is stored in Git A complete object in the database , They can be verified , It contains the name of the tagger 、 E-mail address 、 Date time , There's also a tag message , And you can use GNU Privacy Guard （GPG） Sign and verify . It's usually recommended to create a note label , So you can have all of the above information . But if you just want to use a temporary label , Or for some reason you don't want to save this information , Then you can also use lightweight labels .

Note label

stay Git Creating a note label in is very simple . The easiest way is when you're running  tag  Specify... When ordering  -a  Options ：

$ git tag -a v1.4 -m "my version 1.4"
$ git tag
v0.1
v1.3
v1.4
 Copy code 

-m  Option specifies a piece of information that will be stored in the tag . If you do not specify a message for the note label ,Git It will launch the editor and ask you to input information .

By using  git show  The command can see the tag information and the corresponding submission information ：

$ git show v1.4
tag v1.4
Tagger: Ben Straub <[email protected]>
Date:   Sat May 3 20:19:12 2014 -0700

my version 1.4

commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <[email protected]>
Date:   Mon Mar 17 21:52:11 2008 -0700

    changed the version number
 Copy code 

The output shows the tagger's information 、 Date and time of labeling 、 Note information , Then display the specific submission information .

Lightweight label

Another way to tag submissions is to use lightweight tags . Lightweight tags essentially store the submitted checksums in a file —— No other information was saved . Create a lightweight label , No need to use  -a、-s  or  -m  Options , Just provide the tag name ：

$ git tag v1.4-lw
$ git tag
v0.1
v1.3
v1.4
v1.4-lw
v1.5
 Copy code 

At this time , If you run on a label  git show, You don't see any additional tag information . The command only shows the submission information ：

$ git show v1.4-lw
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <[email protected]>
Date:   Mon Mar 17 21:52:11 2008 -0700

    changed the version number
 Copy code 

Label later

You can also tag past submissions . Suppose the submission history is like this ：

$ 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
 Copy code 

Now? , Suppose that v1.2 When you forget to label the project , That is to say “updated rakefile” Submit . You can tag it later . Label that submission , You need to specify the committed checksum... At the end of the command （ Or partial checksums ）：

$ git tag -a v1.2 9fceb02
 Copy code 

You can see that you have tagged 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 <[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
...
 Copy code 

Share tags

By default ,git push  The command does not send the tag to the remote warehouse server . After creating the tag, you have to 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 [email protected]:schacon/simplegit.git
 * [new tag]         v1.5 -> v1.5
 Copy code 

If you want to push a lot of tags at once , It can also be used with  --tags  Option  git push  command . This will send 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 [email protected]:schacon/simplegit.git
 * [new tag]         v1.4 -> v1.4
 * [new tag]         v1.4-lw -> v1.4-lw
 Copy code 

Now? , When someone else clones or pulls , They can also get your tags .

Note	git push  Push two kinds of labels  git push <remote> --tags  Push tags don't differentiate between lightweight tags and note tags , There is no simple option for you to choose to push only one tag .

Remove the label

To remove the label from your local warehouse , You can use commands  git tag -d <tagname>. for example , You can use the following command to delete a lightweight label ：

$ git tag -d v1.4-lw
Deleted tag 'v1.4-lw' (was e7d5add)
 Copy code 

Note that the above command does not remove this tag from any remote repository , You have to use  git push <remote> :refs/tags/<tagname>  To update your remote warehouse ：

The first variant is  git push <remote> :refs/tags/<tagname> ：

$ git push origin :refs/tags/v1.4-lw
To /[email protected]:schacon/simplegit.git
 - [deleted]         v1.4-lw
 Copy code 

The meaning of the above operation is , Push the null value before the colon to the remote tag name , So that it can be deleted efficiently .

The second more intuitive way to delete a remote tag is ：

$ git push origin --delete <tagname>
 Copy code 

Check out the label

If you want to see the version of the file that a label points to , have access to  git checkout  command , Although this will keep your warehouse in “ Detachable head pointer （detached HEAD）” The state of —— There are some bad side effects in this state ：

$ 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
 Copy code 

stay “ Detachable head pointer ” State, , If you make some changes and then commit them , The label will not change , But your new submission will not belong to any branch , And will not be able to access , Only through the exact commit hash can access . therefore , If you need to make changes , For example, you need to fix the mistakes in the old version , Then you usually need to create a new branch ：

$ git checkout -b version2 v2.0.0
Switched to a new branch 'version2'
 Copy code 

If there is another submission after this ,version2  The branch will move forward because of this change , At this point it will be with  v2.0.0  The label is a little different , Then be careful .