【软件测试】Git 详细实战-打标签，一篇通关...

目录：导读

- 前言
- 一、Python编程入门到精通
- 二、接口自动化项目实战
- 三、Web自动化项目实战
- 四、App自动化项目实战
- 五、一线大厂简历
- 六、测试开发DevOps体系
- 七、常用自动化测试工具
- 八、JMeter性能测试
- 九、总结（尾部小惊喜）

前言

Git 打标签
一般会给提交历史打个标签，方便后续进行筛选、查看

列出标签

可带上可选的 -l 选项 --list

$ git tag
v1.0
v2.0

这个命令以字母顺序列出标签

可以按照特定的模式查找标签：
例如，Git 代码仓库包含标签的数量超过 500 个，只想查 v1.8.5 相关的内容

$ git tag -l "v1.8.5*"
v1.8.5
v1.8.5-rc0
v1.8.5-rc1
v1.8.5-rc2
v1.8.5-rc3
v1.8.5.1
v1.8.5.2
v1.8.5.3
v1.8.5.4
v1.8.5.5

标签的分类

Git 支持两种标签：
轻量标签（lightweight）；
附注标签（annotated）；

轻量标签：
很像一个不会改变的分支，它只是某个特定提交的引用

附注标签：
是存储在 Git 数据库中的一个完整对象，它们是可以被校验的；
其中包含打标签者的名字、电子邮件地址、日期时间，此外还有一个标签信息，并且可以使用 GNU Privacy Guard （GPG）签名并验证；
通常会建议创建附注标签，这样可以拥有以上所有信息；
但是如果你只是想用一个临时的标签，或者因为某些原因不想要保存这些信息，那么也可以用轻量标签；

附注标签相关命令

创建附注标签
在运行 tag 命令时指定 -a 选项

$ git tag -a v1.4 -m "my version 1.4"
$ git tag
v0.1
v1.3
v1.4

-m 选项指定了一条将会存储在标签中的信息，如果不加，就会要求你手动输入

查看标签信息和提交信息
通过使用 git show 命令可以看到标签信息和与之对应的提交信息

$ git show v1.4
tag v1.4
Tagger: Ben Straub <ben@straub.cc>
Date:   Sat May 3 20:19:12 2014 -0700

my version 1.4

commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date:   Mon Mar 17 21:52:11 2008 -0700

    changed the version number

输出显示了打标签者的信息、打标签的日期时间、附注信息，然后显示具体的提交信息

轻量标签相关命令

本质上是将提交校验和（SHA，那串很长的乱码）存储到一个文件中，没有保存任何其他信息

创建轻量标签
不需要使用 -a、-s 或 -m 选项，只需要提供标签名字

$ git tag v1.4-lw
$ git tag
v0.1
v1.3
v1.4
v1.4-lw
v1.5

这时，如果在标签上运行 git show，你不会看到额外的标签信息。命令只会显示出提交信息

$ git show v1.4-lw
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date:   Mon Mar 17 21:52:11 2008 -0700

    changed the version number

后期打标签
也可以对提交历史打标签

实际例子
假设提交历史是这样的

$ git log --pretty=oneline
15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment'
a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support
0d52aaab4479697da7686c15f77a3d64d9165190 one more thing
6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment'
0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function
4682c3261057305bdd616e23b64b0857d832627b added a todo file
166ae0c4d3f420721acbb115cc33848dfcc2121a started write support
9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile
964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo
8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme

现在，假设在 v1.2 时你忘记给项目打标签，也就是在 “updated rakefile” 的提交历史

补打标签
你可以在之后补上标签。要在那个提交上打标签，你需要在命令的末尾指定提交的校验和（或部分校验和）

git tag -a v1.2 9fceb02

查看补打标签的信息

$ git tag
v0.1
v1.2
v1.3
v1.4
v1.4-lw
v1.5

$ git show v1.2
tag v1.2
Tagger: Scott Chacon <schacon@gee-mail.com>
Date:   Mon Feb 9 15:32:16 2009 -0800

version 1.2
commit 9fceb02d0ae598e95dc970b74767f19372d61af8
Author: Magnus Chacon <mchacon@gee-mail.com>
Date:   Sun Apr 27 20:43:35 2008 -0700

    updated rakefile
...

共享标签

默认情况下，git push 命令并不会传送标签到远程仓库服务器上
在创建完标签后你必须显式地推送标签到远程仓库上

推送标签的语法格式

git push <remote> <tagname>

实际例子：

polo@B-J5D1MD6R-2312 watermarker % git push origin2 1.11

枚举对象中: 17，完成。
对象计数中: 100% (17/17)，完成。
使用 12 个线程进行压缩
压缩对象中: 100% (12/12)，完成。
写入对象中: 100% (14/14)，1.47 KiB | 1.47 MiB/s，完成。
总共 14（差异 6），复用 0（差异 0），包复用 0

remote: Powered by GITEE.COM [GNK-5.0]
To gitee.com:poloyy/watermarker.git
 * [new tag]         1.11 -> 1.11

一次性推送过个标签
如果想要一次性推送很多标签，也可以使用带有 --tags 选项的 git push 命令。这将会把所有不在远程仓库服务器上的标签全部传送到那里。

git push origin2 --tags
枚举对象中: 6, 完成.
对象计数中: 100% (6/6), 完成.
使用 12 个线程进行压缩
压缩对象中: 100% (4/4), 完成.
写入对象中: 100% (5/5), 452 字节 | 452.00 KiB/s, 完成.
总共 5（差异 2），复用 0（差异 0），包复用 0
remote: Powered by GITEE.COM [GNK-5.0]
To gitee.com:poloyy/watermarker.git
 * [new tag]         1.2 -> 1.2
 * [new tag]         1.3 -> 1.3

现在，当其他人从仓库中克隆或拉取，他们也能得到这些标签

删除标签

删除掉本地仓库上的标签，加个 -d 就行

polo@B-J5D1MD6R-2312 watermarker % git tag
1.11
1.2
1.3
testbu
v1.1
polo@B-J5D1MD6R-2312 watermarker % git tag -d 1.11
已删除标签 '1.11'（曾为 9baca61）
polo@B-J5D1MD6R-2312 watermarker % git tag -d 1.2
已删除标签 '1.2'（曾为 e4da7ac）
polo@B-J5D1MD6R-2312 watermarker % git tag -d 1.3
已删除标签 '1.3'（曾为 bf12eaa）
polo@B-J5D1MD6R-2312 watermarker % git tag
testbu
v1.1

-d 删除标签并不会从任何远程仓库中删除这个标签

删除远程仓库的标签

第一种，–delete

$ git push origin --delete <tagname>

简单粗暴的方式

例子：

polo@B-J5D1MD6R-2312 watermarker % git push origin2 --delete 1.2
remote: Powered by GITEE.COM [GNK-5.0]
To gitee.com:poloyy/watermarker.git
 - [deleted]         1.2
polo@B-J5D1MD6R-2312 watermarker % git push origin2 --delete 1.3
remote: Powered by GITEE.COM [GNK-5.0]
To gitee.com:poloyy/watermarker.git
 - [deleted]         1.3

第二种，传空值

git push <remote> :refs/tags/<tagname>

将冒号前面的空值推送到远程标签名，从而高效地删除它

例子：

polo@B-J5D1MD6R-2312 watermarker % git push origin2 :refs/tags/1.11
remote: Powered by GITEE.COM [GNK-5.0]
To gitee.com:poloyy/watermarker.git
 - [deleted]         1.11

checkout 标签

如果想查看某个标签所指向的文件版本，可以使用 git checkout 命令
但仓库处于“分离头指针（detached HEAD）”的状态，会有些小问题存在

polo@B-J5D1MD6R-2312 watermarker % git status
头指针分离于 testbu
无文件要提交，干净的工作区

checkout 的例子：

polo@B-J5D1MD6R-2312 watermarker % git checkout testbu
注意：正在切换到 'testbu'。

您正处于分离头指针状态。您可以查看、做试验性的修改及提交，并且您可以在切换
回一个分支时，丢弃在此状态下所做的提交而不对分支造成影响。
如果您想要通过创建分支来保留在此状态下所做的提交，您可以通过在 switch 命令
中添加参数 -c 来实现（现在或稍后）。
例如：
git switch -c <新分支名>

或者撤销此操作：
git switch -

通过将配置变量 advice.detachedHead 设置为 false 来关闭此建议
HEAD 目前位于 7fa175d test

查看当前所处分支

polo@B-J5D1MD6R-2312 watermarker % git branch
* （头指针在 1.2 分离）
  master

能看到执行 git checkout 之后，本地分支会自动切换到头指针分支

重点：
在“分离头指针”状态下，如果做了某些更改然后提交它们，标签不会发生变化
但新提交将不属于任何分支，并且将无法访问，除非通过确切的提交哈希才能访问，看下面的实际例子

polo@B-J5D1MD6R-2312 watermarker % git push
fatal: 您当前不在一个分支上。
现在为推送当前（分离头指针）的历史，使用

    git push origin HEAD:<远程分支名字>

需要指定远程分支的哈希（就是那串很长的乱码字符串）

因此，如果你需要进行更改，比如你要修复旧版本中的错误，那么通常需要创建一个新分支

polo@B-J5D1MD6R-2312 watermarker % git checkout -b newtest3 1.2
切换到一个新分支 'newtest3'
polo@B-J5D1MD6R-2312 watermarker % git branch
  master
  newtest2
* newtest3

下面是我整理的2023年最全的软件测试工程师学习知识架构体系图