四、标签管理

4.1、标签的理解

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

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

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

git checkout v1.0

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

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

4.2、标签的使用

创建标签

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

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

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

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

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

然后通过

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

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

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

查看标签含义

git show + 标签名

删除标签

git tag -d + 标签名

推送本地标签到远程仓库

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

git push origin + 标签名称

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

git push origin --tags

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

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

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

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

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

git push origin :+标签名称

五、多人协作

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

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

2.查看远程仓库的分支

git branch -r

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

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

git checkout -b dev origin/dev

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

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

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

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

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

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

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

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.然后推送到远端仓库

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

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

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

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

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

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

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

执行git三板斧的操作

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

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

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

然后进行拉取

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 进行打印已经被删除的远程分支

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

git remote show origin

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

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	紧急修复分支	本地修复

这套分支和环境的搭配只是常见的一种实践，不是“放之四海而皆准”的真理。每个公司、每个团队都可能有不同的调整。

各分支的职责

master 分支

只读、唯一，直接关联到线上生产环境。
一般只从 release 分支合并而来，所有代码都非常稳定。
发布上线后，要打上 tag（标签）来方便追溯。
禁止直接在 master 分支上开发。

release 分支

预发布分支，给测试人员用来做全面测试。
基于 develop 分支创建，合并了所有 feature 分支的内容。
命名方式：release/版本号_时间戳，比如 release/v1.2_20250610。
这个分支是临时的，等发布完成后可选择删除。

develop 分支

统一的开发分支，永远保持最新的可用代码。
所有 feature 分支开发完成后都要合到这里，不能直接在上面开发（除非是特别小的修改）。
也是后续发布 release 分支的基础。

feature 分支

针对具体新需求或功能点的开发分支。
命名方式：feature/功能_作者_时间，比如 feature/login_ys_20250610。
开发完合到 develop 分支，功能上线后可删除。

hotfix 分支

用于线上版本的紧急修复（补丁）。
直接基于 master 分支创建。
命名方式：hotfix/问题_作者_时间，比如 hotfix/crashfix_ys_20250610。
修复完成后，要合到 master 和 develop 两个分支，并推送远程，修复上线后即可删除。

Git Flow 模型：适用不等于万能

其实上面介绍的就是很多企业常用的 Git Flow 分支管理模型。它能很好地满足多环境、多人协作的需要，让每个角色都能在各自的分支上做事，流程清晰可控。
不过，Git Flow 也并非“唯一解”。如果你所在的团队是做 持续交付 的，或者更想简化流程，也可以尝试更轻量的模型，比如基于主干的开发模式（Trunk-Based Development）、使用特性标志（Feature Flags）等等。

关键是：
不要盲目追随别人的分支模型
要根据自己团队和项目的情况，去选适合自己的方式

因为，分支模型最终的目的，就是让咱们的软件开发和协作更高效、更安全。工具、流程再好，也得服务于人的需求，才算真正有价值。

Git flow模型并不是所有的公司都进行使用的很多公司使用自己独立开发的模型，例如阿里的飞流flow分支模型，不同的团队的需求不同进行选择的分支模型就不同。

七、企业级项目管理实战

创建模型的时候进行选择master feature分支

企业名称可随意填写⼀个测试名称，只要能通过即可。注意，多⼈协作开发，需要将多⼈账号拉⼊⼀个企业下才⾏。如何添加成员后⾯会跟⼤家讲解。

创建项目

创建仓库

注：创建的仓库可以关联到某个项⽬中被管理

添加成员

1. 添加企业成员

申请后需要审批人员进行同意方可加入。

2.添加项目成员

3.添加仓库成员

开发场景-基于git flow模型的实践

新需求的加入

现有一个订单管理的新需求进行加入，首先可以基于 develop 分支创建⼀个 feature/hyb_order_20231012 分⽀。

1. 需求在 feature/hyb_order_20231012 分⽀开发完毕，这时研发⼈员可以将代码合并到 develop 分支，将其部署在开发环境的服务器中，方便开发⼈员进行测试和调试。

a. 开发者在 feature 分支下发起请求评审

b.审查员进行审核代码

c.审查通过，进行合并分支

d.合并成功进行查看结果

2.在develop 下开发人员自测通过后，先确定下 develop 不存在未测试完毕的需求，然后研发人员可基于 develop 分支创建⼀个 release/xxx 分支出来，可交由测试⼈员进行测试。

3.测试⼈员测试 release 通过后（包含测试环境和预发布环境的测试），就可将代码合并入 master。

4. 测试⼈员在 master (正式环境) 测试通过后，便可删除 feature/xxx 分支。

修复测试环境 Bug

当 develop 分支的测试环境出现 Bug，建议大家直接在 feature 分支 上进行修复。

修复后的提测、上线流程与新需求的加入流程一致，确保在开发阶段就保持分支的健康和可控性。

修复预发布环境 Bug

当 release 分支的测试环境出现 Bug，修复步骤如下：

回归检查：先检查 develop 分支 是否也存在该 Bug。
修复流程：

如果 develop 分支 也有该问题，修复流程与测试环境 Bug 修复一致；
如果 develop 分支 没有该问题，这种情况一般比较少，往往是数据兼容问题或者环境配置问题，需要单独定位和解决。

修复正式环境 Bug

当 master 分支的正式环境出现 Bug，修复步骤如下：

回归检查：先检查 release 分支 和 develop 分支 是否同样存在该问题。
修复流程：

如果存在，修复流程与测试环境 Bug 修复流程一致；
如果不存在，这种情况也比较少，大多是数据兼容问题或者环境配置问题，需要重点排查。

紧急修复正式环境 Bug

有时候，Bug 在测试环节未能发现，但在正式上线一段时间后才出现，属于紧急修复 Bug。此时，流程如下：

建议先验证下 预发布环境，即使有些企业在面对紧急修复时跳过了这一步。
基于 master 分支创建一个 hotfix/xxx 分支。
修复完成后，发布到 master 进行验证。
验证完毕后，将 master 代码合并回 develop 分支，并删除临时的 hotfix/xxx 分支。