关于Git协同工作流流的思考

业界主流的协同工作流: Git Flow， GitHub Flow, GitLab Flow

工作流介绍: http://www.ruanyifeng.com/blog/2015/12/git-workflow.html

工作流的本质要解决:

不同的团队能够尽可能地并行开发。

不同软件版本和代码的一致性。

不同环境和代码的一致性。

代码总是会在稳定和不稳定间交替。我们希望生产线上的代码总是能对应到稳定的代码上来。

基本上述的四个事儿，上述的工作流大都是在以建立不同的分支，来做到开发并行、代码和环境版本一致，以及稳定的代码

软件开发的工作模式:

   以微服务或是 SOA 为架构的方式: 服务小, 适合用GitHub Flow的方式

  以 DevOps 为主的开发流程 : 迭代快, 无需维护过多版本分支， 适合用GItFLow模型

协同工作的本质: 不是怎么玩好代码仓库的分支策略，而是玩好我们的软件架构和软件开发流程， 好的软件架构和自动化软件生产和运维流程, 能简化协同工作流

我们基于微服务又兼具有DevOps 流程的开发流程, 适合用GitFLow模型, 模型改动如下:

master ------- 主分支 任何时候在这个分支都是稳定的可发布的

dev --------- 开发分支 用于日常开发，存放最新的开发版

test -------- 测试分支 用于测试使用

release ----- 预发环境[考虑是否需要]

feature-xxxx ---- 功能分支[功能并行使用]

hotfix-xxx ------ 修复分支

tag: VX.Y.Z X: 大版本一般大改动 Y：功能改动 Z: 功能完善 如: V1.1.2

开发流程:

新需求开发:

1、从master拉出feature-xxxx 分支

2、基于feature-xxxx分支开发

3、开发完成后feature-xxxx合并到dev进行开发联调

4、联调通过后, 合并test分支进行测试

5、测试过程bug在 feature-xxx修复, 并合并到 dev 和 test中

6、测试通过后，合并到master 打包上线 [预发环境是否考虑]

7、bug 修复基于master分支

8、上线需打tag

重点保证master稳定随时可上线