三种git流程以及发版模型

使用Git,与其他版本控制系统最大的不同在于,Git是一个分布式系统,每一份仓库里,都是全量代码,因此协作中,冲突是常有的事。 我们来看看三种Git开发模型。

git flow

git flow 属于第一代git开发流程,它分为 developmaster 两个分支,所有的开发都在 develop 上切分支,然后定期合并到 mastermaster 代表的是 production ready 的代码。这种模型的主要问题在于需要不断地把代码从 develop 分支合并到 master,因此很容易遗漏。

  • 当需要开发新功能时,从 develop checkout 出来,开发完成时,merge 回 develop 分支
  • 当需要发布时,从 develop checkout 出来,当功能稳定后,需要把 release-* 分支分别 merge 回 developmaster 分支。
  • 当需要hotfix时,从 master checkout 出来。当修复完成后,需要把 hotfix-* 分别 merge 回 developmaster 分支。

github flow

Github 提出了 github flow,把上面的情况简化了,Github的流程在于,master 分支总是 production ready 的。当你需要进行任何 操作时,从 master checkout 出来,进行开发,然后提交PR,最后合并到 master,进行发布。

这种模型特别适合持续部署,因为我们认为 master 总是最新的 production ready 的代码。

gitlab flow

Gitlab 提出了他们自己的流程。Gitlab 提出两种模式。

持续交付模型

我们按照环境来划分分支,例如我们通常会有三个环境:开发环境,staging环境,prod环境。

我们将 master 代码持续部署到开发环境,当代码准备好时,我们从 master checkout 出来,部署到 staging 环境,当需要hotfix时, 在 master 修复,随后 cherry-pick 到对应的分支。发布时,在对应的提交上打上tag。

版本发布模型

例如iOS应用,我们通常是要进行发版操作的,因此流程提出,我们要进行发版的时候,从 msater checkout 出来,当有hotfix 时, cherry-pick 到对应的发布分支。

squash

上文中提到了,很多时候,我们都需要进行pick,或者是revert,而这两个操作,一次都只能操作一个commit,在PR中,我们通常会含有 不止一个commit。那怎么办呢?我建议打开Github中的 squash merge 选项,打开这个选项之后,会把PR中的多个提交合并成一个 提交,这样当我们需要进行 cherry-pick 或者是 revert 时,操作就会非常方便。

总结

本文中我们介绍了三种git工作流,分别看了一下他们是如何工作的,最后我们介绍了 squash,这样我们可以更方便的进行 cherry-pickrevert


ref:


微信公众号
关注公众号,获得及时更新

更多文章
  • Docker CE 18.03源码阅读与分析
  • 容器时代的日志处理
  • Golang和Thrift
  • 折腾Kubernetes
  • 协程(coroutine)简介 - 什么是协程?
  • goroutine 切换的时候发生了什么?
  • Prometheus 数据类型
  • Gin源码阅读与分析
  • 如何面试-作为面试官得到的经验
  • 自己写一个容器
  • Golang(Go语言)中实现典型的fork调用
  • 软件开发之禅---大事化小,各个击破
  • 程序员的自我修养:链接,装载与库 阅读笔记
  • Redis源码阅读与分析三:哈希表
  • Redis源码阅读与分析一:sds