其他分享
首页 > 其他分享> > Git常见分支策略

Git常见分支策略

作者:互联网

前言

版本控制系统是指对软件开发过程中程序代码、配置文件、文档等发生的变更进行管理的系统,它可以帮助团队更好的沟通协作,从而更好的进行交付,常见的版本控制系统分为集中式版本控制系统(如SVN)和分布式版本控制系统(如Git)。

常见的分支策略

常见的分支策略有以下三种:GitFlow、GitHubFlow以及GitLabFlow

Git Flow

GitFlow是这三种分支策略中最早出现的。

GitFlow通常包含五种类型的分支:Master分支、Develop分支、Feature分支、Release分支以及Hotfix分支

通常开发过程中新特性的开发过程如下:

  1. 从Develop分支拉取一条Feature分支,开发团队在Feature分支上进行新功能开发;
  2. 开发完成后,将Feature分支合入到Develop分支,并进行开发环境的验证;
  3. 开发环境验证完成,从Develop分支拉取一条Release分支,到测试环境进行SIT/UAT测试;
  4. 测试无问题后,可将Develop分支合入到Master分支,待发版时,直接将Master分支代码部署到生产环境

适用场景

GitFlow的优点是每个分支都有明确的定义,严格按照GitFlow管理项目代码的话,很难出现代码混乱;其缺点是:如果特性分支过多的话很容易造成代码冲突,从而提高了合入的成本;由于每次提交都涉及多个分支,故而GitFlow也不太适合提交频率较高的项目。

GitHubFlow

GitHubFlow来源于GitHub团队的工作实践。当代码托管在GitHub上时,则需要使用GitHubFlow。相比GitFlow而言,GitHubFlow没有那么多分支。

GitHubFlow通常只有一个Master分支是固定的,而且GitHubFlow中的Master分支通常是受保护的,只有特定权限的人才可以向Master分支合入代码。

在GitHubFlow中,流程如下:

  1. 新功能开发或修复Bug需要从Master分支拉取一个新分支,在这个新分支上进行代码提交;
  2. 功能开发完成,开发者创建Pull Request(简称PR),通知源仓库开发者进行代码修改review,确认无误后,将由源仓库开发人员将代码合入Master分支。

适用场景

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。

标签:Git,Develop,代码,常见,GitHubFlow,Master,分支,合入
来源: https://www.cnblogs.com/Torres-tao/p/16445071.html