三种常见的git workflow

git-flow

git flow 介绍

git flow的完整模型图如下：

git-flow分支模型可以将分支branch分为两大类

在git-flow工作流模型中，核心分支main和develop是常驻分支。

main分支：长期/稳定分支，HEAD永远指向一个可发布的状态。
develop分支：长期存在的开发主分支，HEAD指向最新的、已经开发完成（可能未经完整测试）的状态。 develop分支是开发新特性的基础分支。当要开发一个新特性时，从develop分支checkout一个feature/xxx分支，开发完成后，在合并会develop分支。 develop分支上的代码会包含未被完整测试的代码，因此不可直接用于发布。

辅助分支都是临时分支，使用完毕后就会被删除。

feature/xxx: 开发新功能特性的分支，从develop分支checkout而来；开发完成后，或者merge回develop分支（明确该功能会被加入即将发布的版本），或者被丢弃。然后feature/xxx就被删除。
release/xxx: release分支用于准备一个新的生产版本，release分支从develop分支而来，在release分支上修复测试过程的bug并被完成测试通过后，merge会develop分支或master分支。然后release/xxx分支被删除。即release在提测和回归阶段使用。 hotfix分支用于对线上Bug进行热修复
hotfix/xxx: hotfix分支用于对线上需要立即修复的严重Bug进行热修复，hotfix/xxx分支从master分支checkout而来，修复、测试完成后必须merge到develop分支和master分支。

从develop分支checkout出来一个feature/xxx分支，
在feature/xxx分支进行特性开发和自测。
开发完成后，从feature/xxx分支将功能merge到develop分支。（需要做CodeReview），删除feature/xxx分支
从develop分支checkout一个release/xxx分支，用于测试和回归。
测试通过后，release/xxx合并回develop分支（如果还不能直接发布）或者master分支（达到可发布的状态）；删除release/xxx分支。hotfix
从master分支checkout一个hotfix/xxx分支。
在hotfix/xxx上做Bug修复，修复完成（测试完成）后，merge到develop分支和master分支。

github flow官方介绍

github flow的分支模型图比较简单

只有个主干/长期分支，master. 专门配合”持续发布“使用。

github flow一般配合没有定制化的持续发布场景使用。github flow发布的都是master上版本，要么你选择一个不包含新特性的、相对稳定的版本；要么你选择一个包含更多功能的，相对不稳定的版本。

在github-flow模型中，一般只包含一下两类分支：

master分支：长期分支，master分支的HEAD指向一个包含最新开发完成的、相对稳定的状态。所有开发（测试）完成的代码都会合并到master分支上。所有的发布版本都从master上创建。
feature/xxx分支：功能特性开发分支。开发（测试）完成后merge到master分支。

gitlab-flow 官方介绍

gitlab-flow 细分为两种子模型（面向不同的场景或阶段）

基于环境的的分支模型——面向持续发布：在master分支外，引入Pre-Production、Production分支用于维护发布在不同环境上的代码。
基于版本的分支模型——面向版本发布：在master分支外，引入release/xxx（或stable/xxx）用于管理不同版本的代码（如release/v2.0.x）。

结合具体的场景，两种分支模型可以单独使用，也可以一起使用。

master分支：开发基础分支，HEAD指向最新的、已经开发完成（可能未经完整测试）的状态。
release/xxx分支：发布分支，长期存在。建议每一个稳定的版本创建一个release分支。创建后，只有向后兼容的提交才可以merge到这类分支，并且需要更新小版本号。

开发新特性

0 人点赞