Git Best Practice All In One

时间:2023-03-09 16:04:56
Git Best Practice All In One

Git Best Practice All In One

git workflow

Git Best Practice All In One

本地开发环境:

开发人员自测的,可以是自己本地部署的静态服务器,当然也可类似是运行 npm server类似的环境,本地环境运行的代码可以是任何分支的

dev开发环境:

这个环境是用开发分支dev产出的代码来部署的,唯一的公用的

测试&预发布环境:

这个环境是用开发分支release产出的代码来部署的,唯一的公用的

线上生产环境:

这个环境是用开发分支master产出的代码来部署的,唯一的公用的

git 分支模型

Git Best Practice All In One

Git Best Practice All In One

Git Best Practice All In One

  1. 所有的分支都是基于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,那些正在测试的功能或者还不准备上线的功能就会跟着直接上线了)

  1. 工作流程

Git Best Practice All In One

接到需求文档,做评审后分配个每个人或小组的功能开发,相关人员从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


Git Best Practice All In One

xgqfrms 2012-2020

www.cnblogs.com 发布文章使用:只允许注册用户才可以访问!