GIT Workflow
作为项目代码版本管理,在团队中不同成员工作成果合并并发布的方式不同,对分支的使用(工作流)也不同
记录一下个人理解常见的几种方式
git wordflow
适用于:固定版本发布日期周期的团队(多个功能一次性上线)
分支情况:
- master分支
- dev分支
-
- 提测功能测试完成之后合并到release分支
- release分支
-
- 预发布环境,可能预发布后还有新的小bug 继续修复 稳定后合并到master分支
- feature分支(业务开发分支)
-
- 从dev分支新建
-
- 开发完成之后合并到dev分支
git 迅捷wordflow
适用于:按单个功能独立上线 随时上线的团队
分支情况:
- master分支
-
- 新功能更新后,需要把最新代码合并回dev分支 保持最新代码节点
- dev分支
-
- 不能从dev分支合并到master分支
- feature分支(业务开发分支)
-
- 从master分支新建
-
- 开发完成之后合并到dev分支
-
- 测试完成之后 变基到master 分支
-
- 变基成功之后 合并到master分支
github workflow
在开源项目中更常见的工作流方式,以Pull Request
为核心。
- 从master创建分支,开发代码,当
功能/bug 完成
或者需要协助/团队讨论
时候发起PR请求 - 任意成员可以评论 回复 对代码进行审计和共同思考
- 功能完成之后,管理权限允许合并到master分支中
扫描二维码,分享此文章