多人协作流程与规范

 

一、工作流

选用GitFlow工作流模式作为协作流程规范。

1、gitflow

Gitflow工作流定义了一个围绕项目发布的严格分支模型。虽然比功能分支工作流复杂几分，但提供了一个健壮的用于管理大型项目的框架。

Gitflow为不同的分支分配一个很明确的角色，并定义分支之间如何和什么时候进行交互。 除了使用功能分支外在做Bug修复、维护和预发布时也使用各自的分支。同时通过Pull Requests、隔离实验性开发实现更高效的协作。

 

2、工作方式

Gitflow工作流仍然用一个远程仓库作为所有开发者的交互中心。和其它的工作流一样，开发者在本地工作并push分支到中央仓库中。

 

二、主要分支: Master、Develop

Gitflow工作流使用2个分支来记录项目的历史。master分支存储了正式发布的历史，而develop分支作为功能的集成分支。 这样也方便master分支上的所有提交分配一个版本号。

• Master(绿色): 永远处在 production-ready 状态
• Develop(橙色): 最新的下次发布开发状态

 

三、支援性（临时）分支:

1、Feature功能分支

每个新功能位于一个自己的分支，这样可以push到中央仓库以备份和协作。 但功能分支不是从master分支上拉出新分支，而是使用develop分支作为父分支。当新功能完成时，合并回develop分支。 新功能提交应该从不直接与master分支交互。

Feature(蓝色): 开发新功能都从 develop 分支出来，完成后 merge 回 develop

2、release发布分支

一旦develop分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从develop分支上fork一个发布分支。 新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上—— 这个分支只应该做Bug修复、文档生成和其它面向发布任务。 一旦对外发布的工作都完成了，发布分支合并到master分支并分配一个版本号打好Tag。 另外，这些从新建发布分支以来的做的修改要合并回develop分支。

使用一个用于发布准备的专门分支，使得一个团队可以在完善当前的发布版本的同时，另一个团队可以继续开发下个版本的功能。 这也打造定义良好的开发阶段（比如，可以很轻松地说，『这周我们要做准备发布版本4.0』，并且在仓库的目录结构中可以实际看到）。

常用的分支约定：

用于新建发布分支的分支: develop
用于合并的分支: master
分支命名: release-* 或 release/*

Release(黄色): 准备要 release 的版本，只修 bugs。从 develop 分支出来，完成后 merge 回 master 和 develop

3、hotfix维护分支

维护分支或说是热修复（hotfix）分支用于生成快速给产品发布版本（production releases）打补丁，这是唯一可以直接从master分支fork出来的分支。 修复完成，修改应该马上合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。

为Bug修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。 你可以把维护分支想成是一个直接在master分支上处理的临时发布。

• Hotfix(灰色): 等不及 release 版本就必须马上修 master 赶上线的情况。会从 master 分支出来，完成后 merge 回 master 和 develop