mg电子游戏网站开发快速seo软件

一、删除远程分支，git branch -a （查看所有本地分支与远程分支）还能看到已经删除的分支，怎么解决？

解决方法：
查看远程分支的情况

git remote show origin

被删除的分支就是陈旧的分支

git remote prune origin

然后删除本地分支，就完成了彻底删除。

先在master分支上拉取，更新信息，然后删除别的分支
git branch -d function1 function2 dev

二、企业级开发流程

2.1 企业级开发流程

我们知道，⼀个软件从零开始到最终交付，⼤概包括以下⼏个阶段： 规划、 编码、 构建、 测试、 发布、部署和维护。

软件规模较小的项目可以由一个软件开发人员去完成（开发->测试->发布上线）
软件规模大，一个人就吼不住了，就需要多人去开发。

• 开发团队(尤其是敏捷团队)追求变化
• 运维团队追求稳定
为了弥合开发和运维之间的鸿沟，需要在⽂化、 ⼯具和实践⽅⾯的系列变⾰ ⸺DevOps正式登上舞台。

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

2.2 系统开发环境

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

三、Git分支设计模型

针对不同的环境有不同的分支，常用开发软件的分支如下：

master分支：

1.master为主分⽀ ，该分⽀只读且唯⼀分⽀。⽤于部署到正式发布环境，⼀般由合并release分⽀得到。
2.主分⽀作为稳定的唯⼀ 代码库,任何情况下不允许直接在 master 分⽀上修改代码。
3.产品的功能全部实现后，最终在master分⽀对外发布。
4.master分⽀不可删除。

release分支：

1.release分⽀主要⽤于提交给测试⼈员进⾏功能测试。
2.release分⽀测试出问题，需要回归验证develop分⽀看否存在此问题。
3.release分⽀属于临时分⽀，产品上线后可选删除。

develop分支：

1.develop为开发分⽀,基于master分⽀创建的只读且唯⼀分⽀，始终保持最新完成以及 bug 修复后的代码。
2.可根据需求⼤⼩程度确定是由feature分⽀合并，还是直接在上⾯开发（⾮常不建议） 。

feature分支：

1.我们开发一个功能，就有一个分支。
2.一但功能需求开发完毕，开发人员就合并到develop分支里。
3.一但功能上线，就可以将分支删除。

hotfix分支：

1.hotfix分支用来修复bug的分支。一但master分支出现bug，就要基于master分支创建一个hotfix分支。
2.在hotfix分支上把bug修复完毕，需要合并到 master 分⽀和 develop 分⽀并推送远程。⼀旦修复上线，便将其删除。

企业级常⽤的⼀ 种 Git 分⽀设计规范： Git Flow 模型（就是上面的五个分支）。该模型并不是适⽤于所有的团队、 所有的环境，主要是为了编写代码的效率与代码的稳定。

四、企业级项目管理

如何进行企业级项目管理？
为了解决“软件开发人员”和“IT运维技术人员”，之间的沟通问题。需要在⽂化、 ⼯具和实践⽅⾯进行变⾰ ⸺DevOps正式登上舞台。

2.1 准备工作

1. 创建项目
   
2. 创建仓库
   企业里面要有成员，两种添加成员方式。
   
   添加项目成员
   
   添加仓库成员
   

创建代码

2.2 代码的开发（测试）

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

1. 新需求加⼊
   新建一个分支
   
   
   
   代码合并
   
   
   查看到feature/wzq_20240724_pay分支已经合并到develop分支上了。
   
   基于develop分支创建release/1.0_20240724（都是最新的develop分支里的代码）
   
   测试人员测试release通过后（包含测试环境和预发布环境的测试）， 就可将代码合并⼊master（和上面合并分支的操作一样）。
   最后把不必要的分支删除掉
   

2. 修复测试环境 Bug
   在develop测试时，出现bug，我们需要回退到feature分支（feature分支是在develop分支基础上创建完成得）上进行处理，处理完毕后，与新需求加入的流程一致。

3. 修改预发布环境 Bug
   在release分支上出现bug，要回归到develop分支查看是否存在相同的问题。
   如果存在，修复流程 与 修复测试环境 Bug流程⼀致。
   如果不存在，这种可能性⽐较少，⼤部分是数据兼容问题，环境配置问题等。

4. 修改正式环境 Bug
   在master上测试出bug，要回归到develop和release分支上查看是否存在相同的问题。
   如果存在，修复流程 与 修复测试环境Bug流程⼀ 致。
   如果不存在，这种可能性也⽐较少，⼤部分是数据兼容问题，环境配置问题等。

5. 紧急修复正式环境 Bug
   在测试环节未测试出 Bug，上线运⾏⼀段时候后出现了 Bug，需要紧急修复的。
   在master分支的基础上，创建hotfix/XXX分支，修复完毕后发布在master分支上进行测试验证，验证完毕，将这段代码合并到master分支和develop分支，同时删掉hotfix这个分支。