Git学习第五天 分支工作流模型

Gitflow模型介绍

Git分支管理中的一些工作流模型，所谓工作流模型，就是一些好的规范和流程，可以让我们的工作更高效，更有条理

它将分支分成了五种类型，每种类型都有自己的用途。

主线分支

        最左边这一列是主线分支，也叫基线分支，就是我们常常说的main分支或者master分支，主线分支是项目的核心分支，它包含了项目的最新稳定版本的代码，我们应该随时保证主线分支中的代码是可发布的，一般来说，主线分支的代码会被部署到生产环境中，主线分支中的代码是不允许直接被修改的，只能通过合并分支的方式来修改，每次合并分支都建议生成一个新的版本号，这样可以方便追踪和回溯，可以通过

git tag

命令来标记版本号，版本号的规则一般也是有规定的，如下图所示

一般来说，问题修复分支是从主线分支中分离出来的，修复完成后会被合并到主分支和开发分支中，当问题修复分支完成之后，一般会将这个问题修复分支删除掉，问题修复分支也一般会更新我们的小版本号。

开发分支

就是上图中绿色的这一部份，它是从主线分支中分离出来的，包含了项目的最新开发版本的代码，用于开发和测试开发分支也是项目的核心分支，和main分支一样也是一个长期存在的分支开

功能分支

发分支右侧黄色的这一部份就是我们的功能分支。功能分支一般包含了项目某个新功能的代码，用于开发新的功能，他们的都是从开发分支中分离出来的，当功能分支的代码稳定后，会以某种方式合并回开发分支中，比如上面的

就是一个功能分支，用于开发登陆页面的功能，功能分支中应该只包含登陆页面相关的功能代码，等到开发完成后，合并回开发分支中，然后再按版本发布的计划执行版本发布的流程，这就涉及到我们版本发布的分支，也叫做预发布分支

预发布分支

这个分支包含了项目最新预发布版本的代码，用于发布前的测试和验证，一般来说，预发布分支是从开发分支中分离出来的，当预发布分支的代码稳定后，会被合并到主分支和开发分支中，比如在1.1.0版本发布之前，会发布一个预发布分支，用于测试和验证，在测试和验证过程中发现的问题会在预发布分支中进行修改，提交，并且cherry-pick到开发分支中，当预发布分支的代码稳定后，会合并到主分支和开发分支中，然后会将预发布分支删除掉。

按照生命周期的不同进行分类

主要分支和辅助分支，主要分支分为主分支和开发分支，这两个分支是项目的核心分支，一般都是长期存在的；其他三种分支都属于辅助分支，在完成各自的功能之后就可以删除了。

GithubFlow模型

GithubFlow模型适用于技术水平比较高的团队或者开源项目

只有一个长期存在的主分支，而且主分支上的代码是可以直接部署到生产环境中的，一般都会设置分支保护，禁止团队直接在主分支上进行提交，团队成员可以从主分支中分离出自己的分支进行开发和测试，然后在本地分支提交代码，等到开发完成之后，可以发起一个Pull Request简称PR，中文名也叫拉请求，或者叫做合并请求，团队成员可以对代码进行review评审，如果没有问题，就可以将这个PR发布和合并到主分支中了，整个流程就完成了