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分支中
