【开源中国 APP 全新上线】“动弹” 回归、集成大模型对话、畅读技术报告”
想节后重新梳理公司代码的管理结构,想问下各位的结构是怎么样的,最好能图文说明下,特别是dev这个分支,到底需不需要真的有点迷。欢迎发表观点
不需要dev
理论上只要有
```
master
weekely/2019-01-24
feature/login
feature/list
这些分支即可。
feature对应各个子需求,weekely代表上线日期。任何一次merge都将old branch删掉。
开发过程是拉分支,然后开发,部署到开发环境测试,联调。之后部署到测试环境,联调。最后上线。
所以默认保留三个分支,master(生产环境)、test(测试环境)、dev(开发环境),
1、从master拉分支比如:dev_20190124_order(命名规则:dev_日期_业务名称)
2、开发,之后合并到dev分支,部署开发环境,自测联调(有问题在dev_20190124_order改,之后合并dev分支)
3、合并test分支,部署测试环境,联调(有问题在dev_20190124_order改,之后合并dev、test分支)
4、合并master分支,部署测试环境,联调(有问题在dev_20190124_order改,之后合并dev、test、master分支)
5、测试通过上线。删除分支,master合并到dev、test
6、打tag
不需要dev
理论上只要有
```
master
weekely/2019-01-24
feature/login
feature/list
```
这些分支即可。
feature对应各个子需求,weekely代表上线日期。任何一次merge都将old branch删掉。
开发过程是拉分支,然后开发,部署到开发环境测试,联调。之后部署到测试环境,联调。最后上线。
所以默认保留三个分支,master(生产环境)、test(测试环境)、dev(开发环境),
1、从master拉分支比如:dev_20190124_order(命名规则:dev_日期_业务名称)
2、开发,之后合并到dev分支,部署开发环境,自测联调(有问题在dev_20190124_order改,之后合并dev分支)
3、合并test分支,部署测试环境,联调(有问题在dev_20190124_order改,之后合并dev、test分支)
4、合并master分支,部署测试环境,联调(有问题在dev_20190124_order改,之后合并dev、test、master分支)
5、测试通过上线。删除分支,master合并到dev、test
6、打tag