阅读 602

git 开发流程 gitflow githubflow gitlabflow TrunkBase AoneFlow 以及持续集成

未完.....修正中

看到国内 大多数项目 默认都是 dev 为主分支,分支众多,颇为混乱。颇为诧异。遂总结出本篇文章,持续修正。 TrunkBased 模型是持续集成思想所崇尚的工作方式,它由单个master分支和许多release分支组成,每个release分支在特定版本的提交点上从master分支创建出来,用来进行上线部署和 Hotfix。在 TrunkBased 模式中,没有显性的feature分支。

GitFlow 模型是若干模式的集大成者,包含一个master分支、一个develop分支、许多的feature分支、许多的release分支和 Hotfix 分支,以及许多繁琐的合并规则。

git flow

gitflow 是最早第一个提出的 git 工作流。虽然完备,但对于现在敏捷 持续集成分支构建。过于复杂。

适用于内部开发大中型项目。不适合微服务项目

【保留分支】

master 针对 master 的每次提交,都要迭代更新 tag 即里程碑。
develop 用于开发,中小项目 可直接在 develop 分支开发。不用 check 出 feature分支。
复制代码

【可选分支】

feature 用于同时开发多个 不同 功能。新建的功能分支 必须是描述性的名字,以便于别的开发人员查找和理解。
release 用于发布测试,名字基本上是release-tag号。 
	该分支相对稳定 不再接受新需求。发布即代表版本号定成功,
    发布成功后合并到 master 和 视情况合并到 develop。   
	这里不建议 release-加时间。一定要明确版本号。
    如业务需求改动,舍弃这次版本,不对 master 提交。
hotfix	用于修复紧急bug
patch 	用于修复功能缺陷
复制代码

【基本流程】

master -> develop -> master
master -> develop -> featrue -> develop -> master
复制代码

【标准流程】

master -> develop -> featrue -> develop -> release -> master
复制代码

【bug流程】

master -> hotfix -> develop
            ↓
          master 
复制代码

【优点】流程清晰可控。

【缺点】流程复杂,效率低。

参考地址1 参考地址2

github flow

github 开发是基于 pr (pull request)的自动化工作流。 这是因为开源项目, 大多参与人员,是没有权限直接提交更新代码。 需要 fork 到自己项目。修改后 提交 pr 到 原来的项目里。由原项目管理员审核 review代码 测试 merge 到 主分支。

简单理解就是 复制一份代码 到自己的项目里。然后你可以随便更新更改自己项目。改完 提交 pr 到原项目。避免所有人瞎改乱造。

不同公司方式可能不同,但都是通过 pr 形式。

【保留分支】

master 
	主要的开发分支。
    因为大多数 git server 都是 master 为主分支。所以以master 为主开发分支。便于理解和开发。
复制代码

【可选分支】

develop
feature
release
hotfix
patch
复制代码

【基本流程 && bug流程】

master -> fork代码 -> feature -> pr -> review代码 -> master
复制代码

【基于issue的开发 && bug流程】

认领issue-> master -> fork代码 -> 新建hotfix分支,修改issue对应 -> pr 指定 issue -> review代码 -> master
复制代码

【优点】安全可控。开源友好。

【缺点】流程复杂,非活跃项目效率低。

参考地址

gitlab flow

其实大多公司都是自建 gitlab。

【保留分支】

master
	master 默认是主要的开发分支,是最新的。
复制代码

【可选分支】

develop
feature
release
hotfix
patch
复制代码

【基本方式】

feature -> mr -> master -> production
复制代码

【多环境】

feature -> mr -> master -> pre-production -> production 
复制代码

【版本发布】

feature -> mr -> master -> stable
复制代码

production 方式适合程序集成发布项目。 stable 方式适合对版本迭代要求严格的项目。

对比 github flow 可以看出 加了 production 用来解决 github 对 master 时间不可控的问题。

【优点】清晰可控。开源友好。

【缺点】对比 github flow 增加了需要维护的分支。

参考地址

TrunkBased

主干开发是助力实现 持续集成 和 持续交付 的关键因素。开发团队的成员一天多次地将代码提交到主干分支

TrunkBased 和 github flow 是类似的

【保留分支】

master || trunk
	master 为主要测试开发分支
复制代码

【可选分支】

develop
feature
release
hotfix
patch
复制代码

【基本流程】

feature ->  master -> release
复制代码

【master 未更新 bug 流程】

fixbug -> master -> release
复制代码

【master 已更新 bug 流程】

不要直接在release 改。避免merge 操作麻烦。
release分支tag -> master fixbug ->  master cherry pick 到 release -> 更新tag 
复制代码

【feautre 未开发完 release】

使用 Feature Toggle
复制代码

【优点】持续集成,简单。

【缺点】只有一个主分支,并行开发麻烦。 比较适合快速迭代的微服务项目。

参考地址

Aone flow

阿里的AoneFlow,它基本上兼顾了 TrunkBased 的“易于持续集成”和 GitFlow 的“易于管理需求”特点,同时规避掉 GitFlow 的那些繁文缛节。

【保留分支】

master
复制代码

【可选分支】

develop
feature
release
hotfix
patch
复制代码

【基本流程】

master -> feature -> relase -> master
复制代码

【bug修复流程】

release || tag  -> fixbug -> master
复制代码

参考地址 总结:

从中我们可以看出,gitflow 不适用敏捷为主的项目。

gitflow 下,持续集成部署的项目,我们的 feautre 分支 需要频繁和并到 develop 。而我们并不能为 多个 feature 准备多个环境。 同时大量的 merge 耗费人力精力。

文章分类
后端
文章标签