Git打标签与版本控制规范

前言

本文适用于使用Git做VCS(版本控制系统)的场景。

用过Git的程序猿,都喜欢其分布式架构带来的commit快感。不用像使用SVN这种集中式版本管理系统,每一次提交代码,都要为代码冲突捏一把冷汗。
频繁commit的背后,带来的结果是一长串密密麻麻的提交记录。
一旦项目出现问题,需要检查某个节点的代码问题,就会有点头疼。
虽然有commit message,但还是有存在查找困难和描述不清的问题。

本文的侧重点,就是通过Git的打标签功能git tag来解决这个问题,并用SemVer(语义化版本控制规范)规范标签的命名。

一、打标签

打标签的作用,就是给项目的开发节点,加上语义化的名字,也即功能版本的别名。
打上标签名的同时,写上附带信息,可以方便项目日后维护过程中的回溯和复查。
另外,也可以通过标签记录,大致了解当前项目的向下兼容性、API的修改和迭代情况。

1.1 打标签命令

一般推荐打带附注信息的标签,这样可以最大限度查看标签版本的修改情况。

// 命令格式git tag -a 标签名 -m "附注信息"// 示例git tag -a v0.1.0 -m "完成了文章a和文章b的撰写,耗费时间2h,感觉棒棒的!"

1.2 举个栗子

一份文集等待出版,有a、b、c、d四篇。
现在通过Git管理进度。

1.经过两次commit操作,添加a.txtb.txt后,将代码修改push到远程仓库。

仓库图表如下:

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

2.给当前文集打个标签,顺便留个心情

// 打标签git tag -a v0.1.0 -m "完成了文章a和文章b的撰写,耗费时间2h,感觉棒棒的!"// push 标签到远程仓库git push origin v0.1.0

仓库图表如下:

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

3.再经过两次commit操作,添加c.txtd.txt后,将代码修改push到远程仓库。

仓库图表如下:

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

4.文集已经写完,打个完结版的标签

// 打标签git tag -a v1.0.0 -m "文集完成,共4篇文章,等出版。"// push 标签到远程仓库git push origin v1.0.0

仓库图表如下:

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

5.过了段时间,我想知道文集在v0.1.0版本的情况

// 输出v0.1.0的详情git show v0.1.0// 输出结果tag v0.1.0Tagger: 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.txtdiff --git a/src/b.txt b/src/b.txtnew file mode 100644index 0000000..f9ee20e--- /dev/null+++ b/src/b.txt

这里,可以清晰地看到当时打标签的内容和附注信息。
还有另外一个方便的点,就是不需要用hash字符串表示的版本号去查看更改。

以下是用版本号查询的结果:

// 用版本号查看git show 7107eb8b3f870cd864e3eb5b14f26184d73dd1e6// 输出结果commit 7107eb8b3f870cd864e3eb5b14f26184d73dd1e6 (tag: v0.1.0)Author: wall <582104384@qq.com>Date:   Wed May 23 15:27:10 2018 +0800    添加b.txtdiff --git a/src/b.txt b/src/b.txtnew file mode 100644index 0000000..f9ee20e--- /dev/null+++ b/src/b.txt@@ -0,0 +1 @@+This is B.\ No newline at end of file

1.3 归纳优缺点

  • 版本号hash字符串不友好,不方便记忆
  • 标签语义化,对开发人员友好,方便提取附注的开发信息

二、语义化版本控制规范

像上文的栗子,可以看出使用了v0.1.0v1.0.0打标签。
其实,这里遵循了一套语义化版本控制规范(Semantic Versioning)。

规范的概要如下:

版本格式:主版本号.次版本号.修订号,版本号递增规则如下:

  1. 主版本号:当你做了不兼容的 API 修改,
  2. 次版本号:当你做了向下兼容的功能性新增,
  3. 修订号:当你做了向下兼容的问题修正。

先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面,作为延伸。

为什么要有这套规范,就是为了避免软件管理的领域里存在的,称为“依赖地狱”的死亡之谷。

规范详情,可以在下面的参考链接获取。

三、参考

[1] 语义化版本2.0

(0)

相关推荐

  • Git学习总结

    git是一个分布式版本控制系统,可以使编程人员能够灵活的在同一个项目的不同版本之间进行调控以及和gitHub配合进行团队开发. git安装不在此记录. 此为个人总结笔记,可以对git进行正常的使用,不 ...

  • svn版本控制迁移到git

    获得原 SVN 仓库使用的作者名字列表 因为导入到git需要配置原作者(svn提交人)和git账户的映射关系 其格式为: vim authors-transform.txt taoxs = xsTao ...

  • git实操常用命令汇总-小马哥

    github在备案地执行git commit 后需要运行以下代码: 1.创建README.md 2.git add README.md 3.git commit -m '第一次提交' 4.git re ...

  • git使用教程9-pycharm 使用 tag 打标签

    前言 当我们的代码完成了第一阶段的需求,版本稳定后,希望能出个稳定版本.于是在 commit 后需要打个 tag 标签,也就是我们平常说的版本号,如v1.0版本 本篇讲解如何使用 pycharm 打 ...

  • 【Git基本命令】

    [基本指令] git init :使目标文件夹变成一个仓库 git add <文件名,含后缀> : 告诉git我要添加文件了 git commit -m "<提交说明> ...

  • git常用命令以及使用规范

    首先说一下常用的git命令 克隆项目 git clone ... 从master分支上拉取一个新分支 git checkout -b xxx(分支名字) 根据master分支拉取一个xxx分支出来gi ...

  • 实验室溶液标签规范写法

    ↓↓↓ 5.6月 培训汇总 →[报名] 好书推荐→[购买] 2021年能力验证  →[报名] 实验室服务清单 实验室溶液标签规范写法 1 溶液标签使用的要求 实验室溶液标签一般需要写明五项内容:名称. ...

  • 开发中的你的Git提交规范吗?

    开发中的你的Git提交规范吗?

  • 制作文件盒侧标签,掌握这些技巧,不仅省时省力,而且规范完美

    制作文件盒侧标签,掌握这些技巧,不仅省时省力,而且规范完美

  • NFC论坛发布新规范 对ISO 15693标签提供使用支持

    NFC Forum,已经发布了新的规范,正式称为Type 5标签操作规范,其目的是增加对符合ISO 15693标准的13.56 MHz无源RFID标签的使用支持和规范,并为p2p通信提供了一个主动通信 ...

  • 程序员必读:Git提交信息和分支创建规范

    为什么要制定规范 古话说,没有规矩不成方圆.在团队协作开发时,每个人提交代码时都会写 commit message,但如果没有规范,每个人都会有自己的书写风格,因此在翻看 git log 时经常看到的 ...

  • 前端学习之路,前端开发人员如何在团队中规范git commit提交记录

    摘要 近期在review团队的部分代码,对比个人初期与如今的git提交记录,发现初期的提交记录简直是五花八门,言不由衷,让人一打眼看去就觉得这写的什么东西.一个好的git提交记录既方便个人快速的了解自 ...