🔥承渊政道： 个人主页
❄️个人专栏: 《C语言基础语法知识》 《数据结构与算法》
✨逆境不吐心中苦,顺境不忘来时路! 🎬 博主简介:
引言:在深入剖析Git的原理和使用(上)中,我们已经搭建起Git的基础认知框架---从Git的诞生背景、核心设计理念出发,掌握了初始化仓库、提交版本、查看日志、简单分支创建与切换等基础操作,也初步触及了Git"分布式版本控制"的核心优势.但这些表层操作,仅仅是Git强大功能的冰山一角:当我们面对多人协作中的代码冲突、复杂分支的合并与管理、误操作后的版本回滚难题,或是想弄明白"Git如何高效存储版本数据""远程仓库与本地仓库的同步逻辑是什么"时,仅靠基础操作往往无从下手,背后的核心原理才是解决这些问题的关键.本篇将聚焦远程仓库的进阶协作(拉取、推送、复刻、协同开发流程).将坚持"原理+实操"结合的思路,真正发挥Git在版本控制、团队协作中的核心价值,为后续的高效开发、规模化协作筑牢基础.接下来,就让我们开启Git原理与进阶使用的深度探索之旅.那么它们到底又有哪些方面的知识是需要学习和掌握的呢?废话不多说,带着这些疑问,下面跟着小编的节奏🎵一起学习吧！
目录
- 1.远程操作
- 2.标签管理
- 3.Git实战场景---多⼈协作⼀
- 4.Git实战场景---多⼈协作二
- [5.解决branch -a打印已被删除的远程分支的办法](#5.解决branch -a打印已被删除的远程分支的办法)
- 6.企业级开发模型
-
- 6.1企业级开发流程
- 6.2系统开发环境
- 6.3Git分⽀设计规范
- 6.4企业级项⽬管理实战---准备⼯作
- [6.5开发场景---基于git flow模型的实践](#6.5开发场景—基于git flow模型的实践)
1.远程操作
1.1理解分布式版本控制系统
我们⽬前所说的所有内容(⼯作区,暂存区,版本库等等),都是在本地!也就是在你的笔记本或者计算机上.⽽我们的Git 其实是分布式版本控制系统!什么意思呢?可以简单理解为,我们每个⼈的电脑上都是⼀个完整的版本库,这样你⼯作的时候,就不需要联⽹了,因为版本库就在你⾃⼰的电脑上.既然每个⼈电脑上都有⼀个完整的版本库,那多个⼈如何协作呢?⽐⽅说你在⾃⼰电脑上改了⽂件A,你的同事也在他的电脑上改了⽂件A,这时,你们俩之间只需把各⾃的修改推送给对⽅,就可以互相看到对⽅的修改了.
分布式版本控制系统的安全性要⾼很多,因为每个⼈电脑⾥都有完整的版本库,某⼀个⼈的电脑坏掉了不要紧,随便从其他⼈那⾥复制⼀个就可以了.在实际使⽤分布式版本控制系统的时候,其实很少在两⼈之间的电脑上推送版本库的修改,因为可能你们俩不在⼀个局域⽹内,两台电脑互相访问不了.也可能今天你的同事病了,他的电脑压根没有开机.因此,分布式版本控制系统通常也有⼀台充当"中央服务器"的电脑,但这个服务器的作⽤仅仅是⽤来⽅便"交换"⼤家的修改,没有它⼤家也⼀样⼲活,只是交换修改不⽅便⽽已.有了这个"中央服务器"的电脑,这样就不怕本地出现什么故障了(⽐如运⽓差,硬盘坏了,上⾯的所有东西全部丢失,包括git的所有内容)
1.2远程仓库
Git是分布式版本控制系统,同⼀个Git 仓库,可以分布到不同的机器上.怎么分布呢?最早,肯定只有⼀台机器有⼀个原始版本库,此后,别的机器可以 "克隆" 这个原始版本库,⽽且每台机器的版本库其实都是⼀样的,并没有主次之分.你肯定会想,⾄少需要两台机器才能玩远程库不是?但是我只有⼀台电脑,怎么玩?其实⼀台电脑上也是可以克隆多个版本库的,只要不在同⼀个⽬录下.不过,现实⽣活中是不会有⼈这么傻的在⼀台电脑上搞⼏个远程库玩,因为⼀台电脑上搞⼏个远程库完全没有意义,⽽且硬盘挂了会导致所有库都挂掉,所以我也不告诉你在⼀台电脑上怎么克隆多个仓库.实际情况往往是这样,找⼀台电脑充当服务器的⻆⾊,每天24⼩时开机,其他每个⼈都从这个"服务器"仓库克隆⼀份到⾃⼰的电脑上,并且各⾃把各⾃的提交推送到服务器仓库⾥,也从服务器仓库中拉取别⼈的提交.完全可以⾃⼰搭建⼀台运⾏Git 的服务器,不过现阶段,为了学 Git 先搭个服务器绝对是⼩题⼤作.好在这个世界上有个叫
GitHub的神奇的⽹站,从名字就可以看出,这个⽹站就是提供 Git 仓库托管服务的,所以,只要注册⼀个GitHub账号,就可以免费获得Git 远程仓库Github 是国外的⽹站,国内访问的速度⽐较慢,小编采⽤gitee(码云)来托管代码.下面,我们从零开始,使⽤⼀下gitee(码云)远程仓库.
1.3新建远程仓库
新建远程项⽬仓库
填写基本信息
创建成功
创建成功后,我们可以对远程仓库进⾏⼀个基本的设置:开源or私有
从创建好的远程仓库中我们便能看到,之前在本地学习过的分⽀,也存在于远程仓库中并被管理起来了.刚创建的仓库有且只有⼀个默认的master分⽀.
1.4克隆远程仓库---HTTPS/SSH协议
克隆/下载远端仓库到本地,需要使⽤
git clone命令,后⾯跟上我们的远端仓库的链接,远端仓库的链接可以从仓库中找到:选择"克隆/下载"获取远程仓库链接:
SSH协议和HTTPS协议是Git 最常使⽤的两种数据传输协议.SSH 协议使⽤了公钥加密和公钥登陆机制,体现了其实⽤性和安全性,使⽤此协议需要将我们的公钥放上服务器,由Git 服务器进⾏管理.使⽤HTTPS⽅式时,没有要求,可以直接克隆下来.
使⽤HTTPS⽅式:
使⽤SSH⽅式:
使⽤SSH⽅式克隆仓库,由于我们没有添加公钥到远端库中,服务器拒绝了我们的 clone 链接.需要我们设置⼀下:
1️⃣创建SSH Key.在⽤⼾主⽬录下,看看有没有.ssh⽬录,如果有,再看看这个⽬录下有没有id_rsa 和 id_rsa.pub 这两个⽂件,如果已经有了,可直接跳到下⼀步.如果没有,需要创建SSH Key: 顺利的话,可以在⽤⼾主⽬录⾥找到.ssh ⽬录,⾥⾯有 id_rsa 和 id_rsa.pub 两个⽂件,这两个就是SSH Key的秘钥对,id_rsa 是私钥,不能泄露出去,id_rsa.pub 是公钥,可以放⼼地告诉任何⼈.
2️⃣添加⾃⼰的公钥到远端仓库.点击ssh公钥选项进⾏设置:点击确认后,需要对你进⾏认证,输⼊你的账号密码即可.⾄此,我们的准备⼯作全部做完,欢快的clone吧.
done成功!如果有多个⼈协作开发,GitHub/Gitee 允许添加多个公钥,只要把每个⼈的电脑上的Key 都添加到 GitHub/Gitee,就可以在每台电脑上往 GitHub/Gitee 上提交推送了.当我们从远程仓库克隆后,实际上Git 会⾃动把本地的 master 分⽀和远程的 master 分⽀对应起来,并且,远程仓库的默认名称是 origin.在本地我们可以使⽤git remote命令,来查看远程库的信息,或者⽤git remote -v显示更详细的信息:上⾯显示了可以抓取和推送的origin的地址.如果没有推送权限,就看不到 push 的地址.推送是什么意思呢,我们继续往下看!
1.5向远程仓库推送
本地已经clone成功远程仓库后,我们便可以向仓库中提交内容,例如新增⼀个file.txt⽂件:
提交时要注意,如果我们之前设置过全局的 name 和 e-mail,这两项配置需要和 gitee 上配置的⽤⼾名和邮箱⼀致,否则会出错.或者从来没有设置过全局的 name 和 e-mail,那么我们第⼀次提交时也会报错.这就需要我们重新配置下了,同样要注意需要和 gitee 上配置的⽤⼾名和邮箱⼀致.如何配置已讲过,在这⾥就不再赘述.到这⾥我们已经将内容提交⾄本地仓库中,如何将本地仓库的内容推送⾄远程仓库呢,需要使⽤git push命令,该命令⽤于将本地的分⽀版本上传到远程并合并命令格式如下:
此时我们要将本地的master分⽀推送到origin主机的 master 分⽀,则可以像上面那张图里面写的.推送成功!这⾥由于我们使⽤的是SSH 协议,是不⽤每⼀次推送都输⼊密码的,⽅便了我们的推送操作.如果你使⽤的是HTTPS协议,有个⿇烦地⽅就是每次推送都必须输⼊⼝令.接下来,看看码云远端:
代码已经被推送⾄远端了:
1.6拉取远程仓库
在gitee上点击 file.txt⽂件并在线修改它(我不建议这样做,最好还是在本地仓库修改代码,然后在推送到远端仓库,只是为了演示效果才这样操作):修改内容:增加一个hello world.
此时,远程仓库是要领先于本地仓库⼀个版本,为了使本地仓库保持最新的版本,我们需要拉取下远端代码,并合并到本地.Git 提供了git pull命令,该命令⽤于从远程获取代码并合并本地的版本.格式如下:
我们发现,拉取成功了!
1.7忽略特殊⽂件
在⽇常开发中,我们有些⽂件不想或者不应该提交到远端,⽐如保存了数据库密码的配置⽂件,那怎么让Git 知道呢?在Git ⼯作区的根⽬录下创建⼀个特殊.gitignore ⽂件,然后把要忽略的⽂件名填进去,Git 就会⾃动忽略这些⽂件了.不需要从头写.gitignore ⽂件,gitee 在创建仓库时就可以为我们⽣成,不过需要我们主动勾选⼀下:
如果当时没有选择这个选择,在⼯作区创建⼀个也是可以的.⽆论哪种⽅式,最终都可以得到⼀个完整的.gitignore⽂件,例如我们想忽略以.so 和.ini 结尾所有⽂件,.gitignore的内容如下:
接着我们就来验证⼀下.gitignore⽂件的能⼒,在⼯作区新增两个⽂件 a.so b.ini :
检验.gitignore 的标准就是 git status 命令是不是说 working tree clean.我们发现Git 并没有提示在⼯作区中有⽂件新增,果然.gitignore ⽣效了!但有些时候,你就是想添加⼀个⽂件到 Git,但由于这个⽂件被.gitignore 忽略了,根本添加不了,那么可以⽤ -f 强制添加;或者你发现可能是.gitignore 写得有问题,需要找出来到底哪个规则写错了,⽐如说 d.so ⽂件是要被添加的,可以⽤git check-ignore命令检查：
Git 会告诉我们,.gitignore 的第3⾏规则忽略了该⽂件,于是我们就可以知道应该修订哪个规则.还有些时候,当我们编写了规则排除了部分⽂件时,但是我们发现 .* 这个规则把 .gitignore 也排除了.虽然可以⽤ git add -f 强制添加进去.但有强迫症的童鞋还是希望不要破坏.gitignore 规则.这个时候.可以添加⼀条例外规则;把指定⽂件排除在.gitignore 规则外的写法就是! +⽂件名,所以,只需把例外⽂件添加进去即可.
最后⼀步就是把 .gitignore和相关创建的文件也提交到远端就完成了!
1.8给命令配置别名
在我们使⽤Git 期间,有些命令敲的时候着实让⼈头疼(太⻓了...)幸运的是Git⽀持对命令⾏简化!举个例⼦,将
git status简化为git st,对应的命令为:
--global参数是全局参数,也就是这些命令在这台电脑的所有Git仓库下都有⽤.如果不加,那只针对当前的仓库起作⽤.好了,现在敲git st看看效果:
不过,我个⼈还是不推荐⼤家现在去使⽤命令简化等⼤家⼯作了,再去简化⾃⼰的⼯作吧,⽬前所有的命令都要⼿动完成,让大家尽快适应 Git!
2.标签管理
2.1理解标签
标签
tag,可以简单的理解为是对某次 commit 的⼀个标识,相当于起了⼀个别名.例如,在项⽬发布某个版本的时候,针对最后⼀次 commit 起⼀个 v1.0 这样的标签来标识⾥程碑的意义.这有什么⽤呢?相较于难以记住的 commit id ,tag 很好的解决这个问题,因为 tag ⼀定要给⼀个让⼈容易记住,且有意义的名字.当我们需要回退到某个重要版本时,直接使⽤标签就能很快定位到.
2.2创建标签
在Git中打标签⾮常简单⾸先切换到需要打标签的分⽀上然后,敲命令 git tag [name] 就可以打⼀个新标签:可以⽤命令
git tag查看所有标签:默认标签是打在最新提交的 commit 上的.那如何在指定的commit上打标签呢?⽅法是找到历史提交的commit id,然后打上就可以了,示例如下:
注意,标签不是按时间顺序列出,⽽是按字⺟排序的.可以⽤ git show [tagname] 查看标签信息.
Git 还提供可以创建带有说明的标签,⽤-a指定标签名,-m指定说明⽂字,格式为:
另外,打完标签之后,使⽤ tree .git 命令查看⼀下你的本地库有什么变化,肯定能帮助你理解!
2.3操作标签
如果标签打错了,也可以删除.
因为创建的标签都只存储在本地,不会⾃动推送到远程.所以,打错的标签可以在本地安全删除.
如果要推送某个标签到远程,使⽤命令git push origin <tagname>
此时,查看远端码云,看到了标签已经被更新!
当然,如果你本地有很多标签,也可以⼀次性的全部推送到远端.
如果标签已经推送到远程,要删除远程标签就⿇烦⼀点,先从本地删除:然后,从远程删除.删除命令也是push,但是格式如下:
在码云上查看确实删除成功!
3.Git实战场景---多⼈协作⼀
3.1完成准备工作
⽬前,我们所完成的⼯作如下:
①基本完成Git的所有本地库的相关操作,git基本操作,分⽀理解,版本回退,冲突解决等等.
②申请码云账号,将远端信息clone到本地,以及推送和拉取.是时候⼲最重要的⼀件事情了,实现多⼈协作开发!为了做这件事情,我们需要先做⼀些准备⼯作.我们之前已经将项⽬clone到了指定⽬录.
我们在mac环境下(如果你的是windows环境就在windows下进行操作),再clone 同⼀个项⽬仓库,来模拟和你⼀起协作开发的另⼀名⼩伙伴:
这样我就把我gitee里面的项目文件Clone成功到我的mac电脑的git文件夹中了!
3.2协助开发
⽬前,我们的仓库中只有⼀个 master 主分⽀,但在实际的项⽬开发中,在任何情况下其实都是不允许直接在 master 分⽀上修改代码的,这是为了保证主分⽀的稳定.所以在开发新功能时,常常会新建其他分⽀,供开发时进⾏迭代使⽤.那么接下来,就让我们在 gitee 上新建 dev 远程分⽀供我们使⽤,并将它拿到本地仓库
在dev分支下向file.txt里面增加"aaa"的内容,并把它push到远端仓库的dev分支下,至此开发者1的任务已经完成了!
开发者2将自己电脑本地的仓库代码分支与远端分支匹配一致
我们向file.txt文件里面增加"bbb"的内容,并把它推送到远端仓库
但是我们会发现有合并冲突因为开发者1添加的"aaa"内容和开发者2添加的"bbb"内容不一致,而我们最终想要的是"aaa、bbb"的文件内容,所以我们需要进行修改!
解决完冲突后,我们再次进行代码提交,我们就会发现成功了!
此时,我们看到远端的码云已经能看到我们的新提交了!由此,两名开发者已经开始可以进⾏协同开发了,不断的 git pull/add/commit/push ,遇到了冲突就使⽤我们之前讲的冲突处理解决掉冲突.对于开发者1来说,要想看到开发者2的代码只需要pull⼀下即可.最后不要忘记,虽然我们是在分⽀上进⾏多⼈协作开发,但最终的⽬的是要将开发后的代码合并到master上去,让我们的项⽬运⾏最新的代码.
3.3将内容合并进master
我们查看master分支时会发现里面的代码并不是我们设想的那样,重要原因是缺少了merge操作!
方法一:我们可以使用Pull Requests进行merge操作,来合并分支.
方法二:在本地仓库中进行master和dev到merge操作
切换⾄ master分⽀, pull ⼀下,保证本地的master是最新内容.合并前这么做是⼀个好习惯切换⾄dev分⽀,合并master分⽀这么做是因为如果有冲突,可以在dev分⽀上进⾏处理,⽽不是在在master上解决冲突.这么做是⼀个好习惯.切换⾄master分⽀,合并dev分⽀,将master分⽀推送⾄远端.
此时,查看远端仓库,master已经是最新代码了:
此时,dev 分⽀对于我们来说就没⽤了,那么dev分⽀就可以被删除掉.我们可以直接在远程仓库中将dev分⽀删除掉:
总结⼀下在同⼀分⽀下进⾏多⼈协作的⼯作模式通常是这样:
1️⃣⾸先,可以试图⽤ git push origin branch-name 推送⾃⼰的修改;
2️⃣如果推送失败,则因为远程分⽀⽐你的本地更新,需要先⽤ git pull 试图合并;
3️⃣如果合并有冲突,则解决冲突,并在本地提交;
4️⃣没有冲突或者解决掉冲突后,再⽤git push origin branch-name推送就能成功！
5️⃣功能开发完毕,将分⽀ merge 进 master,最后删除分⽀.
4.Git实战场景---多⼈协作二
4.1协助开发1
⼀般情况下,如果有多需求需要多⼈同时进⾏开发,是不会在⼀个分⽀上进⾏多⼈开发,⽽是⼀个需求或⼀个功能点就要创建⼀个 feature 分⽀.现在同时有两个需求需要开发者1和开发者2进⾏开发,那么你们俩便可以各⾃创建⼀个分⽀来完成⾃⼰的⼯作.在上个部分我们已经了解了可以从码云上直接创建远程分⽀,其实在本地创建的分⽀也可以通过推送的⽅式发送到远端.在这个部分我们就来⽤⼀下这种⽅式.任务目标:
对于开发者1来说可以进⾏以下操作:新增本地分⽀ feature-1 并切换新增需求内容-创建function1⽂件将 feature-1分⽀推送到远端
对于开发者2来说,可以进⾏以下操作:创建并切换到feature-2分支,在分支下为需求新增function2文档,将feature-2分支推送至远端.
此时,在本地,开发者1看不⻅开发者2新建的⽂档,开发者2看不⻅开发者1新建的⽂档.并且推送各⾃的分⽀时,并没有任何冲突,开发者俩互不影响,⽤起来很舒服!!!再来看下远端码云上此时的状态:
对于开发者feature-1分⽀,对于开发者2feature-2分⽀,正常情况下,开发者就可以在⾃⼰的分⽀上进⾏专业的开发了!但天有不测⻛云,开发者2突然⽣病了,但需求还没开发完,需要开发者1帮他继续开发,于是他便把feature-2 分⽀名告诉你了.这时开发者1就需要在⾃⼰的机器上切换到 feature-2 分⽀帮忙继续开发,要做的下面的操作.
4.2协助开发2
必须先拉取远端仓库内容,可以看到远程已经有了feature-2,切换到feature-2分⽀上,可以和远程的feature-2分⽀关联起来,否则将来只使⽤ git push 推送内容会失败.开发者1向function2.txt文件里面增加"i am coding"的内容!
切换成功后,便可以看⻅feature-2 分⽀中的function2.txt⽂件了,接着就可以帮开发者2进⾏开发:查看远程状态,推送成功了!这时,开发者2已经修养的差不多,可以继续进⾏⾃⼰的开发⼯作,那么他⾸先要获取到开发者1帮他开发的内容,然后接着开发者1的代码继续开发.或者开发者1已经帮开发者2开发完了,那开发者2也需要在⾃⼰的电脑上看看开发者1帮他写的代码:
Pull⽆效的原因是开发者2没有指定本地 feature-2 分⽀与远程 origin/feature-2 分⽀的链接,根据提示,设置feature-2和origin/feature-2的链接即可:⽬前,开发者2的本地代码和远端保持严格⼀致.开发者1和开发者2可以继续在不同的分⽀下进⾏协同开发了.各⾃功能开发完毕后,不要忘记我们需要将代码合并到master中才算真正意义上的开发完毕!
4.3将内容合并进master
由于开发者2率先开发完毕,于是开始merge,切换master,pull一下,保证本地master是最新的内容.切换至feature-2分支,合并master分支,切换至master分支,合并feature-2分支.将master分支推送至远端,此时远程仓库的状态:
当开发者2将其代码merge到master后,这时开发者1也开发完成了,也需要进⾏merge到master操作:切换⾄master分⽀, pull ⼀下,保证本地的master是最新内容合并前这么做是⼀个好习惯.切换⾄feature-1 分⽀,合并 master分⽀这么做是因为如果有冲突,可以在feature-1分⽀上进⾏处理,⽽不是在在master上解决冲突.这么做是⼀个好习惯.由于feature-1分⽀已经merge进来了新内容,为了保证远程分⽀最新,所以最好push⼀下.要 push 的另⼀个原因是因为在实际的开发中,master的merge操作⼀般不是由我们⾃⼰在本地进⾏操作,其他⼈员或某些平台merge时,操作的肯定是远程分⽀,所以就要保证远程分⽀的最新.如果merge 出现冲突,不要忘记需要commit才可以push!!切换⾄ master 分⽀,合并 feature-1分⽀,将master 分⽀推送⾄远端:
此时,feature-1 和 feature-2 分⽀对于我们来说就没⽤了,那么我们可以直接在远程仓库中将dev分⽀删除掉.这就是多⼈协作的⼯作模式,⼀旦熟悉了,就⾮常简单!
5.解决branch -a打印已被删除的远程分支的办法
当前我们已经删除了远程的⼏个分⽀,使⽤ git branch -a 命令可以查看所有本地分⽀和远程分⽀,但发现很多在远程仓库已经删除的分⽀在本地依然可以看到.例如下面,使⽤命令
git remote show origin,可以查看remote地址,远程分⽀,还有本地分⽀与之相对应关系等信息.此时我们可以看到那些远程仓库已经不存在的分⽀,根据提示,使⽤git remote prune origin命令:这样就删除了那些远程仓库不存在的分⽀.对于本地仓库的删除.之前已经介绍过了,⼤家可以⾃⾏从操作.
6.企业级开发模型
6.1企业级开发流程
我们知道,⼀个软件从零开始到最终交付,⼤概包括以下⼏个阶段:规划、编码、构建、测试、发布、部署和维护.最初,程序⽐较简单,⼯作量不⼤,程序员⼀个⼈可以完成所有阶段的⼯作.但随着软件产业的⽇益发展壮⼤,软件的规模也在逐渐变得庞⼤.软件的复杂度不断攀升,⼀个⼈已经hold不住了,就开始出现了精细化分⼯.
但在传统的IT组织下,开发团队(Dev)和运维团队(Ops)之间诉求不同:
1️⃣开发团队(尤其是敏捷团队)追求变化
2️⃣运维团队追求稳定
双⽅往往存在利益的冲突.⽐如,精益和敏捷的团队把持续交付作为⽬标,⽽运维团队则为了线上的稳定⽽强调变更控制.部⻔墙由此建⽴起来,这当然不利于 IT 价值的最⼤化.为了弥合开发和运维之间的鸿沟,需要在⽂化、⼯具和实践⽅⾯的系列变⾰⸺DevOps正式登上舞台.
DevOps(Development和Operations的组合词)是⼀种重视"软件开发⼈员(Dev)"和"IT运维技术⼈员(Ops)"之间沟通合作的⽂化、运动或惯例.透过⾃动化"软件交付"和"架构变更"的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠.在DevOps的软件开发过程包含计划、编码、构建、测试、预发布、发布、运维、监控,由此可⻅DevOps的强⼤.
讲了这么多,这个到底和我们的主题 Git 有什么关系呢?
举⼀个很简单的例⼦就能说明这个问题.⼀个软件的迭代,在我们开发⼈员看来,说⽩了就是对代码进⾏迭代,那么就需要对代码进⾏管理.如何管理我们的代码呢,那不就是 Git(分布式版本控制系统)!所以Git 对于我们开发⼈员来说其重要性就不⾔⽽喻了.
6.2系统开发环境
对于开发⼈员来说,在系统开发过程中最常⽤的⼏个环境必须要了解⼀下:
1️⃣开发环境:开发环境是程序猿们专⻔⽤于⽇常开发的服务器.为了开发调试⽅便,⼀般打开全部错误报告和测试⼯具,是最基础的环境.
2️⃣测试环境:⼀个程序在测试环境⼯作不正常,那么肯定不能把它发布到⽣产机上.该环境是开发环境到⽣产环境的过渡环境.
3️⃣预发布环境:该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测⽽设⽴的⼀套环境.其配置等基本和⽣产环境⼀致,⽬的是能让我们发正式环境时更有把握!所以预发布环境是你的产品质量最后⼀道防线,因为下⼀步你的项⽬就要上线了.要注意预发布环境服务器不在线上集成服务器范围之内,为单独的⼀些机器.
4️⃣⽣产环境:是指正式提供对外服务的线上环境,例如我们⽬前在移动端或PC端能访问到的APP都是⽣产环境.这⼏个环境也可以说是系统开发的三个重要阶段:开发->测试->上线.⼀张图总结:
对于规模稍微⼤点的公司来说,可不⽌这么⼏个环境,⽐如项⽬正式上线前还存在仿真/灰度环境,再⽐如还存在多套测试环境,以满⾜不同版本上线前测试的需要.⼀个项⽬的开始从设计开始,⽽⼀个项⽬的成功则从测试开始.⼀套良好的测试体系可以将系统中绝⼤部分的致命Bug 解决在系统上线之前.测试系统的完善和成熟也是衡量⼀个软件企业整体⽔平的重要指标之⼀,测试往往被忽视,因为它对可以的隐性、对软件开发企业不产⽣直接的效益,但是它却是软件质量的最终保障,乃⾄项⽬能否成功的重要因素！
6.3Git分⽀设计规范
环境有了概念后,那么对于开发⼈员来说,⼀般会针对不同的环境来设计分⽀,例如:
注:以上表格中的分⽀和环境的搭配仅是常⽤的⼀种,可视情况⽽定不同的策略.
1️⃣master分⽀
①master 为主分⽀,该分⽀为只读且唯⼀分⽀.⽤于部署到正式发布环境,⼀般由合并release 分⽀得到.
②主分⽀作为稳定的唯⼀代码库,任何情况下不允许直接在 master 分⽀上修改代码.
③产品的功能全部实现后,最终在master分⽀对外发布,另外所有在master分⽀的推送应该打标签(tag)做记录,⽅便追溯.
④master 分⽀不可删除.
2️⃣release分⽀
①release 为预发布分⽀,基于本次上线所有的 feature 分⽀合并到 develop分⽀之后,基于develop分⽀创建.可以部署到测试或预发布集群.
②命名以release/开头,建议的命名规则: release/version_publishtime.
③release 分⽀主要⽤于提交给测试⼈员进⾏功能测试.发布提测阶段,会以 release 分⽀代码为基准进⾏提测.
④如果在 release 分⽀测试出问题,需要回归验证 develop 分⽀看否存在此问题.
⑤release分⽀属于临时分⽀,产品上线后可选删除.
3️⃣develop分⽀
①develop 为开发分⽀,基于master分⽀创建的只读且唯⼀分⽀,始终保持最新完成以及 bug 修复后的代码.可部署到开发环境对应集群.
②可根据需求⼤⼩程度确定是由 feature 分⽀合并,还是直接在上⾯开发(⾮常不建议).
4️⃣feature分⽀
①feature 分⽀通常为新功能或新特性开发分⽀,以develop分⽀为基础创建feature分支.
②命名⽀.以 feature/ 开头,建议的命名规则:feature/user_createtime_feature.
③新特性或新功能开发完成后,开发⼈员需合到develop分⽀.
④⼀旦该需求发布上线,便将其删除.
5️⃣hotfix分⽀
①hotfix 分⽀为线上bug修复分⽀或叫补丁分⽀,主要⽤于对线上的版本进⾏ bug 修复.当线上出现紧急问题需要⻢上修复时,需要基于master分⽀创建 hotfix分⽀.
②命名以 hotfix/ 开头,建议的命名规则: hotfix/user_createtime_hotfix.
③当问题修复完成后,需要合并到master分⽀和develop分⽀并推送远程.⼀旦修复上线,便将其删除.
其实,以上跟⼤家讲解的是企业级常⽤的⼀种 Git分⽀设计规范:Git Flow模型.但要说的是,该模型并不是适⽤于所有的团队、所有的环境和所有的⽂化.如果你采⽤了持续交付,你会想要⼀些能够尽可能简化交付过程的东西.有些⼈喜欢基于主⼲的开发模式,喜欢使⽤特性标志.然⽽,从测试的⻆度来看,这些反⽽会把他吓⼀跳.关键在于站在你的团队或项⽬的⻆度思考:这种分⽀模型可以帮助你们解决哪些问题?它会带来哪些问题?这种模式为哪种开发提供更好的⽀持?你们想要⿎励这种⾏为吗?你选择的分⽀模型最终都是为了让⼈们更容易地进⾏软件协作开发.因此,分⽀模型需要考虑到使⽤者的需求,⽽不是盲⽬听信某些所谓的"成功的分⽀模型".所以对于不同公司,规范是会有些许差异,但万变不离其宗,是为了效率与稳定.
6.4企业级项⽬管理实战---准备⼯作
DevOps研发平台---Gitee企业版免费版
企业名称可随意填写⼀个测试名称,只要能通过即可.注意,多⼈协作开发,需要将多⼈账号拉⼊⼀个企业下才⾏.如何添加成员后⾯会介绍.
创建项⽬
创建仓库
添加成员
1️⃣添加企业成员
2️⃣添加项⽬成员
3️⃣添加仓库开发⼈员
6.5开发场景---基于git flow模型的实践
现有⼀个订单管理的新需求需要开发,⾸先可以基于develop分⽀创建⼀个feature/yb_20231010_pay分⽀.
1️⃣需求在feature/yb_20231010_pay,分⽀开发完毕,这时研发⼈员可以将代码合并到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流程⼀致.如果不存在,这种可能性⽐较少,⼤部分是数据兼容问题,环境配置问题等.
❸修改正式环境Bug
在master测试出现了Bug,⾸先要回归下release和develop分⽀是否同样存在这个问题.如果存在,修复流程与修复测试环境Bug流程⼀致.如果不存在,这种可能性也⽐较少,⼤部分是数据兼容问题,环境配置问题等.
❹紧急修复正式环境Bug
需求在测试环节未测试出Bug,上线运⾏⼀段时候后出现了Bug,需要紧急修复的.有的企业⾯对紧急修复时,⽀持不进⾏测试环境的验证,但还是建议验证下预发布环境.可基于master 创建hotfix/xxx 分⽀,修复完毕后发布到master验证,验证完毕后,将master代码合并到develop分⽀,同时删掉 hotfix/xxx分⽀.
拓展阅读
其他DevOps研发平台:
腾讯coding
阿里云 云效
拓展实践
阿⾥⻜流flow分⽀模型,及项⽬版本管理实践
敬请期待下一篇文章内容-->Linux系统进程概念的相关内容介绍!
每日心灵鸡汤:
愿你有"马不停蹄"的勇气
无论过去一年有多少遗憾,新的一年都是全新的起点.别怕慢,别怕难,只要一直在路上,每一步都算数.
愿你像马一样自由洒脱
生活难免有羁绊,但心可以永远辽阔.少在意别人的眼光,多听从内心的声音,去想去的地方,做想做的事.
愿你拥有"马到成功"的运气
这不是迷信,而是相信努力终有回响.认真对待每一件小事,好运自然会来敲门.
愿你保持"老马识途"的智慧
经历过的都是财富,别让挫折成为绊脚石,而是化作垫脚石.用成熟的心态,走更远的路.
愿你珍惜身边"青梅竹马"的情谊
无论是家人、朋友还是爱人,真心待你的人,都是这世间最珍贵的礼物.多陪伴,多表达爱.
最后,愿你在马年
身体健康如骏马,心情舒畅如春风,日子红火如朝阳,万事皆可期,未来皆可待!马年快乐!🐎✨
