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.txt 和 b.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.txt和d.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.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

这里,可以清晰地看到当时打标签的内容和附注信息。
还有另外一个方便的点,就是不需要用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.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 归纳优缺点

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

二、语义化版本控制规范

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

规范的概要如下:

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

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

先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面,作为延伸。
为什么要有这套规范,就是为了避免软件管理的领域里存在的,称为“依赖地狱”的死亡之谷。

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

三、参考

[1] 语义化版本2.0

[[2] 原文连接
[[3] git 基础-打标签

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值