git-flow

git-flow 简介

git flow 介绍

git flow的完整模型图如下：

分支介绍

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

• 核心分支： main、develop
• 辅助分支： feature/xxx, hotfix/xxx, release/xxx

核心分支

在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分支。

操作流程

开发新特性

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

github-flow

github-flow 简介

github flow官方介绍

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

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

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

分支介绍

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

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

操作流程

开发新特性

1. 从 master分支checkout一个feature/xxx分支
2. 在feature/xxx分支上做开发，
3. 开发完成并测试ok后，合并到master分支。hotfix。github-flow面向的一般是持续发布的场景，比较少需要做hotfix。

gitlab-flow

gitlab-flow 简介

gitlab-flow 官方介绍

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

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

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

基于环境的的分支模型——面向持续发布

分支介绍

1. master分支： 开发基础分支，HEAD指向最新的、已经开发完成（可能未经完整测试）的状态。
2. pre-production分支: 预发布分支，有master分支checkout而来，可以用于做测试验证。经过完整测试后，合入production分支。
3. production分支：生产环境分支，长期分支。从pre-production分支checkout而来。

基于版本的分支模型——面向版本发布

分支介绍

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

操作流程

开发新特性

1. 从master分支checkout一个feature/xxx分支。
2. 在feature/xxx上开发，自测。
3. 自测ok后，合入master分支。
   基于环境的的分支模型：
4. 从master分支checkout一个pre-production分支，（如果已存在直接merge）， 进行提测。
5. 提测通过，合并到production进行生产环境发布。
   基于版本的分支模型：
6. 从master分支checkout一个release/xxx分支，在release/xxx上提测，打标签。
7. 提测通过后用release/xxx上的分支上的版本发布。