当前版本分为
dev(开发分支)
staging(测试分支)
pre-release(预发布分支)
release(生产分支)
发布版本 dev=>staging=>pre-release=>release
解决冲突 如果dev发生产有冲突,可以先让dev在本地 merge 一下 release 解决冲突后 push dev即可。
与其他版本也是一致.
需求分支
当项目有优化需求,bug修复,版本需求等过来时候.要做好版本分支管理, 比如同时来了a,b,c三个不同的需求,这时候可以从 release分支拉下来 三个分支 分别取名 a,b,c 然后在本地做开发。开发完成后 在本地的dev分支进行 合并 然后发布到测试环境进行测试 ,如果没有问题,则可以发布生产的时候直接用 优化分支去merge到生产环境
示例:
git fetch //更新下本地存储在远程仓库的代码,与远程仓库保持同步
git checkout release //切换分支到生产分支,准备建立优化分支
git pull origin release //更新下本地生产环境代码
git checkout -b dev_opt //以生产环境代码为基础创建一个 dev_opt分支。 我一般喜欢这样命名.看个人习惯吧.即可在本地代码进行开发.开发完成后
git checkout dev_zhenxqin => git mrege dev_opt //切换到自己的dev分支,合并你优化的代码,
git push origin dev_zhenxqin => 这里用平台(jenkins/蓝盾等)操作把dev_zhenxqin分支代码合并到staging分支,并部署/测试/产品检测完没问题后并同意发布生产环境/预生产/可先在本地看看有没有代码冲突
git checkout dev_opt => git merge release //在本地看一下有没有冲突 有的话先解决冲突。
git push origin dev_opt => 这里用平台(jenkins/蓝盾等)操作把dev_opt分支代码合并到release分支,并部署/测试/产品检测,至此发布完成