三种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:


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

更多文章
  • 《程序员的自我修养-装载、链接与库》笔记
  • Golang sync.Pool源码阅读与分析
  • MySQL操作笔记
  • Go语言解析GBK编码的xml
  • Golang log 源码阅读
  • 使用Go语言实现一个异步任务框架
  • Golang flag源码阅读及自己实现
  • Go使用gdb调试
  • Golang ASM简明教程
  • Golang context源码阅读与分析
  • 善用闭包(closure)让Go代码更优雅
  • Golang中的并发控制
  • Golang的可选参数实践
  • FreeBSD ipfw使用教程
  • Golang expvar库源码阅读