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


更多文章
  • Go访问私有变量
  • Raft论文阅读笔记
  • 避免全局变量
  • Go的unsafe包
  • Golang中实现禁止拷贝
  • 人生如戏,全靠演技 -- 《日常生活中的自我呈现》读后感
  • Golang的反射
  • 数据库事务
  • 把网站去掉CSS之后
  • 处理并发的方式
  • 常见的索引方式
  • Golang 实践经验
  • 高性能MySQL笔记第一章
  • 面试的一些技巧
  • HTTP/2 简介