一个软件从零开始到最终交付，大概包括以下几个阶段：规划、编码、构建、测试、发布、部署和维护。
最初，程序比较简单，工作量不大，程序员一个人可以完成所有阶段的工作。但随着软件产业的日益发展壮大，软件的规模也在逐渐变得庞大。软件的复杂度不断攀升，一个人已经 hold 不住了，就开始出现了精细化分工。如下图所示：
- 开发团队（尤其是敏捷团队）追求变化
- 运维团队追求稳定
双方往往存在利益的冲突。比如，精益和敏捷的团队把持续交付作为目标，而运维团队则为了线上的稳定而强调变更控制。部门墙由此建立起来，这当然不利于 IT 价值的最大化。
为了弥合开发和运维之间的鸿沟，需要在文化、工具和实践方面的系列变革 ⸺ DevOps正式登上舞台。
DevOps（Development 和 Operations 的组合词）是一种重视 “软件开发人员（Dev）” 和 “IT运维技术⼈员（Ops）” 之间沟通合作的文化、运动或惯例。透过自动化 “软件交付” 和 “架构变更” 的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。在 DevOps 的软件开发过程包含计划、编码、构建、测试、预发布、发布、运维、监控，由此可见 DevOps 的强大。
了解 DevOps：DevOps到底是什么意思？ - 知乎 (zhihu.com)
一个软件的迭代，在开发人员看来，说白了就是对代码进行迭代，那么就需要对代码进行管理。如何管理我们的代码呢 —— Git（分布式版本控制系统） ，所以 Git 对于开发人员来说其重要性就不言而喻了。
一、系统开发环境
对于开发⼈员来说，在系统开发过程中最常用的几个环境必须要了解⼀下：
- 开发环境：开发环境是程序员们专门用于日常开发的服务器。为了开发调试方便，一般打开全部错误报告和测试工具，是最基础的环境。
- 测试环境：一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。该环境是开发环境到生产环境的过渡环境。
- 预发布环境：该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测而设立的一套环境。其配置等基本和生产环境一致，目的是能让我们发正式环境时更有把握，所以预发布环境是你的产品质量最后一道防线，因为下一步你的项目就要上线了。要注意预发布环境服务器不在线上集成服务器范围之内，为单独的一些机器。
- 生产环境：是指正式提供对外服务的线上环境，例如我们目前在移动端或 PC 端能访问到的 APP 都是生产环境。
这几个环境也可以说是系统开发的三个重要阶段：开发 -> 测试 -> 上线
总结：
对于规模稍微大点的公司来说，可不止这么几个环境，比如项目正式上线前还存在仿真 / 灰度环境，再比如还存在多套测试环境，以满足不同版本上线前测试的需要。
一个项目的开始从设计开始，而一个项目的成功则从测试开始。一套良好的测试体系可以将系统中绝大部分的致命 Bug 解决在系统上线之前。测试系统的完善和成熟也是衡量一个软件企业整体水平的重要指标之一，测试往往被忽视，因为它对可以的隐性、对软件开发企业不产生直接的效益，但是它却是软件质量的最终保障，乃至项目能否成功的重要因素。
二、Git 分支设计规范
环境有了概念后，那么对于开发人员来说，一般会针对不同的环境来设计分支，例如：
注意 ：以上表格中的分支和环境的搭配仅是常用的⼀种，可视情况而定不同的策略。
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 分支并推送远程。一旦修复上线，便将其删除。
6、总结
上面讲解的是企业级常用的一种 Git 分支设计规范：Git Flow 模型。但要说的是，该模型并不是适用于所有的团队、所有的环境和所有的文化。如果你采用了持续交付，你会想要一些能够尽可能简化交付过程的东西。有些人喜欢基于主干的开发模式，喜欢使用特性标志。然而，从测试的角度来看，这些反而会把他吓一跳。
关键在于站在你的团队或项目的角度思考：这种分支模型可以帮助你们解决哪些问题？它会带来哪些问题呢？这种模式为哪种开发提供更好的支持？你们想要鼓励这种行为吗？你选择的分支模型最终都是为了让人们更容易地进行软件协作开发。因此，分支模型需要考虑到使用者的需求，而不是盲目听信某些所谓的 “成功的分支模型”。所以对于不同公司，规范是会有些许差异，但万变不离其宗，是为了效率与稳定。
三、企业级项目管理实战
1、准备工作
（1）DevOps 研发平台
企业名称可随意填写一个测试名称，只要能通过即可。
注意：多人协作开发，需要将多人账号拉入一个企业下才行。
（2）创建项目
（3）创建仓库
注意：创建的仓库可以关联到某个项目中被管理。
（4）添加成员
A. 添加企业成员
B. 添加项目成员
C. 添加仓库开发人员
2、开发场景 —— 基于 git flow 模型的实践
（1）新需求加入
现有一个订单管理的新需求需要开发，首先可以基于 develop 分支创建⼀个 feature/xyl_20240606_pay 分支。
只能将仓库删除，重新创建：
创建步骤和前面一致，除了下面这一点需要修改：
A. 需求在 feature/xyl_20240606_pay 分支开发完毕，这时研发人员可以将代码合并到 develop 分支，将其部署在开发环境的服务器中，方便开发人员进行测试和调试。
a. 开发者在 feature 分支下发起请求评审
b. 审查员审查代码；审查通过，合并分支
c. 合并成功，查看结果
B. 在 develop 下开发人员自测通过后，先确定下 develop 不存在未测试完毕的需求，然后研发人员可基于 develop 分支创建⼀个 release/xxx 分支出来，可交由测试人员进行测试。
新建分支：
C. 测试人员测试 release 通过后（包含测试环境和预发布环境的测试），就可将代码合并入 master 。
接着进行审查与合并。
D. 测试人员在 master（正式环境）测试通过后，便可删除 feature/xxx 分支
（2）修复测试环境 Bug
在 develop 测试出现了 Bug，建议直接在 feature 分支上进行修复，修复后的提测上线流程 与 新需求加入的流程一致。
（3）修改预发布环境 Bug
在 release 测试出现了 Bug，首先要回归下 develop 分支是否同样存在这个问题。 如果存在，修复流程 与 修复测试环境 Bug 流程一致。如果不存在，这种可能性比较少，大部分是数据兼容问题，环境配置问题等。
（4）修改正式环境 Bug
在 master 测试出现了 Bug，首先要回归下 release 和 develop 分支是否同样存在这个问题。
- 如果存在，修复流程与修复测试环境 Bug 流程⼀致。
- 如果不存在，这种可能性也比较少，大部分是数据兼容问题，环境配置问题等。
（5）紧急修复正式环境 Bug
需求在测试环节未测试出 Bug，上线运行一段时候后出现了 Bug，需要紧急修复的。
有的企业面对紧急修复时，支持不进行测试环境的验证，但还是建议验证下预发布环境。
可基于 master 创建 hotfix/xxx 分支，修复完毕后发布到 master 验证，验证完毕后，将 master 代码合并到 develop 分支，同时删掉 hotfix/xxx 分支。
（6）拓展阅读
A. 其他 DevOps 研发平台
DevOps_DevOps 解决方案_一站式 DevOps_开发者工具 | 腾讯云 CODING DevOps
