Git提交流程

上面说了这么多基础的Git知识,接下来就一起来看看日常开发当中的实践。正如上面所说Git的分支开销很小,所以可以很方便的切换分支,也是因为如此,有几种比较流行的Git分支模型。

Git分支模型

GitFlow

GitFlow最早是由Vincent Driessen发明的,目前仍然广泛采用的一种工作流程。

先看这张图片的最上面,master主分支develop开发分支是加粗的,在整个的开发周期内,这两个分支一直存在。主分支的任何一次提交都是一个稳定的版本,开发分支就是目前最新的开发版。

在这两个分支之外,有三个功能分支:

  • feature branches:功能分支,开发某个功能的分支
  • release branches:发布分支,往外释出版本的分支
  • hotfixs:修复分支,修复bug的分支
    这三个分支都是临时性的,做完之后都会合并进入到develop分支当中。GitFlow看起来相对比较复杂,需要维护两个分支。

GitHub Flow

看到这个名字就知道,这是Github推行的一个工作流。因为现在持续集成已经成为主流,所以通过GitFlow的方式来控制发版,还是很复杂。Github Flow相对于上面有了很多简化,详细的可以看Github官网的介绍

在使用过程中,每次都从master检出一个新的分支,在这个分支执行feature开发/hotfix的处理,在编写完代码之后,只需要向主分支发起PR(pull request)进入code review,确认代码没有问题之后,会将这一次PR的代码合并去master中即可。

可是Github Flow也有一个缺点,假如说发布软件有一定的窗口期,这样就会导致线上运行的代码和实际的master代码产生不一致。

Trunk-Based Development

随着敏捷开发和持续集成思想逐渐变成主流,演变出来了一种Trunk-Based Development的开发方式。在这个方式下,所有的提交都在master分支,测试和开发都相对的简单起来。但这会引出三个问题(出自分支模型与主干开发

如何避免发布的时候引入未完成的 Feature
如何进行线上 Bug Fix
如何重构
上面的引用连接中有关于这三种情况的解答,感兴趣的话,可以去看看。

提交流程

说完了分支模型,下来简单的说一下提交的流程

  • 在Jira,看板等工具中领取Task
  • 在dev分支切一个新的分支(Feature分支或者Fix分支)
  • 开发完毕之后,推送本地新建的分支到远程代码仓库
  • 新建一个PR请求,并添加代码评审员(code reviewer)
  • 等待代码评审(code review approve)结束后,合并到dev分支
  • 自动部署,自动打包程序出包,QA team测试验证结果
  • 测试通过

可能在各家公司的要求都不是特别一样,但总体来说流程会相似。或者在不同的项目(例如公司项目和个人项目)可能会有少许的差异,需要灵活的变通和调整。

REF :