基于git flow管理策略制定
基于git flow管理策略制定
介绍git flow
一切起源于作者Vincent Driessen发的文章A successful Git branching model文章提供了一种git版本管理的具体策略。
以下为git flow的流程图：
分支管理介绍
- Master分支
最重要的分支，需要能够达到发布到生产环境的代码要求，理论上不允许任何人直接修改，只能从其他分支（Release分支和Hotfix分支）进行合并 - Develop分支
主要开发分支，开发人员直接在这条分支上进行修改，也可以通过开发人员拉取的Feature分支合并而来，需要合并到Release分支进行测试 - Feature分支
开发分支，在进行功能点的开发时，拉取Develop分支进行开发，开发完成后合并回Develop分支，然后销毁 - Release分支
测试用分支，当要发布新版本时，拉取Develop分支，进行测试和修改bug，测试修改完成后合并到Develop分支和Master分支 - Hotfix分支
当Master分支发布之后出现bug需要紧急修复时，直接从Master分支拉取，修复后合并到Devlop分支和Master分支
具体使用策略
- Master分支
绝对纯洁的分支，要求代码达到发布到生产环境的要求，每次的合并请求在允许后都需要打tag标明版本 - Devevlop分支
允许开发人员进行修改提交的分支，允许直接在这条分支上提交修改，但最好还是能够在拉取的Feature分支上完成功能点的开发后再合并来进行修改。这条分支的代码需要在拉取到Release分支完成测试 - Feature分支
在进行新功能点的开发时，从Develop分支拉取，在Feature分支上进行开发，完成开发并合并到Develop分支上后销毁 - Release分支
Release代表预发布分支，当需要发布新版本时，从Develop分支拉取进行测试，出现bug时直接在这条分支上完成修改，然后合并到Develop分支和Master分支上 - Hotfix分支
当Master分支上的代码出现bug时，需要紧急修复，从Master分支上拉取，在完成修复后合并到Develop分支和Master分支上
具体的角色权限管理
目前需要使用gitlab的人员有开发人员权限分为两级：普通开发人员（Developer组）和代码审核人员（Maintainer组）。因为目前规模比较小，对Feature分支和Hotfix分支进行削减，作为预备方案。
他们各自允许的操作如下：
Developer：Develop分支和Release分支上修改提交代码，发起合并请求
Maintainer：Developer的所有权限，从Develop分支上拉取新建Release分支，审核所有的合并请求。