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


更多文章
  • KVM 显卡穿透给 Windows
  • 使用 HTTP Router 处理 Telegram Bot 按钮回调
  • 使用反射(reflect)对结构体赋值
  • GIN 是如何绑定参数的
  • 你好 2022(2021 年终总结)
  • 用Go导入大型CSV到PostgreSQL
  • 使用 OpenWRT 搭建软路由
  • 使用软KVM切换器 barrier 共享键鼠
  • SQL 防注入及原理
  • 使用 gomock 测试 Go 代码
  • gevent不是黑魔法(二): gevent 实现
  • gevent不是黑魔法(一): greenlet 实现
  • 用 entgo 替代 gorm
  • 应用内使用crontab不是那么方便
  • 单测时要不要 mock 数据库?