Specification -Git playing tag with the Git version control and version control to play tag specification

Git playing tag with the version control standard

Foreword

This article is for use Git to do a scene VCS (version control system).

Used Git program ape, like its distributed architecture brings commitpleasure. Do not like to use SVN version of this centralized management system, each commit the code, the code must be conflict gotten me very nervous.
Frequent commitbehind, the result is to bring a long list of records submitted by dense.
Once the project is a problem, the problem needs to check the code of a node, will be a little headache.
Although there are commit message, but there is still the difficulty of finding and problem description unclear.

The focus of this article is through tagging features of Git git tagto solve this problem, and (semantic version control specification) specification with SemVer name tag.

First, tagging

Tagging role is to develop the project node, plus the semantic name, that function version of the alias.
Tag the name while writing the incidental information, you can easily project future maintenance process back and review.
In addition, the label can also record, an overview of the current project downward compatibility, and iterative modification where the API.

1.1 tagging commands

It is recommended to play information note with the label, so you can maximize check the label version of modified circumstances.

// 命令格式
git tag -a 标签名 -m "附注信息"

// 示例
git tag -a v0.1.0 -m "完成了文章a和文章b的撰写，耗费时间2h，感觉棒棒的！"

1.2 For chestnuts

An anthology awaiting publication, there are a、b、c、dfour.
Git management progress by now.

1. After two commitoperations, adding a.txtand b.txtlater, to change the code push remote repository.

Warehouse schema as follows:

master -> * 添加b.txt
          | 
          * 添加a.txt
          |
          * 初始化

2. to the current corpus to make a label, by the way leave a mood

// 打标签
git tag -a v0.1.0 -m "完成了文章a和文章b的撰写，耗费时间2h，感觉棒棒的！"

// push 标签到远程仓库 git push origin v0.1.0

Warehouse schema as follows:

    master v0.1.0 -> * 添加b.txt
                     | 
                     * 添加a.txt
                     |
                     * 初始化

3. then after two commitoperations, adding c.txtand d.txtlater, to change the code push remote repository.

Warehouse schema as follows:

           master -> * 添加d.txt
                     |
                     * 添加c.txt
                     |
           v0.1.0 -> * 添加b.txt
                     | 
                     * 添加a.txt
                     |
                     * 初始化

4. anthology has been finished, the end to make a version of the label

// 打标签
git tag -a v1.0.0 -m "文集完成，共4篇文章，等出版。"

// push 标签到远程仓库 git push origin v1.0.0

Warehouse schema as follows:

    master v1.0.0 -> * 添加d.txt
                     |
                     * 添加c.txt
                     |
           v0.1.0 -> * 添加b.txt
                     | 
                     * 添加a.txt
                     |
                     * 初始化

5. After a period of time, I want to know anthology in v0.1.0situations versions

// 输出v0.1.0的详情
git show v0.1.0

// 输出结果
tag v0.1.0 Tagger: wall <582104384@qq.com> Date: Wed May 23 15:57:13 2018 +0800 完成了文章a和文章b的撰写，耗费时间2h，感觉棒棒的！ commit 7107eb8b3f870cd864e3eb5b14f26184d73dd1e6 (tag: v0.1.0) Author: wall <582104384@qq.com> Date: Wed May 23 15:27:10 2018 +0800 添加b.txt diff --git a/src/b.txt b/src/b.txt new file mode 100644 index 0000000..f9ee20e --- /dev/null +++ b/src/b.txt

Here, you can clearly see the time tagging of content and information notes.
There is another convenient point, that does not require the version number represented by the hash string to see the changes.

Here are the results of a query with a version number:

// 用版本号查看
git show 7107eb8b3f870cd864e3eb5b14f26184d73dd1e6

// 输出结果
commit 7107eb8b3f870cd864e3eb5b14f26184d73dd1e6 (tag: v0.1.0) Author: wall <[email protected]> Date: Wed May 23 15:27:10 2018 +0800 添加b.txt diff --git a/src/b.txt b/src/b.txt new file mode 100644 index 0000000..f9ee20e --- /dev/null +++ b/src/b.txt @@ -0,0 +1 @@ +This is B. \ No newline at end of file

1.3 summarized the advantages and disadvantages

• The version number hash string unfriendly, hard to remember
• Semantic tags, developer-friendly, easy to extract notes of development information

Second, semantic version control specification

Chestnuts like the above, it can be seen using v0.1.0and v1.0.0playing tag.
In fact, here we follow a set of semantic versioning specification (Semantic Versioning).

Summary of the following specifications:

Version format: major version minor version number revision number, the version number is incremented rules are as follows:

1. The major version number: When you make an incompatible API changes,
2. Minor version number: When you do a functional backward compatible with the new,
3. Revision number: When you do a downward compatibility problems fixed.

First version of the compiler and version number information can be added to the "major version. Minor version number. Revision Number" later, as an extension.

Why should this specification, is to avoid areas of software management's existence, known as the valley of death "dependency hell".

Specification details, reference can be obtained at the following link.

Third, the reference

[1]  semantic version 2.0