一种比较清晰的 多任务并行开发 的git工作流

原创
09/26 10:20
阅读数 118

从哪个分支上切出来的, 最后就合并到哪个分支

hotfix/xxx  <---> master <---> feat/xxx <---> dev/xxx <---> dev/xxx-name

分支合并不跨层, master不能合入dev, dev也不能合入master, 需要使用feat作为桥梁

 

线上主分支 master  

该分支直接对标线上, 只能合并 feat/xxx 和 hotfix/xxx的分支, 所有合入的分支必须经过完整测试

每次该分支的更新对应一次上线或者线上修复

线上修复分支 hotfix/xxx

由master切出

只用于修复线上问题, 修复后经测试合入master

预上线分支 feat/xxx

由master分支上切出来

在接到新需求后, 作为功能基础分支, 该分支为预上线和稳定的开发测试分支

只接受dev/xxx的合并, 且在该分支上合并master更新其他新功能的代码, 因为master上的代码都是经过了测试的, 一般尽量不要合并其他的feat/xxx

该分支对标测试的稳定环境, 最终测试完成后, 将该分支合入master, 如果多个 并行需求需要相互依赖, 那应该合并的是该分支, 而不是dev/xxx, 因为dev/xxx更新太过于频繁, 而该分支为稳定版, 且应该通过一部分测试

主开发分支 dev/xxx

从feat/xxx上切出来

该分支为开发分支, 改动比较频繁, 开发人员在从该分支上切出自己的开发分支开发, 用pr和mr的方式提交代码

该分支作为比较新的测试环境, 每天更新, 不建议作为测试环境, 因为变化太快了

个人开发分支 dev/xxx-name

从dev/xxx切出来

个人开发分支, 具有标示性, 在该分支上开发代码合并进入dev/xxx

 

解决的问题

多需求并行时的开发和测试

每个需求对应一个开发标示或者版本号, 比如三个需求 a,b,c并行,  c作为基础功能, a,b都需要使用, 但是a,b可独立开发

此时从master上切出 feat/a, feat/b, feat/c三个分支

从 feat/a 切出 dev/a,  开发者从dev/a中切出自己的开发分支 dev/a-one

从 feat/b 切出 dev/b, 开发者从dev/b中切出自己的开发分支 dev/b-two

从 feat/c 切出 dev/c, 开发者从dev/c中切出自己的开发分支 dev/c-three

 

首先进行基础开发, 在dev/c能够提供基础功能时, 合入feat/c, 供其他分支使用

对于feat/a, feat/b, 需要合并feat/c来引入c的功能, dev/a, dev/b合并对于的feat分支, 开发人员合并dev/xxx 引入新功能

由于每个feat/xxx都有自己的标识, 可以使用该标识来区分和下发代码

在预上线前feat/xxx分支需要各自进行测试, 最后测试完成后合入master

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部