【Git原理与使用】多人协作与开发模型（2）

git branch

git checkout -b feature-1 #新增本地分支fecature-1并切换

vim func1 #新增需求内容

cat func1 #查看

git add func1 #添加到暂存区

git commit -m " add func1" #添加版本库

git push origin feature-1 #将feature-1分支推送到远端

(2)开发者2同理在 feature-2进行专业的开发了

(3)某天开发者2生病，需要你帮助他继续开发，这时你就需要切换到 feature-2分支帮忙开发了

git pull #必须先拉取远端仓库内容

git branch -a #可以看到远程已经有了feature-2

git checkout -b feature-2 origin/feature-2 #切换到 feature-2分支上，可以和远程的feature-2分支关联起来，否则将来只使用git push推送内容会失败

vim func2

cat func2

git add func2

ait commit -m "modify func2"

git push origin feature-2

(4)这时，你的小伙伴开发2修养好了，可以继续他自己的开发工作了，那么他首先要获取到你帮他开发的内容，接着继续开发。

git pull #失败了，并未pull下来开发/帮忙写的代码，是因为开发2没有指定本地feature-2分支与远程 origin/featnre-2分支的链接。

git branch--set-upstream -to=origin/freature-2 fenture-2

(5)各自开发完毕后，需要合并到master才算完成

(6)开发2开始merge.

git checkout master

git pull #保证本地masler是最新的内容.

git checkout feature-2 #切到 feature-2分支合并master

git merger master #无冲突就继续

git checkout master

git merge feature-2

git push origin master #将本地master推到远程

(7)开发者1同理，完成后featnre-1可直接在远程仓库删除

4、解决方法

远程分支删除后，本地git branch -a仍能看到的解决方法

git remote show origin #查看remote 地址远程分支，还有本地分支与之相对应关系等

git remote prune origin #删除远程仓库不存在的分支

二、企业级开发模型

1、DevOps背景

一个软件从0开始到最终交付，大概包括以下几个阶段：规划编码、构建、测试、发布、部署和维护软开测运维但在传统的IT组织下，开发团队(Dev)和运维团队(Ops)之间的诉求不同，双方利益冲突，不利于实现IT价值的最大化

开发团队：追求变化

运维团队：追求稳定

2、DevOps是什么

（1）为了保障开发和运维之间的鸿沟，需要在文化工具和实践方面的系统变革------DevOps就出现了

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

3、DevOps与git的关系

一个软件的迭代，在我们开发人员看来，说白了就是对代码进行迭代，那么就需要对代码进行管理。如何管理我们的代码呢，那不就是git(分布式版本控制系统)------所以git对于我们开发人员来说其重要性就不言而喻了。著名的gitee码云就是一种DevOps平台

4、系统开发环境

（1）开发环境：开发环境是程序员专门用于日常开发的服务器。为了开发调试方便，一般打开全部错误报告和测试工具是最基础的环境

（2）测试环境：一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上，该环境是开发环境到生产环境的过渡环境

（3）预发布环境：该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测而设立的一套环境。其配置等基本和生产环境一致，目的是能让我们发正式环境更有把握

（4）生产环境：是指正式提供对外服务的线上环境

5、Git分支设计规范

（1)

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

(2)master分支

①为主分支，为只读且唯一。用于部署到正式发布环境，一般由合并release分支得到代码

②作为稳定的唯一代码库，不允许直接在master上修改

③master分支的推送应该打标签(tag)做记录，方便追溯

④ master分支不可删除

(3) release分支

①release为预发布分支，基于本次上线所有的feature分支合并到develop分支之后，基于develop分支创建。可以部署到测试或须发布集群。

②命名以release/开头建议的命名规则：release/version_publishtime

③主要用于提支给测试人员进行功能测试。发布提测阶段，会以release分支代码为基础进行提测

④如果在release分支测试出问题，需要回归验证develop分支看是否存在此问题

⑤releau属于临时分支，产品上线后可选删除

(4)develop分支

①develop为开发分支，基于master分支创建的只读且唯一分支始终保持最新完成以及bug修复后的代码。可部署到开发环境对应集群

②可根据需求大小程度确定是由feature分支合并，还是直接在上面开发(非常不建议)

(5)feature分支

①feature分支通常为新功能或新特性开发分支，以develop分支为基础创建feature分支

②命名以feature/开头，建议的命名规则：feature/user_createtime_feature.

③新特性或新功能开发完成后，开发人员需合到develop分支

④一旦该需求发布上线，便将其删除

(6)hotfix分支

①为线上bua修复分支或补丁分支，主要用于对线上的版本进行bug修复。当线上出现紧急问题need马上修复，需要基于masber分支创建hotfix分支

②命爷以hotfix/开头，建议的命名规则：hotfix/user_creatime_notfx③当问题修复完成后，need合并到master分支和develop分支并推送远程，一旦修复上线可删

以上跟大家分享的是企业级常用的一种git分支设计规范git flow模型。但是还是要说的是该模型并不适用于所有团队。最主要的还是需要站在团队以及项目的角度组看这个模型是否能简洁的解决问题

6、企业级项目管理一般流程

(1)准备工作

DevOps研发平台---gitee 企业版

(2)创建项目

(3)创建仓库

(4)添加成员

7、开发场景一基于gitflow模型的实战

(1)新需求加入

现有一个订单管理的新需求need开发，首先可以基于develop分支创建一个feature/xxxx_20241024分支

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

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

b、审查员审查代码

C、审查通过，合并分支

d、合并成功、查看结果

②在develep下开发人员自测通过后，先确定下develop不存在

未测试完毕的需求，然后研发人员可基于develop分支创建一个release/xxx分支出来，可交由测试人员进行测试

③测试人员测试release通过后，就可将代码合并入master

④测试人员在master测试通过后，便可删除feature/xxx分支

(2)修复测试环境Bug

在develp测试出现了Bug，建议在feature分支上修复

(3)修复预发布环境Bug

在release测试出现了Bug，首先要回归develop分支是否同样存在问题

(4)修复正式环境Bug

在master测试出了问题，要回归release和develop

(5)紧急修复正式环境Bug

上线后出现Bug，紧急修复的。可基于master创建hotfix/xxxx分支，修复后发布到master验证完毕后，将master合并到develop，同时删掉hotfix/×xx分支