目录
[Gitee 企业版DevOps研发平台](#Gitee 企业版DevOps研发平台)
企业级开发模型
一个软件从零开始到最终交付，大概包括以下几个阶段：
最初，程序比较简单工作量不大，程序员一个人可以完成所有阶段的工作，但随着软件产业的日益发展，软件的规模也逐渐变得庞大，软件复杂度不断攀升一个人已经hold不住了，就需要细化分工。此外，在传统的I组织下，开发团队Dev和运维团队Ops之间有着不同的诉求：
- 开发团队追求团队
- 运维团队追求稳定
为了弥合开发和运维之间的鸿沟，需要在文化、工具和实践方面的系列变革，DevOps应运而生。
DevOps是一种重视"软件开发人员Dev"和"IT运维技术人员Ops"之间沟通合作的文化、运动或惯例。通过自动化"软件交付"和"架构变更"的流程，使得构建、测试、发布软件能构更加地快捷、频繁和可靠。一个软件的迭代，在开发人员看来就是对代码进行迭代，那么就需要进行代码管理，即Git***（分布式版本控制系统）***
系统开发环境
对开发人员来说，在系统开发过程中最常用的几个环境必须要了解一下：
- 开发环境：专门用于日常开发的服务器，为了开发调式方便，一般打开全部错误报告和测试工具，是最基础的环境
- 测试环境：一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机机上，该环境是开发环境到生产环境的过度环境
- 预发布环境：避免因测试环境和线上环境的差异等带来的缺陷而设立的一套环境，其配置等基本和生产环境一致，目的是能让我们发布正式环境时更有把握，所以预发布环境是产品质量的最后一道防线，因为下一步项目就要上线了，要注意预发布环境服务器不在线上集成服务器范围之内，是单独的一些机器
- 生成环境：是指正式提供对外服务的线上环境，例如我们目前正在移动端或PC端能访问到的APP都是生产环境
这些环境也可以说是系统开发的三个重要阶段：开发->测试->发布
Git分支设计规范
有了环境的概念后，对于开发人员来说，一般会针对不同的环境来设计分支：
|-------------|------------|--------------|
| 分支 | 名称 | 适用环境 |
| master | 主分支 | 生产环境 |
| release | 预发布分支 | 预发布/测试环境 |
| develop | 开发分支 | 开发环境 |
| feature | 需求开发分支 | 本地 |
| hotfix | 紧急修复分支 | 本地 |
注意事项：以上表格中的分支和环境的搭配仅是常用的一种，可视情况而制定不同的策略
master分支
- master为主分支，该分支为只读且唯一分支，用于部署到正式发布环境，一般由合并release分支得到
- 主分支作为稳定的唯一代码库，任何情况下都不允许直接在master分支上修改代码
- 产品功能全部实现后，最终在master分支上对外发布，此外所有在master分支的推送应该打上标签做记录，方便追溯
- master分支不能删除
release分支
- release为预发布分支，基于本次上线的所有的feature分支合并到develop分支后，再基于develop分支创建，可以部署到测试或预发布集群
- 以release/开头，建议的命名规则是：release/version_publishtime
- release分支主要用于提交给测试人员进行功能测试，发布测试阶段，会以release分支代码为基准进行提交和测试
- 如果在release分支测试出问题，需要回归develop分支查看是否存在此问题
- release分支属于临时分支，产品上线后可以删除
develop分支
- develop分支为开发分支，基于master分支创建的只读且唯一分支，始终保持最新完成及bug修复后的代码，可以部署到开发环境对应集群
feature分支
- feature分支通常为新功能或新特性开发分支，以develop分支为基础创建该分支
- 以feature/开头，建议命名规则：feature/user_createtime_feature
- 新特性或新功能开发完成后，开发人员需要feature分支合并到develop分支
- 一旦相关的功能发布上线，便将对应的feature分支删除
hotfix分支
- hotfix分支为线上bug修复分支或补丁分支，主要用于对线上的版本进行bug修复，当线上出现紧急情况问题需要马上修复时，需要基于master分支创建hotfix分支
- 以hotfix/开头，建议的命名规则：hotfix/user_createtime_hotfix
- 当问题修复完成后，需要合并到master分支和develop分支并推送到远程，修复完成就删除
小总结
以上的内容是企业级常用的一种Git分支设计规范：Git Flow模型，但要说的是该模型并不适用所有团队、环境和文化。关键在于站在你的团队或项目的角度考虑：
- 选择的某种分支模型可以帮助你们解决什么问题？
- 它会带来哪些问题？
- 这种模式可以为哪种开发提供更好的支持？
- 公司支持鼓励这种行为吗？
最终选择的分支模型最终都是为了让人们更容易的进行软件协作开发，因此，分支模型需要考虑到使用者的需求，而不是盲目听信所谓的"成功的分支模型"所以对于不同公司，规范是会有些许差异，但它们都是为了效率和稳定
企业级项目管理实战
Gitee 企业版DevOps研发平台
①打开网站自定义企业名和地址空间
②新建项目
③创建仓库
④向项目和仓库中添加成员
注意事项：创建仓库时如果想要自定义feature等分支，不能选择图中的分支模型，否则在进入仓库时系统自动创建好feature等分支我们就不能再创建了，需要选用生产/开发模型：
⑤向仓库中新增feature分支
⑥在feature分支上开发完成后申请将其合并至develop分支
⑦在develop分支下开发人员自测通过后，然后开发人员可以基于develop分支创建一个release/xxx分支，将该分支交由测试人员进行测试
⑧测试人员对该release分支测试通过后（包含测试环境和预发布环境的测试）就可以将代码何如master分支
⑧测试人员在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分支（更新develop）同时删除hotfix/xxx分支
拓展内容
其它DevOps研发平台：
拓展实践：阿里飞流flow分支模型，及项目版本管理实践
~over~