Git工作流中常见的三种分支策略：GitFlow、GitHubFlow和GitLabFlow-低调大师

Git工作流中常见的三种分支策略：GitFlow、GitHubFlow和GitLabFlow

2021-07-15 612

摘要：聊一聊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分支的合入提供建议。

总结

分支策略不同，研发效率也不同，没有最好的分支策略，只有最适合团队的分支策略，各分支策略的优缺点在上面已经列出，大家可以根据团队情况，选择合适的分支策略进行开发。

点击关注，第一时间了解华为云新鲜技术~

微信关注我们

原文链接：https://my.oschina.net/u/4526289/blog/5131618

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

带你换个角度理解图卷积网络

摘要：本文带大家从另一个角度来理解和认识图卷积网络的概念。本文分享自华为云社区《技术综述十二：图网络的基本概念》，原文作者：一笑倾城。基础概念笔者认为，图的核心思想是学习一个函数映射f(.)f(.)，借助该映射，图中的节点可以聚合自己的特征与邻居节点的特征，从而生成该节点的新特征表示。 Figure 1. 图的一般推理过程[1] 图神经网络 Vs. 卷积神经网络如图2所示，卷积神经网络的输入数据一般是规则的矩阵类型数据，例如图片。每个节点和其它节点的空间关系是固定的。而图神经网络的输入数据一般表现为不规则的拓扑结构，节点与节点的关系非常复杂，节点间的空间关系一般不做约束，节点间是否存在连接以及连接的数量不做约束。复杂的网络还涉及到连接的方向和子图等概念。 Figure 2. 图网络和卷积网络[1] 如图3所示，如果将图的每个节点等价视为图像中的每个像素，其实，图的工作过程可以类比CV中的经典问题：semantic segmentation。 Figure 3. semantic segmentation[2] 图的基础组件及其实现图在工作过程中，主要需要处理的问题有两个，一个...

2021-07-15

531

转载请注明出处：葡萄城官网，葡萄城为开发者提供专业的开发工具、解决方案和服务，赋能开发者。目前低代码技术正处在风口，低代码平台产品不断涌现，乱花渐欲迷人眼。作为软件公司或企业IT部门的负责人，在做低代码平台选型时需要关注哪些方面，才能顺利“上车”，让低代码为自己的团队赋能？除了产品功能是否满足当前项目需求，价格是否在预算范围内之外，以下几个问题的答案同样重要。 Q1：是否支持协同开发和版本管理？项目开发过程中，我们难免遇到客户反馈某个新开发的功能没有用，但是过一段时间以后反悔，又希望加回来的情况。这是软件开发的常态。为了解决这一问题，传统的软件开发团队都会引入版本管理机制，低代码也不例外。面对频繁的需求变更、棘手的问题排查，低代码平台的版本管理，特定模块回滚等操作的价值就会体现出来。此外，为了加速项目的交付速度，我们通常需要集中更多人员进行同步开发。只有具备协同开发能力的低代码平台才能让这一过程变得可管理，避免混乱。所以，不论项目规模大小，选择一款兼容主流代码库、支持敏捷开发的低代码平台都会对开发工作有所帮助。（Git：一款主流的版本控制系统，图片来自Git官网） Q2：是...

2021-07-15

509

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。