共计 3488 个字符，预计需要花费 9 分钟才能阅读完成。
摘要： 聊一聊 Git 中的工作流——分支策略。
本文分享自华为云社区《Git 工作流中常见的三种分支策略：GitFlow、GitHubFlow 以及 GitLabFlow》，原文作者：麻利的小智。
前言
版本控制系统是指对软件开发过程中程序代码、配置文件、文档等产生的变更进行治理的零碎，它能够帮忙团队更好的沟通合作，从而更好的进行交付，常见的版本控制系统分为集中式版本控制系统（如 SVN）和分布式版本控制系统（如 Git）。
之前访问一家企业，企业内的开发团队应用 Git 治理日常开发工作，在开发过程中遇到一个问题：分支策略应用很凌乱——最后开发团队从骨干分支拉出一条个性分支，但新性能实现后，该个性分支没有合入主干分支，而是作为下次开发的骨干分支，从新拉出一条新的个性分支，导致骨干分支始终形同虚设，团队没有一条稳固的代码分支。
这个问题很大水平上源于团队对分支策略的不理解，本文就简略聊一聊 Git 中的工作流——分支策略。
常见的分支策略
上文中提到的团队应用分支策略很凌乱，这种分支策略也并不是支流的，应用支流的分支策略则会防止以上问题。
常见的分支策略有以下三种：GitFlow、GitHubFlow 以及 GitLabFlow。
Git Flow
GitFlow 是这三种分支策略中最早呈现的。
GitFlow 通常蕴含五种类型的分支：Master 分支、Develop 分支、Feature 分支、Release 分支以及 Hotfix 分支。
- Master 分支： 骨干分支，也是正式公布版本的分支，其蕴含能够部署到生产环境中的代码，通常状况下只容许其余分支将代码合入，不容许向 Master 分支间接提交代码（对应生产环境）。
- Develop 分支： 开发分支，用来集成测试最新合入的开发成绩，蕴含要公布到下一个 Release 的代码（对应开发环境）。
- Feature 分支： 个性分支，通常从 Develop 分支拉出，每个新个性的开发对应一个个性分支，用于开发人员提交代码并进行自测。自测实现后，会将 Feature 分支的代码合并至 Develop 分支，进入下一个 Release。
- Release 分支： 公布分支，公布新版本时，基于 Develop 分支创立，公布实现后，合并到 Master 和 Develop 分支（对应集成测试环境）。
- Hot fix 分支： 热修复分支，生产环境发现新 Bug 时创立的长期分支，问题验证通过后，合并到 Master 和 Develop 分支。
通常开发过程中新个性的开发过程如下：
从 Develop 分支拉取一条 Feature 分支，开发团队在 Feature 分支上进行新性能开发；开发实现后，将 Feature 分支合入到 Develop 分支，并进行开发环境的验证；开发环境验证实现，从 Develop 分支拉取一条 Release 分支，到测试环境进行 SIT/UAT 测试；测试无问题后，可将 Develop 分支合入 Master 分支，待发版时，间接将 Master 分支代码部署到生产环境。
可参考下图：
GitFlow 的长处是每个分支都有明确的定义，严格依照 GitFlow 治理我的项目代码的话，很难呈现代码凌乱；其毛病是：如果个性分支过多的话很容易造成代码抵触，从而进步了合入的老本；因为每次提交都波及多个分支，所以 GitFlow 也太不适宜提交频率较高的我的项目。
应用华为云 DevCloud 实现 Git Flow
1. 创立分支
华为云 DevCloud 的代码托管性能反对端到端的 GitFlow，咱们在代码仓库中可新建分支，如图，目前已有次要分支：Master 分支和 Develop 分支，和两个个性分支：Feature-Bill 和 Feature-Score 分支。
2. 为分支创立流水线
流水线性能须要在华为云 DevCloud 的流水线性能中进行配置，基于“Feature-Bill”分支新建一条流水线。
在流水线中配置构建、部署工作，以便于对 Feature-Bill 分支代码的构建、部署进行验证（构建、部署等工作须要提前在对应模块下创立）。
3.Feature 提交代码并验证
Feature-Bill 分支开发实现后，提交代码即可触发流水线进行验证。
4. 代码合入 Develop 分支进行验证
同理还须要为 Develop 分支创立一条流水线，当 Feature-Bill 分支通过 merge 命令合入到 Develop 分支之后，因为 Develop 分支的代码产生了变动，也会触发流水线进行验证。
Develop 分支验证没问题后，团队能够拉取 Release 分支，创立并启动 Release 分支的流水线进行测试环境验证。若发现缺点，可间接在 Release 分支进行批改、验证。当测试环境验证通过后，将代码合入 Master 分支，创立并启动 Master 流水线进行生产环境降级与验证。
GitHubFlow
GitHubFlow 看名字也晓得和 GitHub 无关，它来源于 GitHub 团队的工作实际。当代码托管在 GitHub 上时，则须要应用 GitHubFlow。相比 GitFlow 而言，GitHubFlow 没有那么多分支。
GitHubFlow 通常只有一个 Master 分支是固定的，而且 GitHubFlow 中的 Master 分支通常是受爱护的，只有特定权限的人才能够向 Master 分支合入代码。
在 GitHubFlow 中，新性能开发或修复 Bug 须要从 Master 分支拉取一个新分支，在这个新分支上进行代码提交；性能开发实现，开发者创立 Pull Request（简称 PR），告诉源仓库开发者进行代码批改 review，确认无误后，将由源仓库开发人员将代码合入 Master 分支。
很多人可能会问，提交代码通常是 commit 或者 push，拉取代码才是 pull，为什么 GitHubFlow 中提交代码提出的是“Pull Request”。因为在 GitHubFlow 中，PR 是告诉其余人员到你的代码库去拉取代码至本地，而后由他们进行最终的提交，所以用“pull”而非“push”。
GitHubFlow 长处是绝对于 GitFlow 来说比较简单，其毛病是因为只有一条 Master 分支，万一代码合入后，因为某些因素 Master 分支不能立即公布，就会导致最终公布的版本和打算不同。
GitLabFlow
GitLabFlow 呈现的最晚，GitLabFlow 是开源工具 GitLab 举荐的做法。
GitLabFlow 反对 GitFlow 的分支策略，也反对 GitHubFlow 的“Pull Request”（在 GitLabFlow 中被称为“Merge Request”）。
相比于 GitHubFlow，GitLabFlow 减少了对预生产环境和生产环境的治理，即 Master 分支对应为开发环境的分支，预生产和生产环境由其余分支（如 Pre-Production、Production）进行治理。在这种状况下，Master 分支是 Pre-Production 分支的上游，Pre-Production 是 Production 分支的上游；GitLabFlow 规定代码必须从上游向上游倒退，即新性能或修复 Bug 时，个性分支的代码测试无误后，必须先合入 Master 分支，而后能力由 Master 分支向 Pre-Production 环境合入，最初由 Pre-Production 合入到 Production。
GitLabFlow 中的 Merge Request 是将一个分支合入到另一个分支的申请，通过 Merge Request 能够比照合入分支和被合入分支的差别，也能够做代码的 Review。
华为云 DevCloud 也反对 GitLabFlow 的合并申请，以爱护骨干分支不收烦扰。
1. 设置爱护分支
仓库管理员在代码托管的“设置”中，抉择“爱护分支治理”，而后将 Master（或 Develop）分支设定为爱护分支，一般开发者不可向 Master 分支提交代码、也不容许合入代码，只有仓库管理员才能够向 Master 分支提交代码或合入代码。
2. 创立合并申请
在代码仓库的“合并申请”中，创立一条合并申请，申请将 Feature-Bill 分支合入 develop 分支。
并指定评审人员和执行合入操作的人员。
3.Review 代码并通过合并申请
相干人员收到合并申请后，能够通过“文件变更”，比对文件前后的变动，确认无误后，可执行合入操作，如果有抵触可线上或线下解决抵触。
除了执行合并操作，还能够对代码进行评论打分，为 Feature-Bill 分支的合入提供倡议。
总结
分支策略不同，研发效率也不同，没有最好的分支策略，只有最适宜团队的分支策略，各分支策略的优缺点在下面曾经列出，大家能够依据团队状况，抉择适合的分支策略进行开发。
点击关注，第一工夫理解华为云陈腐技术~
