项目开发流程系列
- 项目开发混淆从初识到理解
- 项目开发代码分支管理
博客创建时间: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区别
- github-flow只有一个长期分支master
- github-flow没有release分支,需求功能直接在feature分支上测试完毕merge到master,然后再master分支上进行发布
- 每次feature分支merge到master上时可能会有冲突,这要求在feature发布前需要合并一线master代码到feature上,进行提测测试。
总结
github_flow模式的工作流一般更贴近日常开发工作,根据自身项目的发布特点可以进行差异化的调整,适合自己的才是最好的。
相关链接:
- 项目开发混淆从初识到理解
- 项目开发代码分支管理
扩展链接:文章来源:https://www.toymoban.com/news/detail-403441.html
- Material Design UI方案使用讲解
- Material TextInputLayout使用详解
博客书写不易,您的点赞收藏是我前进的动力,千万别忘记点赞、 收藏 ^ _ ^ !文章来源地址https://www.toymoban.com/news/detail-403441.html
到了这里,关于项目开发代码分支管理的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!