Git
是当下最流行的版本管理系统,阮一峰在自己的博文中提到过:“如果你严肃对待编程,就必定会使用版本管理工具”。Git
操作是基于分支的,当下环境衍生出多种优秀的分支管理策略,其目的就是要保证不同分支各司其职,避免多人协作过程中代码冲突、代码版本出现问题。在日常迭代过程中,每个公司都有一套自己的分支管理规范,但万变不离其宗,都有Vincent Driessen
提出的Git flow
方法的影子。
基于Git flow
方法协作提交代码时,一般是基于一下分支:
分支名称 | 分支说明 | 分支时效 | 环境 |
---|---|---|---|
master | 与线上环境运行代码版本一致,需保证最高稳定性 | 主分支 | 线上生产环境 |
develop | 开发过程中成员操作分支(前后端对接调试阶段) | 主分支 | 开发环境 |
feature | 新功能分支,一般一个新功能对应一个分支,以避免后面一些不必要的代码冲突 | 临时分支 | |
release | 亦或者叫bugfix分支,修复测试环境Bug所用分支,建议一个Bug单独切一个分支,(测试阶段) | 实施分支 | 测试环境/压测环境/预生产环境 |
hotfix | 紧急修复线上BUG的时候使用的分支 | 临时分支 |
以下是Git flow
流程图:
这张图涉及内容较多,我们只需要关注两个分支,一个是master
分支,另一个是develop
分支,通过箭头可以看到,develop
分支是基于master
分支创建,在提交代码后,又重新回到了master
分支,这里体现的是,在迭代开始前,需要基于线上代码最新版本合并到开发分支,作为团队成员开发的公共分支。在使用Git
时,需要遵循一个原则:从哪里来,最后回到哪里去。
接下来我们需要关注的是feature
分支与develop
分支。在团队协作过程中,对于需求的开发,通常是采用一个成员负责一个功能点或者模块,那么就需要不同成员往develop
分支提交代码,即需要从develop
分支创建feature
分支开发新功能,编码自测完成后,再从feature
分支push(推送)到develop
分支,这同样遵循了以上规则。
在企业开发中,每次迭代往往定义一个版本号,release
分支与之对应。随时间线推进,到达迭代开发中的提测阶段,则需要将开发的新代码从develop
分支推送到release
分支,而后发布代码(CI/CD)到测试环境供测试验证。
当测试提出缺陷时,似乎我们需要排查一下自己代码中是否存在问题。如果是,那么我们需要基于测试环境的release
分支代码版本做修改,此时,我建议基于release
分支去创建一个bugfix
分支用于修复代码中的问题。修复完毕后再将bugfix
分支的代码推送到release
分支,push完成后,将bugfix
分支删除,确保一个bugfix
分支只做一件事。
注意:在合并前需要确保release
分支代码是最新版本,建议在push到其他分支前update一下分支到最新版本,因为不止你一个可怜人在修复Bug。
如果你所在的公司使用Git flow
的标准流程。develop
分支承担了两个“角色”:“写Bug”和“改Bug”。则同样可以从release
分支更新最新代码后,将release
分支代码merge(合并)到develop
分支。再基于develop
分支修改代码,push到develop
,而后切换到release
分支,更新到最新版本,merge develop
分支到release
分支即可。
测试完成、熬到上线、喜大普奔。上线时需要将release
分支代码推送到master
,同样的道理,在推送前需要将master
分支代码更新到最新版本,release
分支合并master
分支代码,再切换到master
分支合并release
分支代码。
上线时需要整理迭代涉及的配置项更新、迭代变更
SQL
脚本、历史数据处理数据SQL
脚本、静态资源等整理出来,发布执行到线上环境,此过程不在本文中赘述。
紧急!震惊!线上代码失去公信力了吗?
当生产环境用户反馈了一个问题,确认为代码缺陷时,需要基于最新的master
分支创建hotfix
分支去修复线上bug,修复完毕后,从hotfix
分支按上述release
分支推送到master
分支流程推送代码到master
分支即可。
你并不能确定目标分支代码是否有变更。
提高团队协作效率,人人有责。