Git 实战场景

四、标签管理

4.1、标签的理解

在使用 Git 进行版本管理时，**标签（Tag）**扮演着非常重要的角色。它其实就是对某次提交（commit）的一个简洁标识，相当于给这次提交起了一个可读、易记的"别名"。比如，当项目发布一个正式版本时，通常会在最后一次提交上打上像 v1.0 这样的标签，以此来标识版本的里程碑。

标签的出现解决了一个非常实际的问题：commit id 过长且难以记忆。虽然 commit id 唯一且精确，但当我们想要回到某个重要版本、修复 bug 或对比差异时，记忆一串哈希值显然不太现实。而标签为我们提供了一个更直观、更友好的方式。

举个例子：

当你需要将项目回退到上一次发布的 v1.0 版本时，只需执行类似：

bash 复制代码

git checkout v1.0

就能瞬间定位到对应的提交。这比手动复制粘贴 commit id 简单得多。

因此，标签不仅是对代码的一次快照，更是项目迭代过程中的一个个"路标"。它让我们能更清晰地管理和回溯不同的版本阶段，尤其是在团队协作或发布流程中，标签的使用显得尤为关键。

4.2、标签的使用

创建标签

想要进行创建标签时，首先需要切换到要进行打标签的分支上，然后进行执行下面的命令

bash 复制代码

git tag + 想要进行打标签的名称

默认进行打标签是打在最新提交的 commit 上的，想要在指定的commit 上进行打标签如何进行呢？

通过下面命令先进行产看指定的提交

bash 复制代码

git log --pretty=oneline --abbrev-commit

然后通过

bash 复制代码

git tag + 想要进行打的标签名称 指定的commit ID

Git还提供可以创建带有说明的标签，用-a指定标签名，-m指定说明文字字，格式为:

cpp 复制代码

git tag -a [name] -m "XXX" [commit_id]

查看标签含义

bash 复制代码

git show + 标签名

删除标签

bash 复制代码

git tag -d + 标签名

推送本地标签到远程仓库

推送指定的标签到远程仓库

bash 复制代码

git push origin + 标签名称

推送所有的标签到远程仓库

bash 复制代码

git push origin --tags

进行删除推动送到远端的标签

删除推送到远端的标签一般分为两步

1. 先进行删除本地的标签

直接执行上面介绍过的删除标签的命令。

2. 将本地的标签进行推送到远程仓库

bash 复制代码

git push origin :+标签名称

五、多人协作

5.1、在同一分支下进行多人协作开发

1.在gitee上进行创建分支（dev分支）

2.查看远程仓库的分支

bash 复制代码

git branch -r

如果没有看到在远程仓库上新建的分支，进行执行pull命令进行拉取。

3.在本地进行创建分支并且和远端的分支进行建立联系

bash 复制代码

git checkout -b dev origin/dev

为了进行模拟多人协作开发，即在Linux下进行创建了本地分支并且进行连接到远程分支上，又在window 下进行创建本地分支模拟协同开发

Linux下进行模拟一个开发人员

widow 下进行模拟一个开发人员

在同一分支下进行开发的步骤如上图所演示的

目的：我们开发者人员首先需要在dev分支上进行开发后在进行合并到远端的maser分支上。

首先每个开发者都需要先进行克隆远端仓库（前提条件），并且在远端仓库进行创建一个dev分支。

然后进行创建分支并且进行连接远端仓库

bash 复制代码

git checkout -b dev origin/dev

然后每个开发者都进行添加并提交对于代码文件的修改，并推送到远端仓库中（这个过程是有很大概率是冲突的，需要进行解决冲突）

最后就是将dev分支进行合并到master总分支上

有两种方如下：

第一种是在远程仓库中进行填写合并表单的形式（推荐）

通过填写合并分支的表单，然后通过审查人员（在企业中一般是leader）的审查后，没有问题的话直接就将dev分支进行了向master进行合并。

第二种方式就是通过命令行的形式

首先需要在本地master 分支下进行pull拉取一下。

在参与的7开发者的本地进行合并master分支（这个过程是可能有冲突的），防止在mater上进行解决冲突出现BUG 问题。

最后在重新切换到master分支下进行合并dev分支。

总结一下，其实在同一分支下进行多人协作的流程是这样：

首先，试图用git push 进行推送自己的修改
如果推送失败，则可能是远程仓库相对于本地仓库更新，需要执行 git pull 试图合并
如果合并有冲突，需要进行解决冲突
然后进行git push 推送到远程仓库
最后进行删除分支

注意：其实多人在同一分支下进行协作开发的场景是很少的，可以说是几乎不存在 ，因为多人在同一分支下进行开发，基本进行git pull 进行合并的时候都是由冲突的，而且进行解决冲突是一件非常麻烦的事情，我们通常都是是使用在不同分支下进行多人协作开发。

5.2、在不同分支下进行多人协作开发

一种方式进行实现（利用可视化的方式在远程进行创建分支）

1.在远程仓库进行新建两个分支 feature-1和feature-2

2.不同的开发者在本地进行创建分支并且和远程分支进行建立联系

3.分别进行向远程分支进行添加推送

4.将远程分支中的内容进行合并到主分支中（合并逻辑在下面进行演示）

另一种方式进行实现（全部进行使用命令行的形式）

1.不同的开发者在本地进项创建分支和文件进行提交

2.然后推送到远端仓库

bash 复制代码

git push origin 想要进行推送到远端仓库的名称

在进行向远端仓库进行推送的时候，由于我们是还没有进行创建远端仓库的，直接进行执行push命令是不能进行成功push的，在进行执行push的时候需要进行执行上述命令，代表创建远程仓库并进行将本地仓库进行推送到该远端仓库。

3.另一个开发者也是这样的操作

在进行执行合并分支的逻辑之前，在不同的分支下进行多人协作开发是没有经历到冲突的。

假如说我们的小伙伴由于每天进行加班肝的太严重了，住进了医院，但是他的开发还没有完成，我们需要进行从本地仓库中进行将他的分支进行拉取下来，替他进行开发维持项目的进度

1.想要对他的代码进行开发，首先要进行找到小伙伴的代码
bash 复制代码
git push
这里进行拉取既可以进行拉取本分支的内容（建立联系），还可以进行拉取仓库中的内容

2.然后在本地进行创建分支并进行建立联系
bash 复制代码
git checkout -b 分支名 origin/远程仓库分支名
3.将开发的代码进行提交并推送到远程仓库中

执行git三板斧的操作

小伙伴康复回归，重新进行开发

将本地分支和远程分支进行建立联系

bash 复制代码

git branch --set-upstream-to=origin/远程分支 本地分支

然后进行拉取

bash 复制代码

git pull

4.进行合并分支

将上面步骤直接进行总结成：

切换至 master分支, pull ⼀下，保证本地的master是最新内容。（合并前这么做是⼀个好习惯）
切换⾄ feature-1 分支, 合并 master 分支，这么做是因为如果有冲突，可以在feature-1分支上进行处理，⽽不是在在master上解决冲突。（这么做是⼀个好习惯）
由于feature-1分支已经merge进来了新内容，为了保证远程分支最新，所以最好push⼀下。
要 push 的另⼀个原因是因为在实际的开发中，master的merge操作⼀般不是由我们自己在本地进其他⼈员或某些平台merge时，操作的肯定是远程分支，所以就要保证远程分支的最新。如果 merge 出现冲突，不要忘记需要commit才可以push!!
切换至 master 分支，合并feature-1分支
将master分支进行推至远端
最后将分支进行删除

5.3、解决gitbranch-a 进行打印已经被删除的远程分支

先执行下面命令进行查看远端分支

bash 复制代码

git remote show origin

进行在本地也进行删除远端被删除的分支

bash 复制代码

git remove prune origin

六、企业级开发模型

6.1、企业级开发流程

一般流程

在企业中我们要进行上线一个软件，要经历以下历程开发 → 测试 → 发布上线，其中开发又包括规划、编码、构建，发布包括：发布、部署和维护。

其中

开发团队 : 写写写，根据业务需求进行实现
测试团队：测测测，对开发人员的代码进行测试
运维团队：稳稳稳，维持服务器的稳定

通过上面的介绍，可以看到开发团队和运维团队是存在利益冲突的

DevOps：打破"开发"和"运维"的隔阂

在传统的 IT 组织里，开发团队 (Dev) 和 运维团队 (Ops) 常常存在不同的诉求和目标。

开发这边，尤其是敏捷团队，更看重快速的交付和频繁的变化；而运维那边，最关心的是线上环境的稳定。

这两边如果各做各的，往往就会出现"部门墙"------开发想要快速上线新功能，运维却得控制风险和变更。

结果呢？大家都不开心，IT 的整体价值也打了折扣。

为了解决这个矛盾，DevOps 这个概念就应运而生了。

DevOps 是 Development（开发） 和 Operations（运维） 的组合词，它不仅仅是一个工具或者流程，而是一种文化、运动、一套最佳实践。

核心目的很简单：让开发和运维能更好地沟通、合作，尽可能多地通过自动化来打通从开发到上线的流程，让软件的交付速度更快、发布更可靠。

从大流程来看，DevOps 贯穿了：
计划 → 编码 → 构建 → 测试 → 预发布 → 发布 → 运维 → 监控

这套流程真正做好的话，能显著加快我们的软件交付，减少线上事故的风险，提升用户体验。

DevOps 跟咱们的 Git 有啥关系？

说了这么多，DevOps 到底和咱们平时学的 Git 有啥关系？

其实非常直接：

软件的每一次迭代，本质上就是在改动代码，代码管理 就成了核心问题。

不管是做自动化测试、自动化部署，还是回滚 Bug 修复，代码版本管理都离不开。

而 Git，作为当前最流行的分布式版本控制系统，简直就是 DevOps 流程里的"血液"。

它让我们能够在多次迭代、多版本并行的情况下，依然有条不紊地管理代码，也给后续的自动化流程（比如 CI/CD）打下了最坚实的基础。

所以，Git 不光是咱们开发过程中"个人必备工具"，更是整个 DevOps 体系里不可或缺的基石。

有了它，咱们的迭代才能真正快又稳，才能让 DevOps 真正发挥它的威力！

6.2、系统开发环境

在咱们日常做系统开发的时候，环境管理是绕不开的一块。平时我们会遇到好几种不同的环境，每个都有自己的用处，下面给大家聊一聊：

开发环境

就是我们日常撸代码的环境。一般来说，开发环境的容错和提示都开得很全，各种错误信息、调试工具都开着，目的就是让开发更顺畅，出错能立马定位。

测试环境

测试环境的作用可不小。咱们写好的代码不能直接上线吧？必须在测试环境先跑一跑，确保基本没啥问题。测试环境就像是代码上线前的"体检中心"。

预发布环境

别小看了它！很多公司都会单独搞个预发布（或者叫灰度/仿真）环境，尽量模拟生产环境的配置，提前找出线上可能出现的坑。它一般是和生产环境非常像，但又独立出来的，专门用来让咱们发版更安心。

生产环境

这个不用多说，就是用户能直接用到的"正式版"环境，所有线上跑的服务都在这。对用户来说，看到的都是生产环境的服务。

从大的流程上来说，咱们的项目一般会走：
开发 → 测试 → 上线 。

如果公司规模再大点，可能还有更多：比如仿真环境、灰度环境、多个版本的测试环境......都为了让上线更靠谱。

重点来了

一个项目从想法到成功，测试是绕不开的。完善的测试体系能让我们在上线前解决绝大部分致命 Bug，虽然测试不直接产生收益，但它才是产品质量的最后一道防线。也能反映一个团队、一个公司的成熟度。别看它不"显眼"，能不能搞好测试，往往决定了项目能不能成！

6.3、Git分支设计模型

在前面聊到的多环境（开发、测试、预发布、生产）和 DevOps 流程中，代码管理 是非常核心的一块。而对于代码管理，Git 是我们的得力助手。

但是，光有 Git 还不够。要让多人协作高效、避免踩坑，就得有一套合理的 分支模型 。下面分享一个企业中常用的 Git 分支模型，通常也被称为 Git Flow。

不同岗位对分支有不同的需求：

开发人员 自然是在"开发分支"上写新代码；

测试人员 则更想要一个单独的分支，能随时拿到他们需要测试的版本。

所以，为了让大家各司其职又能高效协作，咱们就得好好设计一个合适的 Git 分支模型。

常用分支及适用环境

分支	名称	适用环境
master	主分支	生产环境
release	预发布分支	预发布/测试环境
develop	开发分支	开发环境
feature	需求开发分支	本地开发
hotfix	紧急修复分支	本地修复