preface

Previously: Git RefSpec and remote branch

This section focuses on Git tags, aliases, and Git garbage collection.

A,GitLabel (tag)

1. The essence of the label

Tags and branches are similar in that they refer to a single commit; In addition, their values point to the submitted SHA1 value; However, unlike a branch that changes as the commit changes, once a label is added to a commit, it never changes.

** Note: the ** tag identifies a commit, which can be any commit on any branch.

Two types of tags

Git tags come in two types:

  • Lightweight label(lightweight) : Cannot add comments;
  • Labels with footnotes(annotated) : Comments can be added;

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

Annotated tags are used for publishing, while lightweight tags are used for private or temporary objects.

When should I label it?

  • ** Release: ** The Master branch is generally used as the release branch of the project, when the project has reached a mature stage of development ready for release in the Master branch. The current commit of the Master branch is labeled with something like “V1.2”;

    For example, the Vue framework:

    You can see that there are many labels, and you can view the labels and release versions in the Releases option:

  • ** Version management: ** Can record the status of a certain stage of the project in the form of labels for easy management;

    For example, the code of each knowledge point when managing learning wechat applets:

View the label file

Add a lightweight tag v1.0 and a tag v2.0 with annotations to commit MAS2 for the Master branch, as shown below:

Git dog is an alias for git log –all –decorate –oneline –graph.

Next, look at the.git/refs/tags directory where the tag files are stored:

You can see:

  • tagsThe added label files are stored in the directoryv1.0andv2.0;
  • Open the TAB file separatelyv1.0andv2.0They all have the same valueSHA1Value and is submitted with the location where the label was addedmas2theSHA1value6920a6e...The same.
  • emm...Wait a minute! It’s not equal. It’s justv1.0Value and submitmas2theSHA1The values are equal, and the values are equalv2.0Values of are not equal!
  • Why the same submissionmas2Add labels to themSHA1Will the values be different? This is becausev1.0Is a lightweight tag, whilev2.0It’s a label with a note.

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

  • The lightweight tag v1.0 directly takes this submitted SHA1 value as its own SHA1 value;

  • Annotated tag V2.0 creates a tag object whose SHA1 value is the SHA1 of the tag object.

This is the difference between lightweight tags and tags with annotations. However, both labels still point to the same commit, as shown below:

2. Create a label

git tag <tag_name>

Create a lightweight TAB:

Git tag -a <tag_name> -m

Create a label with annotations:

3. Check labels

git tag

Display all tags added:

You can also add the –list argument:

As shown in the figure below, the tag still exists after the branch is switched, indicating that the tag is not related to the branch, but identifies a specific commit:

git show <tag_name>

As shown in the figure, commit twice on the Master branch, each time adding a line to and labeling the file test.txt. Where V1.0 is a lightweight tag and V2.0 is a tag with annotations:

Next, use git show to view the contents of the tag:

  • Lightweight tags:

    As shown, this directive displays the commit to which the label V1.0 points; Also, the output tag points to the result of the commit compared to the last commit; Since label V1.0 points to the first commit of the Master branch, the last commit is NULL. Commit 1st adds a new line to the test. TXT file compared with the last commit.

  • Annotated label:

    Compared with lightweight labels, a label with annotations is an object, which can store the annotations and the information about the label and the time, so that more information is displayed. From the comparison results in the figure, we can see that commit 2nd with the v2.0 tag is added to the test. TXT file 2nd;

4. Look for labels

git tag -l <tag_name>

This method supports regular expression lookup.

As shown above:

  • v*Search for all of thevA label at the beginning;
  • ? 2 *Indicates any beginning of the search, but contains2The tag;

5. Push the label to the remote

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

git push -u origin master
Copy the code

Create a link between the local master branch and the remote master branch;

git push origin <tag_name>

This method can push the specified local tag to the remote repository, such as the local master branch of the tag v1.0 to the remote repository:

After executing the above command, the corresponding remote repository gitTest will display the corresponding tag information:

You can also view the Tag and Releases information in the Releases option:

You can also push multiple local labels to a remote repository at the same time:

Git Push Origin v2.0 v3.0Copy the code

The above commands are abbreviated form, complete as:

Git push origin refs/tags/v4.0: refs/tags/v4.0Copy the code

git push origin --tag

This method pushes all local labels to the remote repository at once:

You can also use the shorthand command:

Git push -- git push -- git pushCopy the code

6. Delete the remote label

Of course, we can delete the remote label directly on the remote repository. However, the best way to do this is to use the command line. The method of deleting a remote label is very similar to the method of deleting a remote branch. There are also two methods:

git push origin :<tag_name>

This method is equivalent to pushing an empty label to the remote repository for deletion. For example, delete tag V3.0 from remote repository:

Git push origin: v3.0Copy the code

This removes the tag V3.0 from the remote repository:

However, the corresponding tag V3.0 in the local repository has not been removed:

The above instructions are abbreviated as follows:

Git push origin: refs/tags/v3.0Copy the code

git push origin --delete <tag_name>

This method uses a more semantic parameter –delete to achieve remote label deletion:

Git push Origin --delete v2.0Copy the code

The tag v2.0 in the remote repository was also successfully removed:

However, the local tag v2.0 has not been removed either:

The effect is the same with the following complete notation:

Git push Origin --delete tag v2.0Copy the code

As you can see, the method for deleting remote branches and tags is the same.

7. Delete the local label

git tag -d <tag_name>

For example, run the following command to delete label V3.0:

git tag -d v3.0
Copy the code

8. Switch labels

git checkout <tag_name>

As shown, three commits are made on the master branch and the appropriate tags are added:

When we switch to the tag v2.0 via the checkout command:

As you can see, a stray commit occurs. Check the status of each branch:

As shown in the figure above, the commit is currently in the direction of the label V2.0, and the switching of the label changes the direction of the HEAD pointer. However, it does not change the direction of the branch master. The process is shown in the figure below:

That is, switching labels is very similar to using RESET for version rollback. However, switching labels only changes the point of the HEAD pointer, causing a stray commit. Create a new branch to save if necessary.

9. Pull the label

In the case shown below, the local repository myGit and the remote repository have a common commit history (homology) and there is no merge conflict.

You can directly use Git pull to pull a tag from a remote repository and create a tag that does not exist in the local repository:

Second,GitThe alias

Set 1.gitCommand alias

Git config < scope > alias.< alias >' < command >'

An alias is an alternative, using a short string in place of a commonly used long command. For example, you can replace the branch command with the bra alias:

git config --global alias.bra branch 
Copy the code

If the command is short, omit the single quotation marks around the command:

In the above commands:

  • –global indicates that the alias is set to the system user, that is, the user can use the alias for all git repositories; The warehouse scope — LOACL, system scope –system;

  • Alias. br Changes the alias to br.

  • Branch indicates a command that needs to be aliased. It can be a long command with arguments. Do not omit the single quotation marks around the command:

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

Because the alias configured above is scoped to system users, this configuration is written to the gitConfig configuration file. Open the file to see the alias configuration written:

** Add: ** You can open the gitConfig file directly with vi ~/. Gitconfig, regardless of the current path;

This means that you can set the alias directly by modifying the Alias option in the gitConfig file, but it is not recommended.

Git status, git checkout, git checkout, etc.

2. Set an alias for an external command

External commands such as gitk do not have git prefixes. Git alias: Git alias: git alias: git alias

Git config < scope > alias.< alias > '<! External command >'
  • An exclamation mark indicates that this is an external command;
  • Make sure you use single quotation marks, don’t use themgitThe prefix.

For example, set git UI to gitk alias under system user scope:

 git config --global alias.ui '! gitk'
Copy the code

After the configuration is complete, the configuration will be written to the gitconfig file of the system user:

Git UI to open the Gitk interface:

** Added: ** after the alias is set, the original command is still valid.

Three, garbage recycling:Git gc

The so-called GC is the garbage collection mechanism, which is rarely used; Its purpose is to clean up unnecessary files and optimize the local repository.

To demonstrate this in action, set up the following test environment:

  • First, create the master and dev branches in the local repository mygit and push them to the remote repository:

  • Then, add a lightweight tag v1.0 and a tag v2.0 with annotations to the local repository myGit:

Git /refs files are as follows:

The heads directory stores local branch information, the remote directory stores remote branch information, and the tags directory stores tag information, as expected.

Next, execute the git gc command:

Git /refs

You can see that the refs directory and its subdirectories are missing, but there is a Packed -refs file in the.git directory. In fact, instead of disappearing, the files in the refs directory are packed into the Packed -refs file. Open the Packed -refs file:

You can see that the refs directory and its subdirectories are compressed into the Packed -refs file after git GC. As you can see from the figure, the lightweight tag v1.0 occupies only one line and the annotated tag v2.0 occupies two lines:

  • Among them the first6And the first8theSHA1The values are the same because both labels were added to the same commit;
  • And a label with a notev2.0Another line of information (no7Line) representstagThe object’sSHA1Value;

Git /refs is not packed into the Packed -refs file. You need to execute git gc again to pack it.

This is the end of this section. You should be able to use Git tags and aliases to improve your development efficiency. Git cherry-pick and git rebase will be introduced in the next section.