Github flow

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

GitHub Flow —— 以部署为中心的开发模式,通过简单的功能和规则,持续且高速 安全地进行部署。在实际开发中往往一天之内会实施几十次部署,而支撑这一切的,就是足够简单的开发流程以及完全的自动化。

它只有一个长期分支,就是master,因此用起来非常简单。
image.png

Github flow如何工作

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

Github flow 的最大优点就是简单,对于”持续发布”的产品,可以说是最合适的流程。

问题在于它的假设:master分支的更新与产品的发布是一致的。也就是说,master分支的最新代码,默认就是当前的线上代码。

可是,有些时候并非如此,代码合并进入master分支,并不代表它就能立刻发布。比如,苹果商店的APP提交审核以后,等一段时间才能上架。这时,如果还有新的代码提交,master分支就会与刚发布的版本不一致。另一个例子是,有些公司有发布窗口,只有指定时间才能发布,这也会导致线上版本落后于master分支。

上面这种情况,只有master一个主分支就不够用了。通常,你不得不在master分支以外,另外新建一个production分支跟踪线上版本。

特点

  1. 令master 分支时常保持可以部署的状态
  2. 进行新的作业时要从master 分支创建新的分支,新分支名称要具有描述性
  3. 在2新建的本地仓库分支中进行提交
  4. 在Github 端仓库创建同名分支,定期push
  5. 需要帮助、反馈,或者branch已经准备merging时,创建Pull Request,以Pull Request 进行交流
  6. 让其他开发者进行审查,确认作业完成后与master分支进行合并(合并的代码一定要测试
  7. 与master分支合并后,立刻部署