目录
3.Git分支设计模型
3.1master分支
3.2release分支
3.3develop分支
3.4feature分支
3.5hotfix分支
4.企业级项目挂历实战_准备工作&开发场景实操学习文档
3.Git分支设计模型
- 对于我们开发人员来说，对于不同的场景/环境，来设计分支模型。对于生产集群服务器上都是面向用户，稳定的代码，对应着master主分支的代码。对于开发集群，开发人员，代码的管理，开发分支，有代码的提交记录。
本章讲解常见的分支模型——git flow模型
注：以下表格中的分⽀和环境的搭配仅是常⽤的⼀种，可视情况⽽定不同的策略。
其实，以下跟⼤家讲解的是企业级常⽤的⼀种 Git 分⽀设计规范：Git Flow 模型。但要说的是，该模型并不是适⽤于所有的团队、所有的环境和所有的⽂化。如果你采⽤了持续交付，你会想要⼀些能够尽可能简化交付过程的东西。有些⼈喜欢基于主⼲的开发模式，喜欢使⽤特性标志。然⽽，从测试的⻆度来看，这些反⽽会把他吓⼀跳。
关键在于站在你的团队或项⽬的⻆度思考：这种分⽀模型可以帮助你们解决哪些问题？它会带来哪些问题？这种模式为哪种开发提供更好的⽀持？你们想要⿎励这种⾏为吗？你选择的分⽀模型最终都是为了让⼈们更容易地进⾏软件协作开发。因此，分⽀模型需要考虑到使⽤者的需求，⽽不是盲⽬听信某些所谓的“成功的分⽀模型”。
所以对于不同公司，规范是会有些许差异，但万变不离其宗，是为了效率与稳定。
【五个部分组成】
【总图】
3.1master分支
- master 为主分⽀，该分⽀为只读且唯⼀分⽀。⽤于部署到正式发布环境，⼀般由合并
release 分⽀得到。- 主分⽀作为稳定的唯⼀代码库,任何情况下不允许直接在 master 分⽀上修改代码。
- 产品的功能全部实现后，最终在master分⽀对外发布，另外所有在master分⽀的推送应该打标签（tag）做记录，⽅便追溯。
- master 分⽀不可删除。
3.2release分支
- release 为预发布分⽀，基于本次上线所有的 feature 分⽀合并到 develop 分⽀之后，基于 develop 分⽀创建。可以部署到测试或预发布集群。
- 命名以 release/ 开头，建议的命名规则: release/version_publishtime 。
- release 分⽀主要⽤于提交给测试⼈员进⾏功能测试。发布提测阶段，会以 release 分⽀代码为基准进⾏提测。
- 如果在 release 分⽀测试出问题，需要回归验证 develop 分⽀看否存在此问题。
- release 分⽀属于临时分⽀，产品上线后可选删除。
3.3develop分支
- develop 为开发分⽀，基于master分⽀创建的只读且唯⼀分⽀，始终保持最新完成以及 bug 修复后的代码。可部署到开发环境对应集群。
- 可根据需求⼤⼩程度确定是由 feature 分⽀合并，还是直接在上⾯开发（⾮常不建议）
3.4feature分支
- feature 分⽀通常为新功能或新特性开发分⽀，以 develop 分⽀为基础创建 feature 分
⽀。- 命名以 feature/ 开头，建议的命名规则： feature/user_createtime_feature 。
- 新特性或新功能开发完成后，开发⼈员需合到 develop 分⽀。
- ⼀旦该需求发布上线，便将其删除。
3.5hotfix分支
- hotfix 分⽀为线上 bug 修复分⽀或叫补丁分⽀，主要⽤于对线上的版本进⾏ bug 修复。当线上出现紧急问题需要⻢上修复时，需要基于 master 分⽀创建 hotfix 分⽀。
- 命名以 hotfix/ 开头，建议的命名规则: hotfix/user_createtime_hotfix
- 当问题修复完成后，需要master分支 合并到 develop 分⽀并推送远程。⼀旦修复上线，便将其删除。
4.企业级项目挂历实战_准备工作&开发场景实操学习文档
具体实操步骤☞见学习文档
DevOps研发平台
DevOps_DevOps 解决方案_一站式 DevOps_开发者工具 | 腾讯云 CODING DevOps
阿里云云效_云效_云原生时代新DevOps平台-阿里云 (aliyun.com)
Gitee 企业版 - 企业级 DevOps 研发效能平台
