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