Shulou(Shulou.com)06/01 Report--

This article focuses on "how to manage git tags". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to manage git tags.

The tag is used to mark a submission point and uniquely bind a fixed commitId, which is equivalent to specifying an alias for the submission record to facilitate the extraction of the file. You can label an important version, either an object or a simple pointer, but the pointer does not move.

New label

Let's say that one of our applications has completed a function after a period of development, and now we need to release it online. We can first merge the development code into master, and then label the current master to identify the current release. If you say it, call it v1.0:

Complete and submit the current code

Yanwei@ubuntu:~/git_test$ git add * yanwei@ubuntu:~/git_test$ git commit-m "v1.0 Last submission" [master c169872] v1.0 Last submission 2 files changed, 1 insertion (+) create mode 100644 new.txtyanwei@ubuntu:~/git_test$ git status

Located in the branch master

No documents to submit, clean workspace

Create a v1.0 tag

Yanwei@ubuntu:~/git_test$ git tag v1.0

View all tag

Yanwei@ubuntu:~/git_test$ git tagv1.0

You can also view the specified label as follows:

Yanwei@ubuntu:~/git_test$ git tag-l "v1.*" v1.0

In the above example, we see a v1.0 tag, but the tag doesn't have any description and doesn't know exactly what it does. At this point, we can add some detailed information when typing tag:

-a specifies that the label is a tag with comments, and-m specifies comments.

Yanwei@ubuntu:~/git_test$ git tag-a v1.1-m "v1.1, nothing changed" View tag details

If you want to view the details of a tag, you can use the following ways:

Yanwei@ubuntu:~/git_test$ git show v1.1tag v1.1Tagger: yanweiDate: Mon Jul 16 19:07:24 2018 + 0800v1.1 version Nothing changed commit c16987225db5f8ff65c7ff858eff4a75992f61dd (HEAD-> master, tag: v1.1, tag: v1.0) Author: yanweiDate: Mon Jul 16 19:01:51 2018 + 0800v1.0 submit diff for the last time-- git a/code.txt b/code.txtindex e064e4c..8f8a0e7 100644 UV-diff. Txtxtcards @-5jue 3 + 5jue 4 @ @ this is the forth linethis is the master branchthis is dev branchthis is dev branch new line+this line for bugdiff-- git a/new.txt b/new.txtnew file mode 100644index 0000000..e69de29 toggle tags

The operation of switching labels is the same as the command to switch branches:

Git checkout [tagname] tagging later

In some application scenarios, a version is not tagged after it is released. Later, in order to standardize management, if you want to tag those versions, you can use the following methods:

Use git log to list some historical version information:

Yanwei@ubuntu:~/git_test$ git log-onelinec169872 (HEAD-> master, tag: v1.1, tag: v1.0) v1.0 Last submission d69c612 merge bug Branch 67de5f6 repair bugea9a7d5 merge with no-ffb89266d (dev) dev branch another commit6c1828d Resolution conflict 2015000 master new commit187dee6 dev first commit0a96a0f forth commite4fb2aa third commit227ecaa second commitd66bdc0 first commit

Specify a label for this version of dev first commit:

Git tag-a v1.2 187dee6 pushes the tag to the remote warehouse

By default, git push does not transfer tags to remote servers, and tags can only be shared to remote repositories through explicit commands. The command format is like a push branch. You can run git push origin [tagname]:

Git push origin v1.1 here, I believe you have a deeper understanding of "how to manage git tags", might as well come to the actual operation of it! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.