项目开发代码分支管理

luo_boke

已于 2022-08-28 22:52:40 修改

阅读量3k

点赞数 4

分类专栏： Android基础文章标签：分支管理 git-flow github-flow

于 2022-08-28 16:48:52 首次发布

本文链接：https://blog.csdn.net/luo_boke/article/details/126570463

版权

Android基础专栏收录该内容

9 篇文章 1 订阅

订阅专栏

项目开发流程系列

分支管理

前言
版本发布类型
Git-Flow
GitHub-Flow
总结

博客创建时间：2022.08.27
博客更新时间：2022.08.28

以Android studio build=7.0.0，SDKVersion 31来分析讲解。如图文和网上其他资料不一致，可能是别的资料版本较低而已。

前言

在团队开发中，当有多个需求版本进行并发并行时，选用合适自己的分支管理策略将变得更加必要和急迫，我们来一起认识分支管理的git_flow和github-flow工作流吧。

版本发布类型

在进行分支管理时不得不科普一下主干发布 和 分支发布

主干发布
的特点就是项目的功能开发工作在master分支上，代码开发完毕后，经过功能测试没有问题后，在master主分支上打release标签作为项目代码版本进行发布。是效率最高的一种项目开发方式。
发布完毕后，master主分支还继续做项目下一个功能版本的开发工作。如果线上代码出现bug，那么就在master分支上修复就可以了。

特征

项目所有主要/核心功能代码的开发工作都在master分支上，开发完毕后，在master分支上进行集成测试。
项目代码测试通过后，通过打标签的方式，以标签的方式进行代码发布。
项目正常运行过程中出现bug，在master分支进行bug的修复工作，修复代码通过测试后，打标签发布。

优势：

项目代码发布前，需要进行主干集成测试，代码冲突易于提前发现
master主干代码安全稳定，每次测试通过后，都可以随时发布。
集成测试常见的配套措施：每日集成(编译部署测试)，代码检查，单元/接口/界面自动化测

劣势：
新功能代码在master主干上开发，若主干代码达不到稳定的标准，不可以进行项目发布master上主干开发有先后，有未完成的功能但又需要发布时，需要能隐藏未完成部分。为了避免以上情况，有三种缓解方法：

1)功能拆分，小批量频繁发布；
2) 后端先行，ui或功能入口发布；
3) 功能开发，配置决定功能

分支发布
项目的功能开发工作在master分支上，代码开发完毕后，经过功能测试没有问题后，从master主分支上切出一个release分支，作为项目代码版本发布的专用分支，而master分支还继续做项目下一个功能版本的开发工作。
如果线上代码出现bug，那么就在release分支上修复就可以了，修复后的代码最终要合并到主干上，只有非常严重的缺陷修复才会从master合并到release分支上。

优势：
主干开发的过程中，关于分支合并的工作量很少，所以整体比较简单，且更容易发布

劣势：
线上出现历史严重bug,需要在各该分支上各个修复，直接在master修复后同步到各分支容易有各冲突

Git-Flow

Git_flow是一种代码分支管理规范，其实它属于一种主干开发—主干发布类型。遵守的Git-Flow规范的分支分为两种，长期分支和短期分支。该工作流相对复杂，需要同时维护两个长期分支，开发中需要经常切换分支
在这里插入图片描述

长期分支
1. 主分支master

1. 线上所有功能代码所在，只读不可修改，对外发布的唯一分支。
2. 只能由hotfix或develop合并

2. 开发分支develop

1. 基于master 分支克隆，只读不可修改。
2.  feature分支从该分支拉出，开发完成后合并到develop
3. 分支上的功能经测试无误后，需要由该分支再次合并到master分支上。

短期分支
一旦开发完成就会合并到develop和master分支上，然后被删除。

1. 功能分支（feature branch）

1. 功能开发分支 , 基于 develop 分支克隆 , 主要用于新需求新功能的开发，属于临时分支
2. feature 分支可同时存在多个 , 用于团队中多个需求功能同时开发
3. 功能开发完毕并测试完成后合到 develop 分支。合并后此分支删除(谁合并谁删除)

2. 补丁分支（hotfix branch）

1. 基于 master 分支克隆 , 主要用于对线上的版本进行bug修复，属于临时分支
2. 修复完毕后，如果需要临时发版则需要打tag并推送到master/develop分支，如果不需要发版只需要推送到develop分支且不用打tag

3. 预发分支（release branch）

1. 用于提交给测试人员进行功能测试 , 测试过程中发现的 BUG 在本分支进行修复 , 修复完成上线后打tag并合并
2.从 develop 分支克隆，属于临时分支。提测完成后合并到master/develop分支，然后删除该分支(谁合并谁删除)。

GitHub-Flow

Github flow 是Git flow的简化版，专门配合”持续发布”。它是 Github.com 使用的工作流程。在持续发布模式下，master和develop分支其实差异不大，所以GitHub-Flow工作流只有一个长期分支master。
在这里插入图片描述
github-flow与git-flow区别