目录
前言：
其实文章更新到这里的时候，我们已经学习了可以满足我们日常生活中的基本需求的指令了，但是为什么要更新本篇文章呢？是因为实际生活中我们对于开发工作，运维工作，以及测试工作都是由单独的分支的，那么一个项目推进的时候，整体的布局是什么样的，不同的人应该使用什么样的分支，这是我们所关心的，自然就会涉及到很多不同的模型，所以本文主要是介绍有关模型的知识。
有关开发模型
我们了解开发模型之前，不妨简单回忆一下之前所涉及到的部分知识，比如master是用来干什么的，dev是用来干什么的，feature是用来干什么的等。
其实追其本源，都是从程序员的负责模块引出来的。
比如开发者，涉及的工作部分肯定是规划代码，写代码，构建代码框架等，对于测试人员，涉及的工作肯定只有一个是测试，对于运维工程师，涉及的工作内容就是发布代码，部署代码，后期维护代码等。
所以实际上的开发项目过程中，开发者们的分支一般都是dev分支，development，开发的意思，对于测试人员，涉及的部分是hotfix，也就是紧急修复分支的意思，对于运维工程师，涉及的分支一般都是Release分支，也就是预发布分支，对于master分支来说，Release分支基本上就是发布之前的最后一道流程了，因为会在该分支测试许多情况。
常见的比如仿真环境，模拟用户真实使用的场景，然后在该分支上访问代码构建的平台，那么什么是灰度测试呢？灰度测试实际上是为了特殊的需求处理的，比如有部分人的环境并不是很符合该代码构建的平台，但是勉强能用，所以为了该类用户的需求，就会单独为该类用户测试。
这是涉及到的开发人员的职责。
所以环境一共分为：
开发环境，测试环境，预发布环境，生成环境。其中的生产环境就是面对用户提供的线上服务平台。
所以就会引发一个问题，对于开发人员来说，肯定是要敏捷度很高，毕竟需求那么多，所以代码变化很大是正常的，对于运维人员来说，肯定是不希望代码变化的，也就是代码稳定了就先这样的感觉。测试人员嘛，就，，，对吧哈哈哈哈。
言归正抓，实际上的开发中如何平衡二者的关心呢？
此时DevOps就出场了，它本质上更像是一种人人都清楚的惯例，而该词语的组成是development operations的组成，开发和运维之间的一种交流文化，详细是什么就不是该文章的内容了，这里放个链接，有兴趣的可以自行查阅：
DevOps到底是什么意思？ - 知乎 (zhihu.com)
那么对于分支来说：
master 分⽀
• master 为主分⽀，该分⽀为只读且唯⼀分⽀。⽤于部署到正式发布环境，⼀般由合并 release 分⽀得到。
• 主分⽀作为稳定的唯⼀代码库,任何情况下不允许直接在 master 分⽀上修改代码。 • 产品的功能全部实现后，最终在master分⽀对外发布，另外所有在master分⽀的推送应该打标签 （tag）做记录，⽅便追溯。
• master 分⽀不可删除。
release 分⽀
• release 为预发布分⽀，基于本次上线所有的 feature 分⽀合并到 develop 分⽀之后，基 于 develop 分⽀创建。可以部署到测试或预发布集群。
• 命名以 release/ 开头，建议的命名规则: release/version_publishtime 。
• release 分⽀主要⽤于提交给测试⼈员进⾏功能测试。发布提测阶段，会以 release 分⽀代码 为基准进⾏提测。
• 如果在 release 分⽀测试出问题，需要回归验证 develop 分⽀看否存在此问题。 • release 分⽀属于临时分⽀，产品上线后可选删除。
develop 分⽀
• develop 为开发分⽀，基于master分⽀创建的只读且唯⼀分⽀，始终保持最新完成以及 bug 修 复后的代码。可部署到开发环境对应集群。
• 可根据需求⼤⼩程度确定是由 feature 分⽀合并，还是直接在上⾯开发（⾮常不建议）。 feature 分⽀
• feature 分⽀通常为新功能或新特性开发分⽀，以 develop 分⽀为基础创建 feature 分 ⽀。
• 命名以 feature/ 开头，建议的命名规则： feature/user_createtime_feature 。
• 新特性或新功能开发完成后，开发⼈员需合到 develop 分⽀。
• ⼀旦该需求发布上线，便将其删除。
hotfix分支
• hotfix 分⽀为线上 bug 修复分⽀或叫补丁分⽀，主要⽤于对线上的版本进⾏ bug 修复。当线上 出现紧急问题需要⻢上修复时，需要基于 master 分⽀创建 hotfix 分⽀。
• 命名以 hotfix/ 开头，建议的命名规则: hotfix/user_createtime_hotfix • 当问题修复完成后，需要合并到 master 分⽀和 develop 分⽀并推送远程。⼀旦修复上线，便 将其删除。
所以远端的dev分支并不是我们开发平台的主力，而是本地仓库的feature分支才是我们开发人员的主力。
现在引入模型，由于模型十分多，所以这里介绍一个非常有代表性的模型，也就是Git Flow模型：
对于这个模型而言，就是属于可以持续交付的模型，也就是隔一段时间发布一个新版本，其实现在很多软件都是这个模型了，毕竟不同的用户的需求不同，这也就意味着软件需要不停的更新。
对于不同的公司的开发模型是不一样的，比如腾讯的某个软件，阿里的某个软件都是，我们现在不妨简单模拟一下企业级别的开发流程。
这里放一个简单企业级开发的链接，可以容纳5个人，我们毕竟是简单学习一下，所以要求的平台还不用那么高。
从这个界面进入，随便取一个公司名称，就可以进入了：
项目这里可以简单创建一个项目，对于刚刚登入这个号的人来说，会有新手导向，也就是自动会出现一个项目，这是正常的。
新建项目，并且可以关联到自己的仓库。
创建好了之后就是较为空荡荡的。
但是我们还需要创建一下仓库，在右上角可以新建仓库，进去就是git创建仓库的部分了。基本是一样的。
需要注意的是这里的分支模型，我们是一个企业，所以肯定不能选择单分支模型的，我们选择的是生产开发模型，如果我们选择的是开发/发布/缺陷分离模型，就会导致后面我们想基于某个分支创建其他分支是不可以的，因为选择这个分支之后，是将我们的分支模型固定了，自由发挥的空间不是很大。
此时就创建好了对应的仓库。
但是一个企业不能只有我们一个人吧，所以我们需要添加成员：
需要你的小伙伴通过链接或者是二维码就可以成功进入你的企业了。
企业成员有了，还需要项目人员吧？所以需要我们添加项目人员：
项目的添加成员部分就可以添加。
项目人员有了，开发成员得有吧？所以我们需要添加仓库开发人员：
代码仓库的这里，就可以添加对应的开发人员或者是测试人员等。
那么，简简单单试试Git Flow？
首先我们要基于Dev分支创建一个feature分支，毕竟是十分不推荐在Dev分支上进行开发的，所以新建：
新建成功之后，我们现在拥有三个分支，一个是feature分支，一个是dev一个是master，所以我们现在可以在feature分支上修改一下ReadMe文件，当成是代码开发：
当然了，为了方便，我们这里直接使用本地的IDE作为演示，实际是不可以在Gitee里面进行修改的。
然后左下角有一个提交，我们点击提交即可：
上方还需要我们保存一下。
此时对于master分支 dev分支是不知道有对应的修改的，所以在feature分支下需要请求代码评审，这里就就不能像我们当时学习那样，框的一下就自己提交了。
此时因为feature分支是基于dev分支创建的，自然是目标分支为dev，然后简单描述一下Issue即可：
在这里我们直接通过即可。
那么就可以直接进行评审了。
此时dev分支就合并成功了，本质上是开发人员自测通过了，所以需要基于dev分支新建一个Release分支，作为是测试人员的工作分支：
同样是在分支管理部分新加。
那么需要pull request，但是合并之后需要删除分支，因为这个分支只是作为测试存在。
此时master分支就完成了。
对于实际中的开发工作肯定是远比本文描述的复杂的，所以本文只是作为我们日后的一个热身罢了，各位开发者加油吧！
感谢阅读！