基于git flow管理策略制定

基于git flow管理策略制定

介绍git flow

一切起源于作者Vincent Driessen发的文章A successful Git branching model文章提供了一种git版本管理的具体策略。
以下为git flow的流程图：

分支管理介绍

1. Master分支
   最重要的分支，需要能够达到发布到生产环境的代码要求，理论上不允许任何人直接修改，只能从其他分支（Release分支和Hotfix分支）进行合并
2. Develop分支
   主要开发分支，开发人员直接在这条分支上进行修改，也可以通过开发人员拉取的Feature分支合并而来，需要合并到Release分支进行测试
3. Feature分支
   开发分支，在进行功能点的开发时，拉取Develop分支进行开发，开发完成后合并回Develop分支，然后销毁
4. Release分支
   测试用分支，当要发布新版本时，拉取Develop分支，进行测试和修改bug，测试修改完成后合并到Develop分支和Master分支
5. Hotfix分支
   当Master分支发布之后出现bug需要紧急修复时，直接从Master分支拉取，修复后合并到Devlop分支和Master分支

具体使用策略

1. Master分支
   绝对纯洁的分支，要求代码达到发布到生产环境的要求，每次的合并请求在允许后都需要打tag标明版本
2. Devevlop分支
   允许开发人员进行修改提交的分支，允许直接在这条分支上提交修改，但最好还是能够在拉取的Feature分支上完成功能点的开发后再合并来进行修改。这条分支的代码需要在拉取到Release分支完成测试
   
3. Feature分支
   在进行新功能点的开发时，从Develop分支拉取，在Feature分支上进行开发，完成开发并合并到Develop分支上后销毁
   
4. Release分支
   Release代表预发布分支，当需要发布新版本时，从Develop分支拉取进行测试，出现bug时直接在这条分支上完成修改，然后合并到Develop分支和Master分支上
   
5. Hotfix分支
   当Master分支上的代码出现bug时，需要紧急修复，从Master分支上拉取，在完成修复后合并到Develop分支和Master分支上
   

具体的角色权限管理

目前需要使用gitlab的人员有开发人员权限分为两级：普通开发人员（Developer组）和代码审核人员（Maintainer组）。因为目前规模比较小，对Feature分支进行修改，删除Hotfix分支，作为预备方案。

他们各自允许的操作如下：

Developer：从dev/release分支拉取各自的临时分支，在自己负责的临时分支上进行push，在完成开发后merge到dev/release分支，发起merge时勾选merge成功销毁临时分支选项。

Maintainer：Developer的所有权限。在dev/release分支上进行push（为了方便，实际上是不应该允许的），审核所有的merge请求。