Git使用【下】

cefler

已于 2023-10-03 10:34:00 修改

阅读量633

点赞数

分类专栏： Linux 文章标签： git 企业级开发git linux 多人开发

于 2023-10-02 23:54:30 首次发布

本文链接：https://blog.csdn.net/cefler/article/details/133499412

版权

Linux 专栏收录该内容

42 篇文章 0 订阅

订阅专栏

在这里插入图片描述

欢迎来到Cefler的博客😁
🕌博客主页：那个传说中的man的主页
🏠个人专栏：题目解析
🌎推荐文章：题目大解析（3）

在这里插入图片描述

👉🏻标签管理

理解标签

标签 tag ，可以简单的理解为是对某次 commit 的⼀个标识，相当于起了⼀个别名。例如，在项⽬发布某个版本的时候，针对最后⼀次 commit 起⼀个 v1.0 这样的标签来标识⾥程碑的意义。
这有什么⽤呢？相较于难以记住的 commit id ， tag 很好的解决这个问题，因为 tag ⼀定要给⼀个让⼈容易记住，且有意义的名字。当我们需要回退到某个重要版本时，直接使⽤标签就能很快定位到。
在这里插入图片描述

标签运用

在 Git 中，可以使用以下命令来创建、查看和管理标签：

创建标签：
- 轻量标签（Lightweight Tag）：只是一个特定提交的引用，没有额外的信息。
```
git tag <tag-name>
//如果tag后没有指出commit id，则默认给最新的commit id打上标签
```
- 附注标签（Annotated Tag）：包含额外的信息，如作者、日期、说明等。
```
git tag -a <tag-name> -m "Tag message"
```
查看标签：
- 查看所有标签：
```
git tag
```
- 查看指定标签的详细信息：
```
git show <tag-name>
```
切换到标签：
- 可以切换到某个标签对应的提交状态，但是不能在标签上进行修改。
```
git checkout <tag-name>
```

删除标签：

删除本地标签：
```
git tag -d <tag-name>
```
删除远程标签：
```
git push origin --delete <tag-name>
```

共享标签：
- 将本地标签共享到远程仓库：
```
git push origin <tag-name>
```
- 将所有本地标签一次性共享到远程仓库：
```
git push origin --tags
```

需要注意的是，标签默认只会推送到远程仓库的本地副本。如果想将标签共享给其他人，需要使用推送命令将标签推送到远程仓库。

另外，还可以使用 -l 选项来过滤标签，使用 --contains 来查找包含某个提交的标签，以及使用 --list 来列出符合指定模式的标签等。

综上所述，以上是一些常用的标签管理命令。在实际使用中，可以根据项目需要和个人习惯来灵活运用这些命令。

👉🏻多人协作一

在这里插入图片描述
✥此次多人协作目标：

这里如果我们单独完成这一项任务，开发者1的开发环境在我们买的云服务器上，
开发者2的开发环境在本地windows上。

准备工作

✢：先在远程仓库中创建分支（这个操作可以在gitee上完成，也可以在本地完成）
我们直接用前者方法完成
在这里插入图片描述
此时远程仓库和本地仓库的情况如下：

git branch -r //可以在本地查看远程仓库分支

在这里插入图片描述
此时我们想让本地仓库同步远程仓库中的dev分支。
我们可以用git pull 拉取远程仓库

开发者1的准备工作已经好了。

此时我们要在window下为开发者2进行部署准备工作。

在这里插入图片描述

此时当前文件夹就会clone远程仓库了

远程仓库和本地仓库的情况如下：
在这里插入图片描述

协作开发

在这里插入图片描述
这里我们要在本地开发，肯定不能在master分支上进行开发，所以要再创建一个分支dev。
这里我们做了一个操作：将分支dev和origin/dev连接起来了。
用命令可查看分支连接关系

git branch -vv

☃️这里我们补充一下本地仓库与远程仓库连接的知识点。

将本地仓库与远程仓库连接起来有以下好处：

备份和恢复：通过将本地仓库推送到远程仓库，可以实现代码的备份。如果本地仓库发生损坏或意外删除，可以从远程仓库中恢复代码。
协作开发：多人协作开发时，通过连接远程仓库，可以方便地共享代码，并进行版本控制和合并工作。团队成员可以通过拉取（pull）远程仓库的代码，进行修改和提交，并通过推送（push）更新到远程仓库。
跨多个工作环境访问代码：通过连接远程仓库，可以在不同的工作环境（如多台计算机或团队成员之间）之间访问相同的代码库，方便查看和修改代码。

要建立本地仓库和远程仓库的连接，需要进行以下步骤：

创建远程仓库：在远程代码托管平台（如GitHub、GitLab等）上创建一个仓库，并获取远程仓库的 URL。
将本地仓库与远程仓库关联：
- 如果在本地仓库中没有关联远程仓库，可以使用命令 git remote add origin <remote-url> 将本地仓库与远程仓库关联起来。其中，origin 是远程仓库的别名，可以自定义。
- 如果已经关联了其他远程仓库，可以使用命令 git remote set-url origin <remote-url> 来修改远程仓库的 URL。
推送和拉取代码：
- 推送代码：使用 git push origin <branch-name> 命令将本地分支的代码推送到远程仓库。例如，git push origin master 将本地 master 分支的代码推送到远程仓库中。
- 拉取代码：使用 git pull origin <branch-name> 命令从远程仓库拉取最新的代码到本地仓库和工作目录中。例如，git pull origin master 从远程仓库的 master 分支拉取最新代码。

⭐️连接建立后，可以使用简短的命令进行操作，如 git push 和 git pull，它们会默认将代码推送到和拉取自动与当前分支关联的远程仓库和分支上。

现在我们在dev分支下进行在file.txt中添加"aaa"内容，并add,commit
在这里插入图片描述
此时因为我们已经建立连接，所以可以直接进行简短的命令git push

同理开发者2进行同样操作。

创建一个分支dev。

在这里插入图片描述
此时再add、commit、push该内容

但是在push这里出错了，原因是出现了合并冲突

所以解决办法：先用git pull将远程仓库的内容拉取下来，然后在本地分支上进行手动修改代码再push提交
在这里插入图片描述

git branch --set-upstream-to=origin/<branch> dev

在这里插入图片描述

在这里插入图片描述

最后我们再进行push就大功告成了。

将内容合并进master

这里我们有两种方法;
1.使用pull request文件，将dev分支放入申请单中，若管理员审批通过，即可合并到master分支中（建议使用）
2.本地操作：先将dev分支merge进本地master分支，最后再将master push即可

但我们这里先使用方法2来演示
这里操作顺序如下：👇🏻
1.先git pull同步远程仓库，有人会疑问会什么这里要先同步远程仓库？
实际上，在开发中，远程仓库的master是不断在更新的，为了保证我们的master状态是最新的，我们要同步远程仓库使其先达到最新状态

2.在dev分支上merge master,有合并冲突在dev分支上解决，不影响master(我们之前说过)

3.最后在master分支上merge dev,最后push 到远程仓库。

在这里插入图片描述
此时，我们的多人协作就此完成！

🌈 总结一下：
在同⼀分⽀下进⾏多⼈协作的⼯作模式通常是这样
• 首先，可以试图⽤ git push origin branch-name 推送⾃⼰的修改；
• 如果推送失败，则因为远程分⽀⽐你的本地更新，需要先⽤ git pull 试图合并；
• 如果合并有冲突，则解决冲突，并在本地提交；
• 没有冲突或者解决掉冲突后，再⽤git push origin branch-name推送就能成功！
• 功能开发完毕，将分⽀ merge 进 master，最后删除分⽀。

👉🏻多人协作二

✥此次多人协作目标：
在这里插入图片描述

协作开发（1）

开发者1🫡
在这里插入图片描述
开发者2🫡

在这里插入图片描述

这里我们发现不论是开发者1还是开发者2push后，居然都没有出现合并冲突。

原因是因为两个开发者此时都处于各自私有的分支上开发，彼此分支互不影响，所以是不会有合并冲突的

此时出现了一个小意外，开发者2生病了🤧🤧，需要开发者1到feature-2分支上进行帮忙开发，此时情况来到了我们刚刚多人开发一中的情况
在这里插入图片描述
原因是git pull分两种情况：

拉取分支内容：需要连接
拉取仓库内容：不需要连接
我们刚刚拉取的feature-2分支信息属于仓库内容。所以不需要连接

在这里插入图片描述
此时开发者2痊愈了，回到岗位上，更新仓库后即可看到开发者1给他写的代码。

将内容合并进master

在这里插入图片描述

此时再合并feature-1
但需注意：

所以得先在feature-1合并master

此时我们在在gitee中创建一个pull request库接收合并就可以了。

至此已大功告成！

👉🏻远程分⽀删除后，本地 git branch -a 依然能看到的解决办法

在这里插入图片描述

git remote prune

在这里插入图片描述

👉🏻企业级开发模型

企业级开发流程

我们知道，⼀个软件从零开始到最终交付，⼤概包括以下⼏个阶段：规划、编码、构建、测试、发
布、部署和维护。
最初，程序⽐较简单，⼯作量不⼤，程序员⼀个⼈可以完成所有阶段的⼯作。但随着软件产业的⽇益
发展壮⼤，软件的规模也在逐渐变得庞⼤。软件的复杂度不断攀升，⼀个⼈已经hold不住了，就开始
出现了精细化分⼯。如下图所示：
在这里插入图片描述
但在传统的 IT 组织下，开发团队(Dev)和运维团队(Ops)之间诉求不同：

• 开发团队(尤其是敏捷团队)追求变化
• 运维团队追求稳定

双⽅往往存在利益的冲突。⽐如，精益和敏捷的团队把持续交付作为⽬标，⽽运维团队则为了线上的
稳定⽽强调变更控制。部⻔墙由此建⽴起来,这当然不利于 IT 价值的最⼤化。
为了弥合开发和运维之间的鸿沟，需要在⽂化、⼯具和实践⽅⾯的系列变⾰⸺DevOps正式登上舞
台。

DevOps（Development和Operations的组合词）是⼀种重视“软件开发⼈员（Dev）”和“IT运维技
术⼈员（Ops）”之间沟通合作的⽂化、运动或惯例。透过⾃动化“软件交付”和“架构变更”的流
程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。在DevOps的软件开发过程包含计
划、编码、构建、测试、预发布、发布、运维、监控，由此可⻅DevOps的强⼤。

想更多了解DevOps参考👉🏻：DevOps到底是什么意思？

讲了这么多，这个故事到底和我们课程的主题 Git 有什么关系呢？
举⼀个很简单的例⼦就能说明这个问题。⼀个软件的迭代，在我们开发⼈员看来，说⽩了就是对代码
进⾏迭代，那么就需要对代码进⾏管理。如何管理我们的代码呢，那不就是 Git（分布式版本控制系
统）！所以 Git 对于我们开发⼈员来说其重要性就不言而喻了。

系统开发环境

对于开发⼈员来说，在系统开发过程中最常⽤的⼏个环境必须要了解⼀下：

开发环境：开发环境是程序猿们专⻔⽤于⽇常开发的服务器。为了开发调试⽅便，⼀般打开全部错
误报告和测试⼯具，是最基础的环境。
测试环境：⼀个程序在测试环境⼯作不正常，那么肯定不能把它发布到⽣产机上。该环境是开发环
境到⽣产环境的过渡环境。
预发布环境：该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测⽽设⽴的⼀套环境。
其配置等基本和⽣产环境⼀致，⽬的是能让我们发正式环境时更有把握！所以预发布环境是你的产
品质量最后⼀道防线，因为下⼀步你的项⽬就要上线了。要注意预发布环境服务器不在线上集成服
务器范围之内，为单独的⼀些机器。
⽣产环境：是指正式提供对外服务的线上环境，例如我们⽬前在移动端或PC端能访问到的APP都是
⽣产环境。
这⼏个环境也可以说是系统开发的三个重要阶段：开发->测试->上线。⼀张图总结：

对于规模稍微⼤点的公司来说，可不⽌这么⼏个环境，⽐如项⽬正式上线前还存在仿真/灰度环境，再
⽐如还存在多套测试环境，以满⾜不同版本上线前测试的需要。

灰度环境是一种软件发布的策略，用于在实际生产环境之前进行有限的、部分用户的测试和验证。它是介于开发环境和生产环境之间的一个中间环境，可以让开发人员和测试人员在真实用户环境下验证和评估新功能或更新的性能和稳定性，以及收集用户反馈进行改进。灰度环境通过将新功能或更新逐渐应用于一小部分用户，以实现控制风险并确保整体系统稳定。

⼀个项⽬的开始从设计开始，⽽⼀个项⽬的成功则从测试开始。⼀套良好的测试体系可以将系统中绝
⼤部分的致命Bug 解决在系统上线之前。测试系统的完善和成熟也是衡量⼀个软件企业整体⽔平的重
要指标之⼀，测试往往被忽视，因为它对可以的隐性、对软件开发企业不产⽣直接的效益，但是它却
是软件质量的最终保障，乃⾄项⽬能否成功的重要因素！

git 分支设计模型

环境有了概念后，那么对于开发⼈员来说，⼀般会针对不同的环境来设计分⽀，例如：

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

Git 分支模型中常用的分支包括以下五种：

master 分支：主分支，也是最稳定的分支，用于发布产品或者版本，该分⽀为只读且唯⼀分⽀。通常只有在完成新功能开发或者进行 hotfix 后，⼀般由合并release 分⽀得到。
develop 分支：开发分支，用于进行日常开发的分支，只读且唯⼀分⽀。通常是从 master 分支创建而来，并在开发一个新功能或者一系列功能时持续更新。
feature 分支：特性分支，用于开发具体的新功能。在从 develop 分支创建后，我们就可以在该分支上进行新功能开发，开发完成后再将该分支合并回 develop 分支。
release 分支：发布分支，用于发布新版本或者产品。当所有的功能都已完成开发并通过测试后，从 develop 分支创建一个 release 分支，该分支如果需要进行 bug 修复，则会在该分支上进行，完成后再合并到主分支和开发分支上，release 分⽀属于临时分⽀，产品上线后可选删除。
hotfix 分支：紧急修复分支，用于快速修复生产环境的 bug。当主分支上出现紧急问题需要快速修复时，我们会从主分支上创建一个 hotfix 分支，完成修复后再合并回主分支和开发分支上。