preface

This article is intended for use with Git as a VCS (version control system).

Programmers who have used Git enjoy the commit thrill of its distributed architecture. Instead of using a centralized version management system like SVN, you have to worry about code conflicts every time you commit code. The result of frequent commits is a long list of committal records. When a project goes wrong and you need to check for code problems at a node, it can be a bit of a headache. Although there are commit messages, there are still problems with lookup difficulties and unclear descriptions.

The focus of this article is to solve this problem through Git tag function Git Tag, and use SemVer (semantic version control specification) to standardize the name of tags.

First, label

The purpose of tagging is to give the development nodes of a project semantic names, which are aliases for functional versions. The label name and accompanying information can facilitate the backtracking and review of the project in the future. In addition, you can use the label record to get an overview of the current project’s downward compatibility, API changes, and iterations.

1.1 Label Commands

It is recommended to label the label with annotated information, so that you can view the modification of the label version to the maximum extent.

// The command format is git tag-aTag name - m"Notes information"// git tag-aV0.1.0 -m"Finished the writing of article A and article B, which took 2 hours, and I feel great!"
Copy the code

1.2 For example

An anthology is waiting to be published, with four parts A, B, C and D. Progress is now managed through Git.

  1. After twocommitOperation, adda.txtandb.txtAfter the code changes are pushed to the remote repository.

The warehouse chart is as follows:

The master - > * add b.t xt added a.t xt | | * * initializedCopy the code
  1. Label the current anthology and leave a note of mood
// Git tag-aV0.1.0 -m"Finished the writing of article A and article B, which took 2 hours, and I feel great!"Git push Origin v0.1.0Copy the code

The warehouse chart is as follows:

Master v0.1.0 - > * add b.t xt add a.t xt | | * * initializedCopy the code
  1. Two more passescommitOperation, addc.txtandd.txtAfter the code changes are pushed to the remote repository.

The warehouse chart is as follows:

Master - > add which xt | * * add c.t xt | v0.1.0 - > * add b.t xt add a.t xt | | * * initializedCopy the code
  1. The anthology is finished. Label it as the final edition
// Git tag-aV1.0.0 -m"Collected works completed, a total of 4 articles, to be published."Git push Origin v1.0.0Copy the code

The warehouse chart is as follows:

Master v1.0.0 - > add which xt | * * add c.t xt | v0.1.0 - > * add b.t xt add a.t xt | | * * initializedCopy the code
  1. After a while, I wondered where the anthology wasv0.1.0Version status
Git show v0.1.0 tag v0.1.0 Tagger: wall <[email protected]> Date: Wed May 23 15:57:13 2018 +0800 completed the writing of article A and article B, which took 2h and felt great! commit 7107eb8b3f870cd864 e3eb5b14f26184d73dd1e6 (tag: v0.1.0) Author: wall < @qq.com > 582104384 Date: Wed May 23 15:27:10 2018 +0800 Add b.tep diff --git a/ SRC/b.tep b/ SRC/B.tep new file mode 100644 index 0000000.. f9ee20e --- /dev/null +++ b/src/b.txtCopy the code

Here, you can clearly see the content of the label and the footnote information. Another convenience is that you don’t need a hash string version number to see changes.

Here are the results of the query using the version number:

Git show 7107eb8b3f870cdCommit 7107 eb8b3f870 e3eb5b14f26184d73dd1e6/864 / output resultscd864 e3eb5b14f26184d73dd1e6 (tag: v0.1.0) Author: wall < @qq.com > 582104384 Date: Wed May 23 15:27:10 2018 +0800 Add b.tep diff --git a/ SRC/b.tep b/ SRC/B.tep new file mode 100644 index 0000000.. F9ee20e -- /dev/null +++ + b/ SRC /b.txt @@ -0,0 +1 @@ +This is b. \ No newline at end of fileCopy the code

1.3 Summarize advantages and disadvantages

  • The hash version string is unfriendly and difficult to remember
  • Tag semantic, friendly to developers, easy to extract annotated development information

Semantic version control specification

As with chestnuts above, you can see that v0.1.0 and V1.0.0 are used for labeling. In fact, there is a Semantic Versioning specification that is followed.

The outline of the specification is as follows:

Version format: Major version number. The second version number. The increment rule is as follows:

  1. Major version number: When you make incompatible API changes,
  2. Minor version number: When you make a backward-compatible feature addition,
  3. Revision number: When you make a backward compatible problem fix.

The prior version number and version build information can be added to the major version number. Second version number. Revision number “is followed as an extension.

The reason for this specification is to avoid the “dependency hell” valley of death that exists in software management.

Specification details can be obtained from the reference link below.

Three, reference

[1] Semantic version 2.0

Friends who like my articles can follow me in the following ways:

  • “Star” or “watch” my GitHub blog
  • RSS subscribe to my personal blog:Mr. Wang’s base