场景: 前端应用会跟随工作宝版本迭代, 在dev分支测试稳定后, 会合并到master分支, 并使用tag标记应用版本和对应的工作宝版本
tag规范: v{APP_version}@{GZB_version..., 这时候每个成员在自己的feature分支独立开发
大功能开发: 大功能开发跨越周期比较长, 需要多次迭代才会稳定....方便跟踪历史记录, 也免于干扰dev分支的迭代和发布
命名规范
feature/name: name是功能名称
feature/GZB_version: 这也是团队常见的模式, 当无法使用一个功能名称来描述时...当要发布一个工作宝对应的版本时(或者一开始开发时)从dev分支checkout出一个开发分支,后续需要对外发布时,将dev分支合并到release分支, 并打上版本tag....这一种使用策略. gzb后端在使用, 为了配合后端工作, 我们也推荐使用这种方式
何时创建:
开启GZB新版本开发任务时(推荐)
向外发布第一个版本时
何时合并:后面dev有版本发布都要合并到release