持续交付之基于Git Flow代码分支策略实践

前言 高效的持续交付体系,必定需要一个合适的代码分支策略。采用不同的代码分支策略,意味着实施不同的代码集成与发布流程,这会影响整个研发团队每日的协作方式,因此研发团队通常需要很认真地选择自己的策略。 主干开发(TBD) 主干开发是一个源代码控制的分支模型,开发者在一个称为 “trunk” 的分支(Git 称 master)中对代码进行协作,除了发布分支外没有其他开发分支。 Google 和 Facebook 都是采用“主干开发”的方法,代码一般直接提交到主干的头部,这样可以保证所有用户看到的都是同一份代码的最新版本。大多数时候,发布分支是主干某个时点的快照。以后的改 Bug 和功能增强,都是提交到主干,必要时 cherry-pick (选择部分变更集合并到其他分支)到发布分支。与主干长期并行的特性分支极为少见。 主干开发的分支策略虽然有利于开展持续交付,但是它对开发团队的能力要求较高。 主干开发的优缺点如下表所示  特性开发 Git Flow Git Flow 模型在 2011 年左右被大家当作了推荐的分支模型,至今也还有项目团队在使用。  主分支:master,稳定版本代码分支,对外可以随时编译发布的分支,不允许直接Push代码,只能请求合并(pull request),且只接受hotfix、release分支的代码合并。gitlab上做权限限制(开发组长)。 热修复分支:hotfix,针对现场紧急问题、bug修复的代码分支,修复完后合并到主分支、开发分支。 发版分支:release,版本发布分支,用于迭代版本发布。迭代完成后,合并dev代码到release,在release分支上编译发布版本,以及修改bug(定时同步bug修改到dev分支)。测试完成后此版本可以作为发版使用,然后把稳定的代码push到master分支,并打上版本标签。 开发分支:dev,开发版本分支,针对迭代任务开发的分支,日常开发原则上都在此分支上面,迭代完成后合并到release分支。 特性开发分支:dev-*,开发人员可以针对模块自己创建本地分支,开发完成后合并到dev开发分支,然后删除本地分支,涉及多人协同开发的可以push到服务端。 产品分支策略 基本情况 尚不具备主干开发能力(开发团队系统设计和开发能力非常强) 有预定的发布周期 需要严格执行发布周期 分支管理 在代码分支管理的层面上,V3C团队源代码分为五个主要分支: Master:主分支,稳定版本 Hotfixes:补丁分支,稳定/预览版本或现场问题的应急处理 Release:预览分支,Bata版/测试与bug修复 Develop:开发分支,常规功能的新增与调整 Feature:特性分支,同时可以有多个特性分支,代码合并后结束; 分支合并时间 主分支:每个季度一个正式版本,于每个季度末合并发版;由预览分支、补丁分支合并;不允许直接Push代码,只能合并; 补丁(热修复)分支:随现场使用情况而定,可以打临时版本或补丁;由主分支替换而来,修复完后合并到主分支、开发分支; 预览分支:版本发布分支,用于迭代版本发布。每日测试打版验证,由开发分支合并而来;测试完成后此版本可以作为发版使用,然后把稳定的代码push到master分支,并打上版本标签。 开发分支:不对外发布,可以由其他分支合并而来;针对迭代任务开发的分支,日常开发原则上都在此分支上面,迭代完成后合并到release分支; 特性分支:不直接打版,可以由开发分支合并而来;新功能稳定后合并到开发分支 初始化配置 分支初始化配置指令: 1. git checkout -b hotfix origin/hotfix //创建hotfix分支 2. git branch --set-upstream-to origin/hotfix //关联到远端hotfix分支 3. 4. git checkout -b dev origin/dev //创建dev分支 5. git branch --set-upstream-to origin/dev //关联到远端dev分支 6. 7. git checkout -b release origin/release //创建release分支 8. git branch --set-upstream-to origin/release //关联到远端release分支 迭代开发 紧急bug修复 预览版(Bata) 稳定版(正式版) 紧急bug修复流程 1. git checkout hotfix //切换到hotfix分支 2. git pull gitlab master //更新从远端主分支更新代码,会同时更新本地、远端的hotfix分支 3. //改bug... 4. git commit -a -m "~修复client心跳检查接口null引用 #V3C-666" //提交代码 5. git push //push 代码到远端hotfix分支 6. 7. //bug改完了,编译测试验证,合并代码: 8. //1.合并代码到dev分支 9. git checkout dev //切换到dev分支 10. git pull //跟新代码 11. git merge --no-ff hotfix //把hotfix分支合并到当前dev分支 12. git commit -a -m “merge hotfix branch” //提交代码到本地dev分支仓库 13. git push //push 代码到服务器端dev分支 14. //2. 合并代码到主分支,在gitlab上操作,发送Push Request 日常特性开发 推荐日常开发中多创建本地特性分支,标准流程如下: git checkout -b dev-rpccompress dev //创建特性分支git commit -a -m”注释” //修改代码并提交git checkout dev //切换到dev分支git pull //从远端更新dev分支代码git merge --no-ff dev-rpccompress //合并特性分支到devgit push //推送git branch -d dev-rpccompress //删除特性分支 Git工作流 工作区:就是你在电脑里能看到的代码库目录。 暂存区:英文叫stage, 或index。一般存放在 ".git目录下" 下的index文件(.git/index)中,所以我们把暂存区有时也叫作索引(index)。这个分区我们平时使用较少,不做多介绍。 本地仓库(版本库):工作区有一个隐藏目录.git,这个不算工作区,而是Git的版本库。我们在工作区修改的代码通过Commit指令提交到版本库。 服务端仓库(远端版本库):服务端的版本库,本地版本库通过push指令把代码提交到远端版本库。 Git的分支创建、切换、删除都非常快,分支是Git的必杀技特性。要充分利用Git的分支特性,特别是个人开发时多使用Feature分支。 上图是一个普遍采用的分支管理方案 Git常用指令 代码合并 1. git merge --no-ff hotfix 2. 3. --no-ff :禁用快速合并,合并后会保留原分支的commit历史记录,如右图左侧图示,推荐的用法。 4. 5. git merge 撤销(未push) 6. git checkout 【行merge操作时所在的分支】 7. git reset --hard 【merge前的版本号】 Git撤销&回滚操作 撤销所有本地改动代码: git checkout . #撤销本地所有修改,未提交(暂存区),可以指定文件$ git reset --hard HEAD #撤销本地所有修改git commit 后撤销(reset:本地仓库撤销commit,不会影响远程仓库)git reset --hard #回滚到某个变更集版本,针对已commit,未pushgit push撤销(revert,用一个新的提交来覆盖当前版本)git revert -m #回滚已经push的变更集,完了后push即可git push 注意:reset、revert都会导致指定后的变更都没有了,慎重使用。 拣选指令 拣选指令-- git cherry-pick 其含义就是从众多的提交中选出一个提交应用在当前的工作分支中.该命令需要提供一个提交ID作为参数.操作过程相当于将该提交,导出为补丁文件,然后在当前HEAD上重放,形成无论内容还是提交说明都一致的提交. git cherry-pick git cherry-pick 6bbf6b4 cc63c15 #可以指定多个CommitIDgit log -n20 #查看日志,获取CommitID Git代码提供规范 基本原则 Git 代码完整提交正确姿势,建议先 Commit,再 Pull,最后 Push。 代码提交前,保证本地编译通过。 代码提交时,保证代码、文件完整提交,不要把本地测试代码、配置提交上去了。 代码每次独立的功能、模块修改,都 Commit 到本地(不急每次都 Push) 较大的模块开发或修改建议创建本地特性分支,完成后合并到 dev,特性分支不可 push 提交注释规则 格式: [前缀:+-*~][正文] #[相关youtrack任务编号] + 添加功能/模块,前缀“+”;- 删除功能/模块,前缀“-”;* 修改、优化功能/模块,前缀“*”;~ 解决Bug,前缀“~”; 示例 +添加登录拦截校验功能 #V3C-1240-删除登陆弹出框提示 #V3C-1241*修改登陆校验逻辑 #V3C-1242~修复登录正确提升不准确缺陷 #V3C-1243 关联的  youtrack 任务单/缺陷单编号,例如:“V3C-124”;

尚美源码教程库提供精美的网站源码教程,小程序、公众号、H5、APP、游戏、直播、支付、区块链、商城、影音、小说等源码信息大全。
用户必须遵守《计算机软件保护条例(2013修订)》第十七条:为了学习和研究软件内含的设计思想和原理,通过安装、显示、传输或者存储软件等方式使用软件的,可以不经软件著作权人许可,不向其支付报酬。鉴于此条例,用户从本平台下载的全部源码(软件)教程仅限学习研究,未经版权归属者授权不得商用,若因商用引起的版权纠纷,一切责任均由使用者自行承担,本平台所属公司及其雇员不承担任何法律责任。
尚美源码教程库 » 持续交付之基于Git Flow代码分支策略实践
赞助VIP 享更多特权,立即登录下载海量资源
喜欢我嘛?喜欢就按“ctrl+D”收藏我吧!♡