B94c030b17d9dda8f531c14803bca6f1
持续集成与 Git 工作流

一、前言

上一篇我们主要讲解了持续集成工具选型,阅读完的朋友可以根据自己的项目特点选择合适的工具 。工具问题解决后,我们需要优化一下“源头”。现今,有许多工作流,本文将介绍几种常见的Git工作流 。阅读本文后,你会对这些工作流有一个更好的了解,知道他们各自的特点,从而选出最适合持续集成的工作流。

二、Git工作流

"工作流"在英语里,叫做"workflow",原意是水流,比喻项目像水流那样,顺畅地向前流动,不会发生冲击、对撞、甚至漩涡。

项目开发中,多人协作,分支很多,虽然各自在分支上互不干扰,但是我们总归需要把分支合并到一起,而且真实项目中涉及到很多问题,例如版本迭代,版本发布,bug 修复等,为了更好的管理代码,需要制定一个工作流程,这就是我们说的工作流,也有人叫它分支管理策略

工作流不涉及任何命令,因为它就是一个规则,完全由开发者定义并遵守,正所谓无规矩不成方圆,就是这个道理。

目前使用度最高的工作流有如下几种:

Git Flow 出现的最早,GitHub Flow 在 Git Flow 的基础上,做了一些优化,适用于持续版本的发布,而 GitLab Flow 出现的时间比较晚,所以综合前面两种工作流的优点,制定而成的一个工作流。TBD则是谷歌现行的工作流。

Git Flow

Git Flow 是 Vincent Driessen 2010 年发布的分支管理模型,到现在为止,使用度非常高。在早期,我管理项目用的就是这个。

Git Flow 的分支结构很清晰。按功能来说,可以分支为5种分支,从5 种分支的生命周期上,又可以分别归类为长期分支暂时分支,在表现上,其实就是主分支协助分支

主分支

  • master:最新版本发布的代码分支。
  • develop:最新开发进度的代码分支。

当 develop 上的代码达到一个稳定的状态,可以发布版本的时候,develop上这些修改会被合并到 master 分支上,然后标记上对应的版本标签(Tag)。

协助分支

除了主分支,Git Flow 的开发模式还需要一系列的协助分支,来帮助更好地并行开发,简化功能开发和问题修复。

  • feature:特性分支,用来做新特性开发。新特性开发完成之后,会合并到 develop 分支,然后删除。

  • release:发布分支,用来做版本(预)发布。在分出发布分支后,该分支只修bug,不再合入新特性。 并且修改bug的提交,会合并回 develop,保证 develop 为最新进度。 当测试完毕后,release分支会合并到 develop 和 master 分支,并打上Tag。
    这样做的好处是,在测试的时候,不影响下一个版本功能并行开发

  • hotfix:热修复分支,用来做线上的紧急 bug 修复的分支。当线上某个版本出现了问题,将检出对应版本的代码,创建 Hotfix 分支,问题修复后,合并回 master 和 develop ,然后删除。这里注意,合并到 master 的时候,也要打上修复后的版本标签。

说明

Vincent Driessen 建议合并分支的时候,加上 no-ff 参数,这个参数的意思是不要选择 Fast-Forward 合并方式,而是策略合并,策略合并会让我们多一个合并提交。这样做的好处是保证一个非常清晰的提交历史,可以看到被合并分支的存在。

SourceTree已提供GitFlow的操作,可减轻分支合并的繁琐。

评价

Git Flow的优点是清晰可控,缺点是相对复杂,需要同时维护两个长期分支。大多数工具都将master当作默认分支,可是开发是在develop分支进行的,这导致经常要切换分支,非常烦人。
更大问题在于,这个模式是基于"版本发布"的,目标是一段时间以后产出一个新版本。但是,很多网站项目是"持续发布",代码一有变动,就部署一次。这时,master分支和develop分支的差别不大,没必要维护两个长期分支。

Github Flow

Github Flow 是Git Flow的简化版,专门配合"持续发布"。它是 Github.com使用的工作流程

第一步:从master拉出新分支。
第二步:新分支开发完成后,或者需要讨论的时候,就向master发起一个pull request(简称PR)。
第三步:Pull Request既是一个通知,让别人注意到你的请求,又是一种对话机制,大家一起评审和讨论你的代码。对话过程中,你还可以不断提交代码。
第四步:当Pull Request被接受,合并进master,重新部署后,原来你拉出来的那个分支就被删除。(先部署再合并也可。)

top Created with Sketch.