分支的分类
首先我们将分支分为固定的3个分支：
- test
测试分支，刚刚开发完的功能或者修复的bug，等待测试人员测试。
- master
预发布分支，包含通过测试的新功能或bug修复，随时都可以发布。
- prod
正式分支，和生产环境跑的代码一致。
两个动态分支，开发新功能的分支名称以“new_”开头，修复bug的分支名称以“fix_”开头。动态分支用完即可删除。
建立（tag）标签
对于issue和pr来说，我们都需要贴对应的tag（标签），来标识对应的状态。一般来说我们会建立如下17个标签:
- 一级bug
- 二级bug
- 三级bug
- 无效bug
- 重复bug
- 不修复
- 无法重现
- 一级需求
- 二级需求
- 疑问
- 已解决
- 确认解决
- 已实现
- 确认实现
- 解决失败
- 代码优化
- 没关联PR
人员的划分
在我们的整个git分支管理方法中分为4个角色
- 测试人员：测试开发人员写的代码
- 开发人员：写代码，实现新功能或者修复bug
- 产品经理：提需求
- 研发组长：代码审查，合并代码
具体的流程与对应角色
动作：新需求
角色：产品经理
- 创建issue，打需求（一级需求）标签，指派给研发组长。
- 研发组长，指派给相应的开发人员，标记里程碑。
角色：开发人员
- 通过指派人，和“需求”标签来搜索新需求。
- 基于master新建新需求分支，编写代码实现新需求。
- 代码编写完成之后，将代码合并到test分支。
- 提pr
- 到gitea上找到相应的issue，然后将issue和提的pr关联起来，将issue标记为“已实现”。并将测试需求指派给测试人员。
角色：测试人员
- 通过指派人，和“已实现”标签来搜索新需求，测试新的需求是否如期实现。
- 如果有bug，新增issue来记录这个bug。并且将bugissue关联到需求issue。
- 如果新需求没有bug或者所有关联的bug都修复完毕，将issue标记为“确认实现”，且将这个需求关联的pr也标记为“确认实现”
动作：修复bug
角色：测试人员
- 创建issue，打bug标签，指派给相关的开发人员
- 等待开发人员修改bug。
- 通过指派人和“已解决”标签,找到要复测的bug，进行复测。
- 如果bug修复成功，则标记为“确认解决”，并删除“已解决”标签，且将关联的pr标记为“确认解决”。如果bug未修复成功，则标记为“解决失败”，并删除“已解决”标签。然后指派给开发人员。
角色：开发人员
- 通过指派人，和bug标签或者“解决失败”标签来搜索未解决的bug。
- 基于master新建修复bug分支，编写代码修改bug。
- 代码编写完成之后，将代码合并到test分支。
- 提PR（注意，如果是新需求产生的bug，不需要重新提pr，直接使用新需求的那个pr）
- 到gitea上找到相应的issue，将issue标记为“已解决”，然后将issue和提的pr关联起来。并将bug指派给测试人员。
动作：合并代码
角色：研发组长
- 查看PR标题包含“确认解决”或者“确认实现”的标签。
- 查看PR是否关联了issue，没关联issue的不可合并。（因为你不知道有没有bug）
- 查看关联了PR的issue是否标记为“确认解决”或者“确认实现”，如果是则可以合并。先关闭掉所有相关的issue
- 检查代码是否符合规范。（code review）
- 关闭关联的issue之后，合并PR。
动作：发布新版本到生产环境
角色：研发组长
- 查看所有待合并的PR是否都已经合并完成。
- 将master的分支直接合并到prod。
- 发布prod分支
动作：临时修复生产环境bug
角色：开发人员
- 基于master分支新建bug修复分支。
- 代码编写完毕后将bug修复分支合并到test分支。
- 测试通过后，提一个PR。
角色：研发组长
- code reivew之后，再合并PR
- 将这个PR涉及到的提交cherry pick到prod分支
- 发布prod分支