三种git流程以及发版模型
2022-7-28 08:0:0 Author: jiajunhuang.com(查看原文) 阅读量:2 收藏

使用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:


更多文章
  • 任务队列怎么写?python rq源码阅读与分析
  • XMonad 配置教程
  • Haskell简明教程(三):Haskell语法
  • Haskell简明教程(二):从命令式语言进行抽象
  • Haskell简明教程(一):从递归说起
  • 2017年必装的VIM插件推荐
  • TCP/IP简明教程 - 从零构建TCP/IP协议(二)连接,断开与拥塞控制
  • TCP/IP简明教程 - 从零构建TCP/IP协议(这次叫PCT协议)
  • Lua Manual 阅读笔记
  • Golang Map 源码阅读与分析
  • MySQL 零碎知识 - MySQL必知必会
  • Golang slice 源码阅读与分析
  • 经典好书推荐(2017)
  • Golang log库 源码阅读与分析
  • 毕业后一年



  • 文章来源: https://jiajunhuang.com/articles/2022_07_28-git_flows.md.html
    如有侵权请联系:admin#unsafe.sh