Detailed Git application Lecture 8: Git tags, aliases and Git gc

Foreword

Foreword summary: Git application in detail Chapter 7: Important operations of Git refspec and remote branch

This section mainly introduces Gittags, aliases and Gitgarbage collection mechanisms.

1. GitLabel ( tag)

1. The essence of the label

Tags are very similar to branches, and they all point to a certain commit; and their values ​​are the values ​​that point to the commit SHA1; however, unlike branches that change with the commit, once a tag is added to a commit The label will never change.

Note: The label identifies a certain commit. This commit can be any commit on any branch.

Two types of labels

GitThere are two types of labels:

• Lightweight label ( lightweight): No comments can be added;
• Label with notes ( annotated): You can add notes;

Annotated tags are meant for release while lightweight tags are meant for private or temporary object labels.

The above is gitthe description of the two tags in the official document. The general idea is: the annotated tags are used for publishing, while the lightweight tags are used for private or temporary objects.

When is the label applied?

• Version release: The general masterbranch will be used as the release branch of the project. When the project has reached a mature stage and is ready to masterbe released on the branch. Generally, a label mastersimilar to " v1.2" is added to the current commit of the branch ;

  For example Vueframework:

  

  You can see there are many tags, and you can releasesview the tags and release versions in the options:

  

• Version management: You can record the status of a certain stage of the project in the form of a label for easy management;

  For example, the code of each knowledge point when managing the WeChat applet:

  

View label file

As shown in the figure below, add a lightweight label and a label with notes to masterthe commit of the branch :mas2v1.0v2.0

git dogAs git log --all --decorate --oneline --graphan alias, will explain later;

Then, check the .git/refs/tagsdirectory where the label file is stored :

can be seen:

• tagsThe added label files v1.0and files are stored under the directory v2.0;
• Open the tag file v1.0and respectively v2.0, and their values ​​are all the same SHA1, and they are equal to mas2the SHA1values submitted when the tag was added 6920a6e....
• emm...and many more! Not equal it, only v1.0the value of the submission mas2of SHA1equal value, and v2.0the value is not equal!
• Why do mas2the tags added to the same submission have different SHA1values? This is because the v1.0lightweight label, and v2.0is annotated labels.

Although both tags mark the same commit, they are constructed differently:

• The lightweight tag v1.0directly uses the SHA1value submitted this time as its own SHA1value;

• The annotated tag v2.0will create an tagobject whose SHA1value is the value of the tagobject SHA1;

This is the difference between lightweight tags and tags with notes. However, these two tags will still point to the same commit, as shown in the following figure:

2. Create a label

git tag <tag_name>

Create a lightweight label:

git tag -a <tag_name> -m '注释'

Create a label with notes:

3. View tags

git tag

Show all added tags:

You can also add --listparameters:

As shown in the following figure: the switched branch tagstill exists, indicating tagthat it has no relationship with the branch, it identifies a specific commit:

git show <tag_name>

As shown in the figure, mastermake two commits on the branch, each time test.txtadding a line of content to the file and labeling it. Among them v1.0are the lightweight tags and v2.0the tags with notes:

Then, use to git showview the content of the tag:

• Lightweight tags:

  

  As shown, the display label instruction v1.0pointed submitted; and, the tag will output the comparison result submitted to the point last submitted; since the tag v1.0points submitted to masterthe first branch of the submission, it was last submission null. Therefore, the comparison result shows that, compared to the last submission, the submission pointed to by the label adds a new line to 1stthe file ;test.txt1st

• Annotated label:

  

  Compared with lightweight tags, a tag with an annotation is an object that can store information such as notes and the person and time of the tag, so the information displayed is more; from the comparison results in the figure, we can see that compared with the previous submission 1st, v2.0The commit pointed to by the tag adds a new line 2ndto the file ;test.txt2nd

4. Find tags

git tag -l <tag_name>

This method supports regular expression search;

As shown in FIG:

• v*It means to search all vthe tags beginning with;
• ?2*It means to search for any 2tags at the beginning, but contains tags;

5. Push the label to the remote

To push the label to the remote warehouse, the first step is to establish a connection between the local warehouse and the remote warehouse. For example, you can use:

git push -u origin master

Establish a connection between the local masterbranch and the remote masterbranch, and perform a push:

git push origin <tag_name>

This method can push the specified local label to the remote warehouse, for example master, v1.0push the label on the local branch to the remote warehouse:

After executing the above instructions, the corresponding information gitTestwill appear in the corresponding remote warehouse tag:

You can also releasesview tagand Releasesinformation in the options :

You can also push multiple local tags to a remote warehouse at the same time :

git push origin  v2.0 v3.0

The above commands are all abbreviated, the complete writing is:

git push origin refs/tags/v4.0:refs/tags/v4.0

git push origin --tag

This method can push all local tags to the remote warehouse at once:

You can also use shorthand commands:

//下面的tag可以写成tags，效果一样
git push --tag

6. Delete the remote tag

Of course, we can delete the remote tag directly on the remote warehouse. However, the best way is to use the command line to delete. The method for deleting remote tags is very similar to the method for deleting remote branches. There are also two methods:

git push origin :<tag_name>

This method is equivalent to pushing an empty label to a remote warehouse, thereby achieving the effect of deletion. For example, delete the label in the remote warehouse v3.0:

git push origin :v3.0

In this way, the label in the remote warehouse V3.0is deleted:

However, the corresponding label in the local warehouse V3.0has not been deleted:

The above instructions are abbreviated, and the complete writing is as follows :

git push origin :refs/tags/v3.0

git push origin --delete <tag_name>

This method uses more semantic parameters --deleteto realize the deletion of remote tags:

git push origin --delete v2.0

The label in the remote warehouse was also successfully deleted v2.0:

However, the local label v2.0has not been deleted:

Using the following complete writing, the effect is the same:

git push origin --delete tag v2.0

It is not difficult to find that the method of deleting remote branches and remote tags is the same .

7. Delete the local label

git tag -d <tag_name>

For example, delete the label by the following command v3.0:

git tag -d v3.0

8. Switch labels

git checkout <tag_name>

As shown in the figure, masterthree commits were made on the branch, and the corresponding tags were added:

When we checkoutswitch to the label by command v2.0:

Visible, there will be free submission. Check the status of each branch at this time:

As shown in the figure above, you are currently in v2.0the commit pointed to by the tag , and you have changed the HEADpointer during the tag switching process . However, masterthe direction of the branch has not been changed . The process is shown below:

In other words, switching labels is resetvery similar to using version rollback. It's just that switching the label only changes the HEADpointer, which will cause a free commit. If necessary, you can create a new branch to save.

9. Pull the label

In the situation shown in the figure below, the local warehouse mygitand the remote warehouse have a common commit history (homologous), and there is no merge conflict (for details, please refer to the Git application detailed explanation: Lecture 6: Git collaboration and Git pull FAQ ) :

You can directly git pullpull the label of the remote warehouse and create a label that is not in the local warehouse:

Second, the Gitalias

1. Set the gitcommand alias

git config <作用域> alias.<别名> '<命令>'

Aliases are an alternative, using a short string to replace commonly used long commands. For example, you can use aliases brato replace branchcommands with the following commands:

git config --global alias.bra branch 

When the command is shorter, you can omit the single quotes around the command:

In the above command:

• --globalIndicates that the set alias scope is the system user, that is, the user gitcan use this alias for all warehouses; the rest have warehouse scope --loacland system scope --system;

• alias.brIndicates that the alias is changed to br;

• branchThe commands that need to be aliased afterwards can be long commands with parameters. At this time, the single quotes around the command cannot be omitted:

  git config --global alias.dog 'log --all --decorate --oneline --graph'
  

  

Since the alias scope configured above is for system users, this configuration will be written to the gitconfigconfiguration file. Open the file to see the written alias configuration :

Added: Use vi ~/.gitconfigcan open gitconfigthis file (remember to add a little), no matter what path is currently located;

In other words, you can set the alias directly by modifying the gitconfigfile aliasoptions, but it is not recommended .

In this way, some common commands can be simplified through aliases, such as git status, git checkoutetc .:

2. Set the external command alias

gitkExternal commands like this have no gitprefix. The method of setting the alias gitis different from the command provided by the setting , and should be set in the following format:

git config <作用域> alias.<别名> '<!外部命令>'

• The exclamation mark indicates that this is an external command;
• Note that single quotation marks should be added without gitprefixing;

For example, in the system user scope, the alias will be git uiset as gitk:

 git config --global alias.ui '!gitk'

After setting, the configuration will be written to the system user's configuration file gitconfig:

Then directly use git uiit to open the gitkinterface:

Supplement: After setting the alias, the original command is still valid.

3. Garbage collection:Git gc

The so-called gcgarbage collection mechanism is actually used less; its role is to clean up unnecessary files and optimize the local repository .

To demonstrate its role, set up the following test environment:

• First, mygitcreate two branches in the local warehouse masterand devpush them to the remote warehouse:

  

• Then, mygitadd a lightweight label v1.0and a label with notes to the local warehouse v2.0:

  

At this time .git/refs, the files in the directory are as follows:

headsThe catalog stores local branch information, the remotecatalog stores remote branch information, and the tagscatalog stores tag information, which is in line with expectations.

Then, execute the git gccommand:

Check the .git/refscatalog again :

You can see refsthat the files in the directory and its subdirectories disappeared, but there .gitis one more packed-refsfile in the directory. In fact, refsthe files in the directory did not disappear, but were packed into packed-refsfiles. Open the packed-refsfile:

You can see that the files in the directory and its subdirectories are compressed and packaged into files git gcafter execution . It can be seen from the figure that the lightweight tags occupy only one line, while the annotated tags occupy two lines:refspacked-refsv1.0v2.0

• The values ​​of the first 6line and the second 8line SHA1are the same, because both tags are added to the same submission;
• v2.0The other line of information (the second 7line) in the annotated label indicates tagthe SHA1value of the object ;

After packaging, modify the file again , or add a branch , the new content will still be .git/refsdisplayed in the directory, and will not be packaged into the packed-refsfile, it needs to be re-executed git gcto be packaged.

The above is the whole content of this section. After studying in this section, I believe that you have been able to use Gittags and aliases to improve development efficiency. The next section will be introduced in detail git cherry-pickand git rebasewe will see you in the next section!