【深入浅出 Git】：从入门到精通

这篇文章介绍下版本控制器。

【深入浅出 Git】：从入门到精通

Git是什么
Git的安装
Git的基本操作
理解分布式
远程仓库相关操作

Git是什么

Git是一种版本控制器，帮助我们管理一个文件的各种版本，Git几乎可以管理所有的文件，但是对于程序员来说，最常见的就是管理源文件。

注意：Git作为版本控制器，它并不会给你保存所有的版本的文件，它只会告诉你改动的地方，对于文本文件是这样；对于视频、音频这些二进制文件，它只能告诉你它们的改动前后的大小的变化。

Git的安装

centos下：

bash 复制代码

#更新软件包列表
sudo yum update -y

#安装git
sudo yum install git -y

#验证安装
git --version

ubuntu下：

sql 复制代码

#更新软件包列表
sudo apt-get update

#安装git
sudo apt-get install git -y

#验证安装
git --version

windows下：
- 前往官网安装git.
- 安装后，本地会有Git Bash 和 Git GUI这两个应用：
  - Git Bash：提供了一个类似于 Linux 的命令行界面，适合喜欢命令行操作的用户。
  - Git GUI：为那些更倾向于图形界面操作的用户提供了一个可视化的工具。
- Windows 的命令行（如 CMD 或 PowerShell）中能够直接使用 git 指令，说明 Git 已经被正确安装并且其路径已经被添加到系统的环境变量中。这是 Git 安装程序的默认行为。

Git的基本操作

建立本地仓库

在 Git 中，本地仓库指的是存储在计算机上的一个文件夹，它包含了项目的所有文件以及这些文件的版本历史记录。每个 Git 仓库（repository）都是一个独立的单元，允许您进行版本控制、提交更改、查看历史记录等操作。即使没有网络连接，您也可以在本地仓库中工作，并且在有需要时将更改推送到远程仓库。

新建立一个本地仓库 ：如果此时有一个没有使用git进行版本控制的目录，就可以初始化建立一个新的git仓库
bash 复制代码
```
#先进入该目录
cd /path/project

#初始化本地仓库
git init
```

除此之外，还可以建立远程仓库后，再将其克隆到本地。

配置本地仓库

配置本地仓库，主要是配置用户信息。Git 使用用户名和邮箱来标记每次提交的作者信息。这些信息会嵌入到提交记录中，并在推送至远程仓库时被共享。这样就可以知道每个提交记录的作者了。

设置全局用户信息：如果你希望所有的本地仓库都使用相同相同的用户名和邮箱信息，可以直接奢姿全局的用户信息：
bash 复制代码
```
git config --global user.name "Your Name"
git config --global user.email "[email protected]"
```
- -global 参数表示这些配置将应用于当前用户的所有 Git 仓库。
可以通过以下指令查看当前的全局的用户信息：
bash 复制代码
```
git config --global --list
```
设置局部（本地仓库）的用户信息：也可以仅设置局部的用户信息。
bash 复制代码
```
git config user.name "Your Name"
git config user.email "[email protected]"
```
可以通过以下指令查看当前仓库的局部的用户信息：
bash 复制代码
```
git config --loacl --list
```

认识工作区、暂存区、版本库的概念

工作区 ：新建一个仓库后会生成一个.git目录，与这个.git目录在同一个目录及其子目录的区域都叫工作区，我们未来开发就在这个区域，不包括.git。
暂存区：暂存区是一个临时存储区域，用于存放即将作为下一次提交一部分的文件更改。它位于工作区和版本库之间，充当一个缓冲区的角色。通过使用暂存区，您可以更精细地控制哪些更改会包含在下一个提交中。
- 只有在暂存区的文件才会被提交，所以有了暂存区我们就可以多次提交。现在这个仓库没有添加文件到暂存区（Stage/index），所以该目录没有建立。
版本库 ：存储所有文件历史记录的地方，支持分支管理和版本回滚。整个.git目录我们将其称之为版本库，将文件添加到版本库后，我们才能对其进行管理。

$!caution$
工作区的文件如果没有添加到暂存区 和版本库是不能对其进行管理的。

三者的关系：

在创建 Git 版本库时，Git 会为我们⾃动创建⼀个唯⼀的 master 分⽀，以及指向 master 的⼀个指

针叫 HEAD，这个我们后面再谈。

添加文件

添加文件到暂存区

使用如下指令将文件添加到暂存区：

bash 复制代码

#添加部分文件
git add 文件1 文件2

#添加所有新增或修改的文件
git add .

提交文件到版本库

只添加了文件到暂存区，还不能管理它，必须将暂存区中的文件提交到版本库。

bash 复制代码

git commit - m "描述信息"

描述信息是很重要的，合理的描述信息可以在日志中看到这次提交主要的修改内容，便于管理。

提交文件演示

先在工作区创建一个文件file1.txt：
我们可以使用以下命令，显示工作目录和暂存区的状态：
bash 复制代码
```
git status 
```
该命令还会提示下一步的应该怎么做：
将文件添加到暂存区：
此时暂存区有内容了，我们可以查看一下.git目录，看看它的变化：
- 多了一个index文件，这就是传说中的暂存区，如果我们继续新建文件，然后将代码添加到暂存区，该文件到大小会变大：
提交文件到仓库区：

理解.git目录中的文件

HEAD指针与暂存区

.git目录中有一些目录和文件，在windwos下我们可以使用以下命令查看隐藏文件或目录：

bash 复制代码

Get-ChildItem -Force

cd命令进入.git目录：
index就是我们的暂存区，前面已经说过了。
HEAD指针指向的是当前的默认分支master的最新commit，我们可以打印出HEAD文件来看一下它里面的内容：

打印refs/heads/master的内容：

objects对象

这一连串的数字是什么呢？

在 Git 中，refs/heads/master（或更一般地 refs/heads/）指向的是某个分支的最新提交（即该分支的头部）。这里的"值"实际上是一个 40 字符长的 SHA-1 哈希值，它唯一标识了一个具体的提交对象。

每一个提交的对象都会保存在.git的Object目录中：

这个5e目录中有一个文件就叫做69892b75b83d991b99f1c29a5ebfaba53ee0f0。

objects是git存储库的核心组成部分，里面包含了各种对象，当我们git add时就会创建对象用来保存修改的内容。
对于refs/heads/master保存的commit ID，前2位是目录名，后面的都是文件名。
我们可以使用以下指令来查看某个对象保存的内容，默认情况下是二进制，直接cat打印是乱码。
bash 复制代码
```
git cat-file -p <SHA-1>
```

前面一行有个tree，它后面也跟了一行哈希值。我们直接打印看看是什么内容：

tree 对象的主要作用是描述某个提交（commit）所对应的文件和目录结构。

除了这个tree对象除了保存，提交的文件名，似乎前面还有个blob，blob对象后面也跟了一行哈希值，两个文件两个blob对象，我们猜测一下这应该是我们修改的内容：

blob对象用于存储文件的内容。

所有我们大概清楚objects中是有不同的对象的：blob 对象、tree对象。

那refs/heads/master中保存的是objects中的什么对象呢？我们可以使用下面指令来查某个对象的类型：

bash 复制代码

git cat-file -t <SHA-1>

HEAD就是我们前面谈到的特殊引用，它指向当前分支的最新commit，它指向的文件其实保存的就是一个commit对象的SHA-1哈希值。

总结一下objects对象的类型及其创建时期：

blob对象：
- 作用：用于存储文件的内容、每个文件版本的内容会被存储为一个独立的 blob 对象、文件名和目录信息不包含在 blob 中，而是由 tree 对象管理。
- 创建时期 ：运行 git add 时
tree对象：
- 作用：用于表示目录结构、包含指向 blob 对象（文件）或其它 tree 对象（子目录）的引用，以及对应的文件名或目录名。
- 创建时期 ：当运行 git commit 时，Git 会为当前的目录结构创建一个 tree 对象，目录结构没变化，复用已有的tree对象。
commit对象：
- 作用：用于记录项目的快照。
  包含以下信息：
  - 指向一个 tree 对象（描述提交时的目录结构）。
  - 提交的元数据（如作者、提交者、日期、提交消息等）。
  - 指向父提交（parent commits），用于构建提交历史。
- 创建时期 ：运行 git commit 时，Git 会创建一个新的 commit 对象，每次提交都会创建一个commit对象即使内容没有变化。
Tag对象：
- 作用：用于为特定的 commit 提供一个永久性的名称或标签。
- 创建时期 ：当您运行 git tag <tag-name> 时，Git 会创建一个轻量级标签。

$!caution$
如果当前提交是项目中的第一个提交（即初始提交），那么它没有父提交。

添加文件--场景二

下面我们创建两个文件，但是只将一个添加到暂存区，然后提交，顺便打印当前的commit对象的内容，看看是否有父commit对象。

在工作区新建两个文件f1.txt、f2.txt：
将f1.txt添加进暂存区并提交：

$!NOTE$
为什么这里只有 1 file changed呢？明明我们创建了两个文件，因为commit只会提交git add后的文件，也就是位于暂存区的文件。

此时我们再打印HEAD指针指向的commit对象的内容：
我们惊奇的发现，此时的commit对象居然多了一行parent，我们打印它：
- 这他喵不就是我们上次提交的commit对象嘛，所以验证了指向父提交（parent commits），用于构建提交历史。

修改文件

git比其他的版本控制器设计的优秀，正在于它跟踪管理的是文件修改，而非文件本身，下面我们验证一下，什么叫修改呢？凡是对文件到增删改都叫修改。

查看当前工作区的目录结构：
我们给file.txt新增一行aaaaa：
将修改后的file.txt添加到暂存区并提交：
我们可以查看file.txt到blob对象是保存的文件内容：
这样可能看不出来，我们继续给file.txt文件增加一行内容，然后git add、git commit：
- blob对象的确是保存的当前版本的文件的内容。
我们可以通过以下命令来查看一下当前工作区文件与暂存区、版本库中的最新一次提交的差异：
bash 复制代码
```
#工作区与暂存区
git diff [file]

#工作区与版本库
git diff HEAD -- [file]
```

如果文件内容中包含了一些非标准的字符（如和 ^@），Git 将其部分识别为二进制数据或特殊编码格式，这个时候我们可以使用-a选项强转。

这一行描述了差异的具体范围：

-1,4：表示旧版本从第 1 行开始，共 4 行。
+1,4：表示新版本从第 1 行开始，共 4 行。
换句话说，Git 在比较两版文件时，发现它们的前 3 行相同，只有第 4 行发生了变化。

版本回退

版本回退的基本操作

查看提交历史：
bash 复制代码
```
git log --oneline
```
使用 git reset ：git reset 是最常用的回退命令之一，它允许您将 HEAD 指针移动到指定的提交，并可以选择是否保留工作目录中的更改。
- 软重置（Soft Reset）：保留工作目录和暂存区中的所有更改。
  bash 复制代码
```
git reset --soft <commit-hash>
```
- 混合重置（Mixed Reset，默认选项）：保留工作目录中的更改，但重置暂存区。
  bash 复制代码
```
git reset --mixed <commit-hash>
```
- 硬重置（Hard Reset）：丢弃工作目录和暂存区中的所有更改，回到指定提交的状态。
  bash 复制代码
```
git reset --hard <commit-hash>
```
  $!caution$
  使用--hard的时候要特别小心，它会丢失未提交的更改。

关于HEAD的说明，回退的版本可以直接使用commit对象的id，也可以这样：

HEAD：表示当前版本。
HEAD^：表示上一个版本。
HEAD^^：表示上上个版本。
HEAD^^^：表示上上上个版本。

使用^不方便也可以使用数字。

HEAD~0 ：表示当前版本。
HEAD~1：表示上一个版本。
HEAD~2：表示上上个版本。

依次类推。

版本回退的演示

首先打印我们提交过的所有版本：
- 左边是commit id，虽然是一部分，但是也可以进行回退。
直接硬重置到第一次提交到版本：
假设我们后悔了，想回退到刚刚的版本，后面更那次提交的commit id即可：

文件又回来了，但是有时候我们可能清屏了，该如何找到commit id呢？可以通过如下指令：

bash 复制代码

git reflog

它记录本地每次提交的commit id：

版本回退的速度是很快的，因为它只是将HEAD指针移动到不同的commit对象。

撤销修改--情况1

有时候我们工作区写了一大堆代码，但是发现写的不怎么行，想要回退到上一个版本，应该怎样做呢？

直观的办法就是直接手动删除，但是这种办法及其容易出错，因为我们可能误删，如果写的代码太多的话。
**git给我们提供了一个命令，让我们的文件可以回退到上一次add或者commit**的版本：
bash 复制代码
```
git checkout -- [file]
```
- --不能省略。
下面我们简单演示下，先查看file.txt文件的内容：
直接回退到上一次add或者commit：

回退成功。

撤销修改--情况2

已经add，但是还没有commit，我们可以先进行版本回退，将暂存区的修改回退到上一次提交，使用：

bash 复制代码

git reset  --mixed [file]

下面来演示下：

修改file.txt的内容，并add：
回退暂存区的内容为上一个版本的：
此时和情况1一样，使用情况1的指令：
bash 复制代码
```
git checkout -- file.txt
```

撤销修改--情况3

已经add了，并且也commit了。

我们可以使用版本回退到硬重置git reset --hard：

bash 复制代码

git reset --hard HEAD^

硬重置到上一个版本。但是这是有条件的，就是你还没有将这次提交的内容推送到远程。对于已推送的,不建议直接硬重置，因为这会破坏远程仓库的历史记录。

下面我们修改file.txt，并将其add并commit：
然后将其工作区、暂存区、版本库全部到回退到上一个提交版本：

删除文件

从工作区中删除文件也是一种修改，我们来研究一下删除文件的情况。

从分支中删除文件file.txt：
此时工作区中确实已经删除了文件file.txt，但假设我们是误删，如何恢复呢，很简单使用撤销修改中的情况1里面的操作即可：
bash 复制代码
```
#将file.txt回退到最近一次add 或者commit
git checkout -- file.txt
```
但是如果是真的不想要这个文件了，那么就需要删干净，因为暂存区和版本库中还存在这个文件：
我们使用git rm命令：git rm 是 Git 中用于从工作目录和索引（即暂存区）中删除文件的命令。它不仅会将文件从当前分支的工作目录中删除，还会将其从暂存区中移除，这意味着在下次提交时，该文件将不再存在于仓库的历史记录中（至少是从这次提交开始的未来历史中）。
- 删除了还要提交，只要提交版本库中才会更新。

分支管理

什么是分支

在 Git 中，分支（branch）是一个核心概念，它允许开发者在同一代码库中并行地开发不同的功能、修复 bug 或进行实验，而不会互相干扰。分支实质上是对提交历史的一个指针或引用，指向某一系列的提交（commits）。

每一个分支，随着每一次的commit都会变长，它就像一条时间线，每一条时间线我们可以看作是一条分支，HEAD指向当前分支：

而这个文件保存的就是最新提交的commit。

分支操作

创建新的分支

bash 复制代码

git branch <branch-name>

<branch-name>：是你想创建的分支的名称。
如果后面不加分支名，就是查看本地所有分支。

切换分支

bash 复制代码

git checkout <branch-name>

$!caution$
注意，没有--。

切换分支的本质就是HEAD指向了不同的分支文件。

合并分支

bash 复制代码

git merge [branch-name]

注意如果你想将某一个分支的内容合并到master主分支上，那么必须要切换到master分支下再合并。

删除分支

合并分支后，说明开发已经完成了，可以删除不需要的分支，想删除某个分支，也必须不能在该分支上。

bash 复制代码

git branch -d [branch-name]

演示上述操作

查看当前的所有分支：
只有一个master，我们新建一个分支dev：
切换分支到dev：
修改内容后（我们是在记事本中修改的），合并分支：
现在合并成功了，删除掉分支dev即可：

上述过程我们画成时间线的图就是这样:

合并冲突

在合并的时候，我们可能遇见两个分支都修改内容的情况，就有可能出现冲突，这个时候我们就需要去手动解决冲突，因为git不清除你要保留那些内容。

下面我们来模拟一下冲突的情况:

首先查看当前的所有分支：
我们创建一个分支dev，创建之后还要切换分支，我们可以使用下面的命令创建并切换：
bash 复制代码
```
git checkout -b dev
```
给file.txt文件增加一行内容 ：aaaaaa on dev，add并提交：
切换到master分支下，也给file.txt文件增加一行内容bbbbbb on master，add并提交：
此时直接在master分支下合并dev分支会出现冲突：
- 出现了冲突，我们需要解决完冲突再提交一次，然后才能合并。
此时我们打开file.txt是这样的：
我们保留dev下的内容，删掉多余的符号：
在master分支上解决完冲突后，然后再提交一次，就解决完冲突合并成功了：
我们使用下面的命令图形化的显示提交情况：
bash 复制代码
```
git log --graph --oneline --all  
```

分支合并的策略--两种模式

快进合并（Fast-Forward Merge） ：当目标分支（如 main）没有新的提交时，Git 会简单地将指针向前移动到被合并分支的最新提交，不会创建新的合并提交。这样有个缺点就是不能看出来当前的提交是合并的还是一直在一个分支上开发的。
三方合并（Three-Way Merge）:当目标分支（如 main）有新的提交时，Git 会创建一个新的合并提交（Merge Commit），以记录两个分支的历史交汇点。

默认情况下是fast-forward模式，但是出现冲突时就是no-ff模式（三方合并），我们可以使用no-ff选项强制使用这种模式。

下面我们来演示一下这两种模式：

Fast-Forward模式演示

创建进入新的分支dev：
给dev分支中的file.txt文件增加一行内容：
切换到master下并合并：
使用git log命令查看图形化的提交线：
检查dev、master分支的最新提交是否是一样的：

Three-Way模式演示

进入dev分支，继续在file.txt上添加一行新内容：
切换回master分支，这次使用no-ff模式合并：
bash 复制代码
```
git merge --no-ff dev
```
- 下面的内容是不是很眼熟，**这不是commit的时候才会出现的内容吗？**说明这种模式下，会重新提交一次。
git log查看提交日志：
检查dev、master分支的最新提交是否是一样的：

不一样说明此次合并，在Three-Way模式下的确是多进行了一次提交。

在dev分支开发时，主分支上出现了bug

有时候我们在dev分支上开发，因为master分支上必须放稳定的代码，它是属于线上环境，必须要保证安全性，而其他分支就一般是日常开发环境，是不稳定的。此时dev上的代码还没add和commit。

在dev分支上开发的代码，如果没有add或commit，在master或者其他分支中是能看到变化的：
- 这是因为，工作区是全局的，工作区是指你当前文件系统中的文件状态，它与具体的分支无关。而暂存区和版本库是分支相关的。只有当你执行git add或git commit中改动才会被记录到当前分支中。
模拟在dev上开发代码然后没有添加到暂存区：
我们要先解决master的bug，dev上的修改不能影响到我们，所以需要先将dev工作区的内容存到一个地方，但是又不能提交因为还没有开发完，.git中确实有这么个区域：

git stash。它允许你将当前工作区的修改（包括暂存区的内容）临时存储起来，而不需要提交这些修改。这样，你可以切换到其他分支（如 master）去修复 Bug，等完成后可以再恢复这些修改继续开发。
我们切换回dev中，将开发了但未开发完的file.txt先存起来：
在.git/refs/目录下，有一个stash文件，这会将工作区和暂存区的所有修改（包括新增、修改和删除的文件）保存到储藏区，并将工作区恢复到最近一次提交的状态。
我们可以使用下面的命令查看储藏区的储藏列表：
bash 复制代码
```
git stash list 
```
然后我们就可以去master中再去开一个分支用于修改bug了。
假设此时我们已经修改完了bug，想要回到dev中继续开发该如何将储藏区的内容拿出来的，使用如下选项：
bash 复制代码
```
git stash pop
```
此时假设已经开发完了再合并，我们建议先在dev上合并master，因为如果遇见冲突，修改的也是dev上的内容，即使修改错了也不影响线上环境，这种方式比较安全：
然后再切换到master上，进行合并：
master与dev进行合并：

强制删除分支

有时候我们在dev分支上开发了一段时间，也提交了突然不想要这些功能了，直接在主分支上使用git branch -d是无法删除的，因为还没有合并：
此时可以使用-D强制将其删除：

理解分布式

Git 是一种分布式版本控制系统（DVCS, Distributed Version Control System），与传统的集中式版本控制系统（如 SVN）相比，它提供了更多的灵活性和控制力。

也就是说同一个git管理的仓库，可以在不同的主机上开发，将来通过网络（局域网）推送、拉取即可。但是这样做有一个不好的点，就是如果两个开发者没有在同一个局域网或者存储最新版本的主机宕机了，岂不是无法拉取内容了。

所以有了中央服务器的诞生，它们部署在公网，可以24小时的访问，帮助开发者维护远程仓库：

GitHub 和 Gitee 都是基于 Git 的代码托管平台，它们提供了远程仓库服务，使得开发者可以方便地在团队中协作开发软件项目。

这样开发时，一个项目的人员只需要通过这个中央服务器，就可以轻松的进行多人协作开发了：

远程仓库相关操作

将远程仓库克隆到本地--HTTPS

当我们新建好一个远程仓库后，如何将其clone到本地呢？
可以看到点克隆是会有多种方法的，这里我们选择HTTPS，复制代码到一个没有git仓库的目录下：
查看我们当前用户对于这个仓库的权限：
bash 复制代码
```
git remote -v
```
- 最前面是仓库的默认名称。

将远程仓库克隆到本地--ssh

与https方式的不同就是多了一步本地生成，并在gitee上配置公钥的过程。SSH 使用公钥和私钥对进行身份验证，而 HTTPS 使用用户名和密码（或个人访问令牌）。

推送操作

我们克隆远程仓库之后，想要将本地的提交推送到远程仓库中，应该怎么做呢？学习如下指令。

bash 复制代码

git push origin <分支名>

下面我们来演示一下：

在本地仓库新建一个文件，add后commit:
直接提交，第一次提交可能有点慢：
查看远端，是否提交成功：

拉取操作

当其它开发者，开发之后将代码提交到了中心仓库gitee/github服务器上，我们想看到相应的内容，就可以去执行拉取操作，拉取操作的作用是从远程仓库获取最新的更改，并将其合并到本地分支中。通过拉取，我们可以确保本地代码与远程仓库保持同步。

我们模拟其它开发者提交新的源码文件，这里我们可以直接在仓库上做更改，但实际中不建议这样做：
执行下面指令进行拉取操作：
bash 复制代码
```
git pull origin master
```
git pull实际是以下两个命令的组合：
- git fetch：从远程仓库下载最新的提交和更改。
- git merge：将下载的内容合并到当前分支。
实际我们进行拉取的时候，也可能出现合并冲突的问题，这个时候也需要手动解决冲突，这样来做
- Git 会标记冲突的文件。打开冲突文件，找到冲突的部分（通常被 <<<<<<< 和 >>>>>>> 包裹）。
- 修改代码以解决冲突。
- 标记冲突已解决并提交：

忽略一些特定后缀的文件

有时候我们的项目中不想提交一些除了源码之外的文件，但是一个文件一个文件的git add还是太麻烦了，我们希望简单点使用git add .一键将所有文件添加到暂存区，但是又不想提交一些特定后缀的文件，这个时候应该怎么办呢？

对此git也给我们提供了解决方案，它里面有一种特点的文件，叫做.gitignore，它位于项目的根目录下，通常需要我们手动创建。

创建.gitignore文件，忽略所有后缀为.so文件：
但是我们想对b.so进行提交，两种做法：
- git add -f [name]：-f表示强制提交。
- 也可以在.gitignore文件中添加!b.so表示不排除b.so文件。
我们创建一个b.so看是否被忽略：
有时候我们发现某个文件被忽略了，但是.gitignore规则太多，想快速查看是哪个规则影响了，可以使用以下命令：
bash 复制代码
```
git check-ignore -v [文件名]
```
比如此时我们想看看，1.so为什么被忽略：
add并commit刚刚新增且没有被忽略的文件，然后推送给远程：
查看远程仓库，确实成功推送了，也是我们预期的结果：

对具有里程碑意义的提交进行打标签操作

打标签

我们可以对某些具有里程碑意义的提交进行打标签，代表这是一次重要的版本。

bash 复制代码

git tag [标签名] [提交哈希]

如果不写提交哈希（也就是commit id），就是默认是对最新一次提交打标签。

我们尝试给最新一次提交打标签：

查看所有标签

下面命令可以查看所有已经存在的标签：

bash 复制代码

git tag

推送标签到远端

下面命令可以将某一个标签推送到远端：

bash 复制代码

git push origin [标签名]

如果你想一键推送所有标签，可以加上下面选项：

bash 复制代码

git push origin --tags

给标签加上描述信息

下面命令可以创建标签并添加上描述信息：

bash 复制代码

git tag -a [标签名] -m [描述信息]

删除标签并推送到远端

有时候我们的标签可能打错了，就需要在远端和本地都删除掉这个标签。

在本地删除标签：
bash 复制代码
```
git tag -d [标签名]
```
将标签的删除，推送至远端：
bash 复制代码
```
git push origin :[标签名]
```