目录
前言：
有关开辟模子
前言：
其实文章更新到这里的时候，我们已经学习了可以满足我们日常生活中的基本需求的指令了，但是为什么要更新本篇文章呢？是由于实际生活中我们对于开辟工作，运维工作，以及测试工作都是由单独的分支的，那么一个项目推进的时候，团体的布局是什么样的，不同的人应该使用什么样的分支，这是我们所关心的，自然就会涉及到许多不同的模子，以是本文主要是先容有关模子的知识。
有关开辟模子
我们了解开辟模子之前，不妨简单回忆一下之前所涉及到的部分知识，好比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个人，我们毕竟是简单学习一下，以是要求的平台还不用那么高。
Gitee 企业版 - 企业级 DevOps 研发效能平台
从这个界面进入，随便取一个公司名称，就可以进入了：
项目这里可以简单创建一个项目，对于刚刚登入这个号的人来说，会有新手导向，也就是自动会出现一个项目，这是正常的。
新建项目，并且可以关联到自己的仓库。
创建好了之后就是较为空荡荡的。
但是我们还必要创建一下仓库，在右上角可以新建仓库，进去就是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分支就完成了。
对于实际中的开辟工作肯定是远比本文描述的复杂的，以是本文只是作为我们日后的一个热身罢了，各位开辟者加油吧！
感谢阅读！
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
