上一篇文章主要针对现有Git分支管理和应用进行了介绍，此外还留下了一些内容没有讲完，本篇文章就是针对剩余内容进行介绍。
Git flow代码分支管理介绍
在开始介绍Git flow之前，还是希望把这个东西的应用场景再介绍一下，避免大家过多陷入到具体的分支命名而忽略存在的意义。 大家可以试想一下，对于单个团队按照需求排期逐个进行功能开发以及迭代向前，这种场景使用原先的develop+master分支就够了。也没有必要引入其他的分支管理增加复杂度。这个流程好用是有一个前提，那就是功能必须是顺序开发，做完一个功能需求后再进行下一个功能开发，但是如果当前项目功能较多，项目负责人希望能够增加人力的同时对多个功能进行并行开发。这种场景大家再想一下，使用原先的master+develop开发有什么问题。 一个最常见的场景就是两个功能开发的提交会交替发起代码合入申请，导致功能开发之间无法进行很好的隔离。实际上，问题到这里就说完了，原本设想就是两个开发组同事同事对一个系统进行开发，然后再逐个合并到系统分支完成开发、测试和发布。但是使用简单的master+develop就会破坏功能开发的隔离性。单纯只是提到这个场景，大家可能并不能清晰认识到这个会引发的问题，但是基于这个场景我们可以推出以下几个可能带来的问题 1.开发团队每次提交合入后都需要关注代码库是否能够编译成功，一旦出现错误还需要人为介入修改。 这个问题并不是采用这个分支会遇到的问题，对于正常开发也可能会遇到代码合入后无法完成编译。但是多个团队并行开发一个分支会让这个问题加剧。且一旦出现这个问题会很大的影响开发效率，需要花很多时间解决一些和业务开发无关的事情。当然，现在已经有了一些标准化的开发工具支持，大家入库的代码只有完成编译通过才会允许合入到代码库。对于流程体系不是特别完善的场景，这个问题解决起来比较头疼。 2.代码冲突变多，且容易出现业务代码被覆盖的问题。 正常进行单个功能开发也会遇到这个问题，和上面一样，出现这个问题的概率较低。一般情况下单个团队对于即将开发的功能都是做好了设计，且每个同事都会负责一些独立的模块，因此在开发过程中不容易出现代码冲突，或者代码冲突经过简单的代码同步即可解决。但是对于多团队开发，如果开发的多个功能涉及到同一个模块，那么就会很容易引起冲突，且解决冲突的难度也会提高。如果不是对于这两个功能开发有详细了解的人进行合并，甚至还会在解决冲突引入潜在的bug。 第二点业务代码被覆盖的问题也是上述提到解决冲突时候容易引起的，这些问题都是不是主观因素引入，而是在正常的开发流程中无意识存在的。如果本身开发流程没有增加单元测试拦截，这些问题会像地雷一样潜伏，知道后续自测或者联调阶段才能发现。 其他还有一些例如配置文件修改覆盖等和上述问题属于差不多的场景问题，不再重复。虽然现在已经有很标准的手段拦截或者发现这些问题，但是解决这些问题也是需要人工介入且耗费大量时间。 一个很自然的想法就是，既然大家一起用一个分支会引起冲突，是不是多拉几个分支就好了，大家用不同的分支进行开发，这样不就不会冲突了。而这个也是Git flow中feature分支存在的含义。不同团队可以分别使用feature分支进行开发、提测。这样日常工作中也就不会出现上述的两个问题。事实上也确实如此。解决了上述提到的开发和测试中的问题，不同团队完成代码开发以及完成测试后临近发布。这个时候问题又出现了，怎么合并不同团队的代码？直接合入到master是肯定不行的，毕竟master是系统能够直接发布的，将多个开发团队代码合并本身就会有风险，不经过测试直接发布合并后的代码不符合软件流程规范，也容易引起软件问题。 针对这个问题，也很好解决，我们再引入一个公共的分支专门用于合入代码，并专门用于进行代码合并后的测试不就行了？这也是Git flow中develop分支存在的意义，develoop分支是专门用于开发，测试，合并代码的分支。各个功能开发分支（feature分支）开发完成后都会合入到develop进行最后的融合测试，在develop上完成融合测试后就会拉取release分支用于完成最后合入master之前的一些操作。 有些人会迷惑，为什么不是直接develop合入就可以？还需要拉取release分支进行操作？问题就在于develop完成测试到合入master之前本身就会有一段时间，也称之为预发布时间，这段时间还需要进行一些发布前的最后确认。例如部分bug不解决，功能文档更新以及进行一些发布体验类测试。这些都会花费时间，如果没有release分支，相当于这段时间其他团队无法从develop分支进行代码合入或者拉取分支的操作，阻塞开发团队继续进行功能迭代。而直接拉取release分支后，其他团队可以正常使用develop分支，而预发布阶段的操作也可以基于release进行。在合入时候release不仅会合入到master分支，还会合入到develop分支。合入到develop分支目的就是将预发布阶段的修改同步到现有开发的主分支，避免后续有重复的预发布修改。release代码合入到主分支后就可以进行预部署，后续就是进行发布尝试，这里不再赘述发布阶段流程。 上面还少一个流程，就是开发功能时候的feature分支从哪里拉取。一些人认为应该从master拉取，而一些人认为应该从develop拉取。从Git flow设计上应该从develop分支拉取最新的代码来创建新的特性分支。这样可以保证你是在最新、最完整的开发进度上进行工作，并有助于减少未来合并冲突的可能性。但是一些团队会将develop作为一个临时分支，每次都是通过严格控制develop的合并阶段窗口来完成一次发布操作，具体就是在一个阶段完成上一次功能发布后就会基于最新master同步develop分支，然后同时创建基于master的feature分支进行开发。对于发布并不是非常频繁的场景，这样做也没啥问题，但是对于贯彻敏捷开发思想的团队可能更倾向于上面一种基于develop拉取功能开发分支的做法，这样会更好的隔离多个阶段的工作。 这里可以给出Git flow对于多个分支的定义 主分支（Master/Main）：这个分支包含随时可以发布的生产代码。所有的重大变更都应通过合并其他分支来更新到主分支上。 开发分支（Develop）：这是主分支的一个平行分支，用于整合所有准备并入下一个新发布的特性分支。当需要准备一个新的生产版本时，会从这个分支创建出一个发布分支。 特性分支（Feature）：这些分支源自于develop分支，每个新功能都应该有自己的特性分支。完成之后，它们会被合并回develop。命名通常以feature/开头，例如feature/new-login-page。 发布分支（Release）：当开发分支上的功能已经准备好进行下一版发布时，可以从develop分支创建一个发布分支。在这个分支上，只进行小范围的调整、bug修复和准备工作。完成后，该分支会被合并进master和develop分支。 修复分支（Hotfix）：如果在当前生产版本中发现了严重的错误，可以从master分支直接创建一个修复分支。修复完毕后，此分支将被合并回到master和develop分支中，以确保错误不会出现在未来的版本中。通常命名为hotfix/开头。
Github flow分支
Github flow实际上就是Git flow的简化版 master，代表了随时可部署到生产环境的代码状态。 特性分支（Feature Branches）：所有新功能或修复都是从main分支创建的新分支开始的。这些分支的命名通常能反映它们的目的，比如feature/new-login-page或bugfix/issue-123。 Pull Requests（PRs）：当一个特性或修复完成并经过本地测试后，开发者会通过发起一个Pull Request来请求将更改合并回main分支。这是团队成员进行代码审查的地方，也是自动化测试运行的地方。 在Pull Request过程中，应该有自动化测试来验证新的代码不会破坏现有功能。一旦Pull Request被批准并且所有检查都通过，就可以将更改合并到main分支，并自动部署到生产环境中。 使用流程上，开发者从main或master分支创建特性分支进行新功能开发或问题修复，完成后通过Pull Request（PR）请求合并回main或master分支，在此过程中会进行代码审查和自动化测试以确保代码质量，一旦PR被批准且所有检查通过，则将更改合并到main或master并部署到生产环境。这种方法支持快速迭代、持续交付，并保持了项目的稳定性和高质量。
Gitlab flow分支
功能开发分支/特性分支feature:从main或master分支创建，完成后通过Merge Request合并回主分支 生产分支:发布分支，用于部署。 预生产分支（Environment Branches）:直接从main或master创建，用于最终验证，确保所有功能都能正常工作。 生产分支 (Production Branch) [可选]:经过充分测试的新版本将被合并到生产分支中，并部署到生产服务器。对于热修复，可以直接基于生产分支创建分支进行修复，然后迅速合并回生产分支及main或master。 从main或master分支创建特性分支进行开发，通过Merge Request（MR）合并回主分支前需经过代码审查和自动化测试。GitLab Flow支持使用特定环境分支（如staging、production，从master拉取）来控制不同阶段的部署，并与CI/CD管道紧密集成，确保代码在各个环境中的稳定性和一致性，完成测试后将预发布分支合入master，通过production分支或者特定tag的master构建镜像并部署到生产环境。
