那些你不得不了解的git workflow

352 阅读4分钟

没有银弹

在git版本控制工具大行其道的今天,基于git的工作流可以说是标配了,作为开发人员我们或多或少都接触过。现在市面主要有git flowgithub flowgitlab flow这三个。至于为什么我会突然研究这些flow呢,主要还是最近写自己的小项目时强套git flow模式,感觉流程太长,就想看看其他的flow能不能缓解下这个情况。

git flow

git flow是最早被提出来的工作流,也是最完备的工作流。这个模式早在2010年就被提出了,至今(2021)也有10年多的历史了,一直在被沿用,可见其的完备性极强。想要了解git flow可以先仔细看下下面的图,后面我们再开始进行分析。

git-model@2x.png

git flow分支分为两种类型,主要分支和临时分支,主要分支是长期存在的,临时分支主要是用来进行开发工作的,合并完成后即可删除。

主要分支

项目的生命周期中,下面两个分支是长期存在的。

  • master
  • develop

master是主分支,版本的发布都是在这个分支上进行,但是此分支并不做为日常的开发分支。

Develop分支做为开发分支,我们的开发工作都在这个分支上进行。

临时分支

临时分支主要有下面三个分支。

功能分支(feature branch)
发布分支(release branch)
修复分支(hotfixes branch)

需要注意的是,git flow里只定义了这三个分支,但在实际项目中,我们是需要更多类型的分支来支持我们的开发的,比如说测试文件的修改,文档的修改之类的。我们可以根据项目的需求适当增加我们的需要的分支类型。

Feature Branch

这个分支主要做新功能的开发,开发完成merge到develop分支中。

Release Branch

Release branch是在某个时期,功能稳定或者达到可以发布的标准之后,从develop分支中取出作为release分支,在这个分支中需要做版本号的更新,发布前的检查之类的工作,如果有bug,在release分支中修复后,分别并入master和develop中。

HotFix Branch

当有一个bug需要紧急修复时,需要建立一个hotfix分支来进行修复。不过hotfix分支和feature branch有所不同的是,hotfix完成之后直接merge到master直接进行新版本的发布,同时hotfix的修改也要并入develop分支。

另外,需要注意的是,如果hoxfix完成的时候,存在release分支的话,这个时候就需要将hotfix并入release分支中,待发布前再并入develop分支,然后release照常发布。

优点和缺点

优点:git flow清晰可控,对于开发中的每一个流程都进行了考虑,非常适合多版本的项目

缺点:太过于复杂,流程繁琐

Github Flow

github flow是一个简化的git 工作流,可以很好的与“持续交付”进行配合。在github flow中,只存在一条长期存在的分支即master分支。

2021-04-12_5.55.58.png

流程

1. 从master分支拉取新分支
2. 开发完成后发起PR进行讨论和review
3. 讨论和review通过后,进行部署进行最后的测试(这里可以配合一些CD工具自动进行部署)
4. merge到master分支

优点和缺点

优点:简单且非常适合“持续发布”

缺点:发布时间不可控,对于有发布窗口期的情况会造成线上和主分支不一致的情况

gitlab flow

gitlab flow的核心是上游优先(upstream first),并且只有有一个上游(master分支),gitlab对于不同的情况会有一些变化,但是并不会脱离这一原则。gitlab给出了两种我们常见的情况,分别是持续发布版本发布两种情况,下面就这两种情况,我们来对gitlab flow进行了解。

持续发布

很多时候,我们都会有发布的窗口期,并不是任何时候都可以发布,这种情况下github flow的局限性就暴露出来了。这个时候使用gitlab flow会更加适合一些。
gitlab flow的流程是这样的,所有的开发分支都并入master分支,然后在需要发布的适合cherry-pick到production分支。bug的修复也是如此。如果有pre-production环境,则可以拉一条pre-production分支作为production的上游,而master则作为pre-production的上游,仍然是是从上游到下游的这一个原则,流程可以参考下面的流程图。

bg2015122306.png

版本发布

如果是“版本发布”的项目,每到一个发布节点从master拉取一个分支作为发布的稳定版本,在分支发布后,只有严重的bug才会被并入已经发布分支中。

gitlab_flow_release_branches.png

结语

还是那句话“没有银弹”,我们只需要根据需求选择和需求相匹配的git工作流即可。即便有一些特殊的场景,我们也只需要根据情况进行调整即可。

参考链接

nvie.com/posts/a-suc…

docs.gitlab.com/ee/topics/g…

guides.github.com/introductio…