一、 首先我们基本遵循Git Flow规范：

• 参考资料
  • Git Flow 的正确使用姿势
  • Git flow 规范
• 我们所有的开发工作基于develop分支，不允许直接在develop分支上直接修改
• 在提测前所有开发工作都是从develop分支上拉取最新的代码进行开发, 开发完成后提merge request合并到develop分支
• Release分支只有在提测当天才会创建
• 提测阶段，所有基于Release分支的改动都必须以bugfix的方式来进行，我们需要从release分支上拉最新代码来开开发，开发完毕通过merge request合并到对应Release分支，这个时候不允许将develop分支上的东西合并到release分支上去
• 测试完成，准备上线当天将release分支的代码合并到master分支和develop分支上去，并在master分支上打上对应tag
• 所有线上bug我们通过在master分支上拉取最新的代码以Hotfix分支的方式来进行，hotfix的代码在合并前必须review， review完成后需要合并到master分支和develop分支。

二、Feature规范

1. 任务创建环节：收到产品需求后，产品研发负责人组织部门员工对产品文档进行讨论分析，如果产品基本逻辑没有问题，在和大家讨论确定初步技术方案后进行任务的分解，即在gitlab上发布issue, issue需要用以下格式描述：“<scope> <release>:<issue>”

   • scope: 如果为多人需要依赖的，标注为[shared], 如果和其他人无关的，省略这个字段
   • release为规划开发的release版本号，用小写的v打头，e,g: v1.0.0
   • issue: 接口、函数或者功能的具体描述

   例如：[shared] v1.0.0: implement some feature

   issue具体描述中需要按如下格式给出工作量以及其他细节的描述：

   ### 指标
   
   - 工作量: 0 天/人
   - 复杂度: 普通/紧急
   
   ### 描述
   
   <具体issue的描述>

   • 工作量: xxx 人/天
   • 复杂度: 分为普通和复杂两个难度
   • 具体issue描述：必须准确描述要达到的效果，可以通过和任务实现人讨论确定具体的接口命名以及传入参数和返回值类型等.

2. 任务分配环节：如果有人认领后开始理解issue，如果有问题及时和负责人和产品沟通，负责人需要及时完善issue的描述，以及更新yiia上的接口文档

3. 大家针对认领的feature开始开发

• 在gitlab的issue->board处将issue拖到WIP看板中即标识issue正在开发中

• 开始准备创建feature分支来处理issue, feature分支的命名规范为:“<release>-<owner>-<feature>”

  • release: 用"v"开头的release名字，例如:v1.0.0

  • owner: 开发者的拼音首字母

  • feature: 功能的简单描述

  • 具体git操作命令

    # 切换到开发分支
    git checkout develop
    # 确保从开发分支上获取到最新代码
    git pull
    # 切换并创建feature分支（同样可以用git flow工具）
    git checkout -b feature/<release>-<owner>-<feature name>

4. 开始开发, 在自己的feature分支提交commit(不需要推到远程)

5. feature开发完，在准备提交merge request之前需要将develop分支上的最新代码合并到自己工作的feature分支上

   git checkout develop
   git pull
   git checkout feature/xxx
   git merge develop

6. 点击Goland中的gitflow的feature publish，这个时候本地feature分支会推向远程分支, 或者执行以下的命令

   git push origin feature/xxx

7. 创建merge request, 请求将feature/xxx合并到develop分支去，在合并的时候在需要关联issue的序号。
   

   

   close #1
   Or
   fix #

   另外需要将issue的状态设置为"Done"
   

   

8. 如果某个feature需要review的话， 将merge request assign给某人；如果不需要review的话，直接自己去合并。如果在合并的过程中发现了冲突，需要到本地的feature/xxx分支去合并develop分支最新的代码并解决冲突后，重新push到远程feature分支上去。

三、Bugfix规范

Bugfix只有在release分支创建后才会出现，测试人员或者负责人会在Issue Board里面新创建issue, 开发人员根据issue的描述从release分支上拉一个新的bugfix分支来解决问题。所有流程基本和Feature开发规范一致，只是来源主分支变成了release分支，合并的目的分支也为release分支。