GitFork工作流

一、Git分支类型

1.1 master分支

  • master 为产品主分支,该分支为只读唯一分支,也是用于部署生产环境的分支,需确保master分支的稳定性。
  • master 分支一般由release分支或hotfix分支合并,任何情况下都不应该直接修改master分支代码。
  • 产品的功能全部实现后,最终在master分支对外发布,另外所有在master分支的推送应该打标签(tag)做记录,方便追溯。
  • master 分支不可删除。

1.2 develop分支

  • develop 为主开发分支,基于master分支创建,始终保持最新完成功能的代码以及bug修复后的代码。
  • develop 分支为只读唯一分支,只能从其他分支合并,不可以直接在该分支做功能开发或bug修复。
  • 一般开发新功能时,feature分支都是基于develop分支下创建的。
  • develop 分支包含所有要发布到下一个release的代码。
  • feature功能分支完成后, 开发人员需合并到develop分支(不推送远程),需先将develop分支合并到feature,解决完冲突后再合并到develop分支。
  • 当所有新功能开发完成后,开发人员并自测完成后,此时从develop拉取release分支,进行提测。
  • release或hotfix 分支上线完成后, 开发人员需合并到develop分支并推送远程。
  • develop 分支不可删。

1.3 feature分支

  • feature 分支通常为新功能或新特性开发分支,以develop分支为基础创建feature分支。
  • 分支命名: feature/ 开头的为新特性或新功能分支,建议的命名规则: feature/user_createtime_feature,例如:feature/ftd_20201018_alipay,含义为:开发人员ftd在2020年10月18日时创建了一个支付宝支付的功能分支。
  • 新特性或新功能开发完成后,开发人员需合到develop分支。
  • feature 分支可同时存在多个,用于团队中多个功能同时开发。
  • feature 分支属于临时分支,功能完成后可选删除。

1.4 release分支

  • release 分支为预上线分支,基于本次上线所有的feature分支合并到develop分支之后,从develop分支创建。
  • 分支命名: release/ 开头的为预上线分支,建议的命名规则: release/version_publishtime,例如:release/v2.1.1_20201018,含义为:版本号v2.1.1计划于2020年10月18日时发布。
  • release 分支主要用于提交给测试人员进行功能测试。发布提测阶段,会以release分支代码为基准进行提测。测试过程中发现的bug在本分支进行修复,上线完成后需合并到develop/master分支并推送远程。
  • release 分支属于临时分支,产品上线后可选删除。

1.5 hotfix分支

  • hotfix 分支为线上bug修复分支或叫补丁分支,主要用于对线上的版本进行bug修复。
  • 分支命名: hotfix/ 开头的为修复分支,它的命名规则与 feature 分支类似,建议的命名规则: hotfix/user_createtime_hotfix,例如:hotfix/ftd_20201018_alipaybugfix,含义为:开发人员ftd在2020年10月18日时创建了一个支付宝支付bug修复的分支。
  • hotfix 分支用于线上出现紧急问题时,需要及时修复,以master分支为基线,创建hotfix分支。当问题修复完成后,需要合并到master分支和develop分支并推送远程。
  • 所有hotfix分支的修改会进入到下一个release。
  • hotfix 分支属于临时分支,bug修复上线后可选删除。

二、Fork工作流

  • Fork 工作流是一种分布式工作流,充分利用了 Git 在分支和克隆上的优势。可以安全可靠地管理大团队的开发者,并能接受不信任贡献者的提交。像githubgitlab 线上服务就是使用这个工作流模式

fork工作流

  • 每个成员都可以 fork 项目到自己的目录, 甚至还可以继续衍生出更多项目, 项目之间的通过 pull、push request 进行代码合并。 一个项目可以有多个上游项目, 也可以有多个下游项目, 它们指向形成一种关系.

1.1 Fork原理

  • Fork 其实不是一个新东西, 当我们在gitlab上点击Fork的时候, gitlab只是将项目克隆(git clone)到个人目录。

1.2 适用场景

  • 适合开源项目。开源项目需要接受任何开发者的代码共享, 无需给他们正式的代码库的写权限
  • 适合大型的,自发性的团队。 fork 工作流可以提供灵活的方式来安全协作

1.3 工作方式

fork工作流

  1. Fork: 一般通过服务器页面进行Fork, 创建一个拥有所有权的拷贝
  2. 克隆项目到本地, 新建功能分支, 提交自己的代码, 然后推送到远程版本库
  3. 然后发起将功能分支 并到上游(upstream)项目的Merge Request请求;
  4. 上游项目的所有者决定是否合并你的代码

1.4 代码检测

stream)项目的Merge Request请求;
4. 上游项目的所有者决定是否合并你的代码

1.4 代码检测

一般开源项目都会严格审验每个 提交,Gitlab支持在每个提交后,对他跑一些集成测试,进行一些讨论和 回顾。主要检测代码是否经过了测试、分支代码是否冲突

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值