阿八博客
  • 100000+

    文章

  • 23

    评论

  • 20

    友链

  • 最近新加了很多技术文章,大家多来逛逛吧~~~~
  • 喜欢这个网站的朋友可以加一下QQ群,我们一起交流技术。

Gitflow 工作流

欢迎来到阿八个人博客网站。本 阿八个人博客 网站提供最新的站长新闻,各种互联网资讯。 喜欢本站的朋友可以收藏本站,或者加QQ:我们大家一起来交流技术! URL链接:https://www.abboke.com/jsh/2019/1010/116552.html

Gitflow 工作流

图片如果未正常加载,请使用翻墙工具或跳转至原文

Gitflow Workflow 是一种 Git 工作流程设计,由 nvie 的 Vincent Driessen 首次发布并广受欢迎
这个 Gitflow workflow 围绕着项目的发布定义了严格的分支模型,为管理大型项目提供了强大的框架

Gitflow 非常适合具有发布周期计划的项目
这个工作流程没有新增任何超出功能分支工作流程的新概念或者命令
相反,它给与不同的分值赋予了不同的角色,定义了怎样以及什么时候进行互动
除了功能分支
除了功能分支外,它还使用各个分支来准备,维护和记录版本
当然,您还可以利用Feature Branch Workflow 的所有好处:拉取请求,孤立的实验和更有效的协作

开始

Gitflow 实际上只是 Git 工作流程的抽象概念
这意味着它决定了要建立哪种分支以及如何将它们合并在一起
我们将触及以下分支的目的
git-flow 工具集是具有安装过程的实际命令行工具
git-flow 的安装过程很简单
git-flow 的软件包可在多个操作系统上使用
在 OSX 系统上,您可以执行 brew install git-flow
在Windows上,您需要下载并安装 git-flow
安装git-flow后,您可以通过执行 git flow init 在项目中使用它
Git-flow 是围绕 Git 的包装
git flow init 命令是默认 git init 命令的扩展,除了为您创建分支外,不会更改存储库中的任何内容

工作机制

Feature Branches(功能分支)

每个新功能都应驻留在其自己的分支中,可以将其推送到中央存储库以进行备份/协作
但是,功能分支不是将其合并到主分支,而是将 develop 分支用作其父分支
功能完成后,它会重新合并到开发中
Feature 分支绝不能直接与 master 进行交互

一旦 develop 分支获得了足够的功能以进行发布(或临近预定的发布日期),就可以从 develop 分支分支发布
创建此分支将开始下一个发行周期,因此此刻之后此发布分支无法添加任何新功能-该分支中仅应包含错误修复,文档生成以及其他面向发行版的任务
一旦准备好发布,发行分支将合并到 master 并用版本号标记
此外,应该将其重新合并到开发中,而自发布以来,该过程可能已经进行了

使用专门的分支来准备发布,使一个团队可以完善当前版本,而另一个团队可以继续开发下一个版本的功能
它还创建了明确定义的开发阶段(例如,很容易地说:“本周我们正在为版本 4.0 作准备,并在存储库的结构中实际看到它)

说明:专门的分支是指的Release分支,并非Master分支

进行发布分支是另一种直接的分支操作
像功能分支一样,发布分支也基于开发分支
可以使用以下方法创建新的发行分支

没有 git-flow 的情景

git checkout developgit checkout -b release/0.1.0

使用 gti-flow 的情景

git flow release start 0.1.0Switched to a new branch 'release/0.1.0'

一旦这个版本准备好发布,它将被合并到master中并进行开发,然后发布分支将被删除
重要的是将其重新合并到 develop 分支中,因为关键更新可能已添加到 release 分支,并且新功能需要访问这些更新
如果您的团队强调代码审查,那么这将是请求请求的理想场所

要完成发行分支,请使用以下方法:

没有 git-flow 的情景

git checkout mastergit merge release/0.1.0

使用 gti-flow 的情景

git flow release finish '0.1.0'

Hotfix Branches / 修补程序分支/热修复分支

单一型产品

特点:通用、不分区域,再无强制更新的情况下老版本基本上仍然能够正常使用
也可能由于更新的不及时可能导致无法正常工作或缺少一些功能支持,例如 “浏览器”

框架型产品

特点:因某些原因导致不通用(数据不统一),例子:一个交通管理类的系统,各个省份之间数据设计不同,导致每个省份都需要一个类似的系统,业务相同、操作相同又各有特点,每个版本必须强制更新

框架

特点:通用,发布过的所有历史版本需要一直维护,需要考虑向下、向上兼容,不维护后劝升级、提供升级途径
例如: Angular 或其他

总结

在实际开发中,如果参与人员多、项目规模大,在效率上理论上是比单分支模型高,规范的 git 流程能够大大减少开发冲突,除此外规范的流程在线上出现紧急问题时具有更好的风险抗压能力与风险处理能力

在git服务器上的分支可以是master 、 develop、 release
release 是发布版本一般情况下在发布后会合并到 master 与 develop,然后删除该分支,但是如果是框架(jQuery)这种,也有可能发布一个1.2.0等,那这个版本是可以上传到远程 git 服务器的
其他的Feature、Hostfix是在本地处理的,处理完成后可以合并到 master 与 develop分支

分支这么多肯定会变得麻烦,不过这种方式是在开发人员多、项目规模大的情景下使用,一般小团队可以采用“集中模型”进行开发

在列出的项目类型中,通过他们的特点,看出单一型、框架型比较适合,框架型产品不是太适合,在采用那种 git 模型时,还应根据项目实际规模来决定采用那种方式

其他分支模型

相关文章

暂住......别动,不想说点什么吗?
  • 全部评论(0
    还没有评论,快来抢沙发吧!