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