Git Best Practice All In One
git workflow
本地开发环境:
开发人员自测的,可以是自己本地部署的静态服务器,当然也可类似是运行 npm server类似的环境,本地环境运行的代码可以是任何分支的
dev开发环境:
这个环境是用开发分支dev产出的代码来部署的,唯一的公用的
测试&预发布环境:
这个环境是用开发分支release产出的代码来部署的,唯一的公用的
线上生产环境:
这个环境是用开发分支master产出的代码来部署的,唯一的公用的
git 分支模型
- 所有的分支都是基于master分支检出
master :保护分支,对应的就是生产环境的分支
release:保护分支,所有开发完成的分支会申请合并到release分支,提供给测试人员测试
feature--名字拼音缩写:功能分支,具体功能开发,( 名字拼音缩写 ,方便定位某个开发人员,快速解决冲突问题,feature-fe-monitor-xgqfrms 或 feature/fe-monitor-xgqfrms)
dev:开发分支 & 脏分支( 不要 merge 到 feature 分支),对应的是大家共用的开发环境,上面的代码会部署到一个公共的开发环境,供开发人员做自测,应付一些日常、非日常的调试
hotfix-:bug紧急修复分支,可以直接合并到master,
(假如release合并了几个feature分支,正在测试的情况下,发现需要紧急修复的buf,紧急修复测试完毕后,可以直接合并到master,如果合并到release,在由release合并到master,那些正在测试的功能或者还不准备上线的功能就会跟着直接上线了)
- 工作流程
接到需求文档,做评审后分配个每个人或小组的功能开发,相关人员从master 检出 feature 功能分支
开发的时候除了会在本地测试,有需要还会合并到 dev分支,在公共的开发环境去自己做测试
因为在开发功能的期间,可能有 hotfix完成合并到master,合并代码的时候习惯 merge一下master,防止冲突等
自测完成之后,申请合并到 release,合并成功后部署到测试环境后通知测试人员做测试
测试通过后,release 申请合并到master,准备上线
如果测试不通过,在功能分支修改后重新 merge
上线成功稳定后删除对应的功能分支,dev 合并最新的master分支
一线大厂 git 分支流程
https://www.infoq.cn/article/EaC4c6yiJrzZ_Gtaf9Ne
https://zhuanlan.zhihu.com/p/45157955
http://yr87.cn/jxadd/article_detail/16393
https://biolxy.github.io/2018/12/04/Git-develop-SOAP/
refs
https://segmentfault.com/a/1190000024453209
music
xgqfrms 2012-2020
www.cnblogs.com 发布文章使用:只允许注册用户才可以访问!