一线互联网公司git工作流使用方式

分支的分类

首先我们将分支分为固定的3个分支：

• test

测试分支，刚刚开发完的功能或者修复的bug，等待测试人员测试。

• master

预发布分支，包含通过测试的新功能或bug修复，随时都可以发布。

• prod

正式分支，和生产环境跑的代码一致。

两个动态分支，开发新功能的分支名称以“new_”开头，修复bug的分支名称以“fix_”开头。动态分支用完即可删除。

建立（tag）标签

对于issue和pr来说，我们都需要贴对应的tag（标签），来标识对应的状态。一般来说我们会建立如下17个标签:

• 一级bug
• 二级bug
• 三级bug
• 无效bug
• 重复bug
• 不修复
• 无法重现
• 一级需求
• 二级需求
• 疑问
• 已解决
• 确认解决
• 已实现
• 确认实现
• 解决失败
• 代码优化
• 没关联PR

人员的划分

在我们的整个git分支管理方法中分为4个角色

• 测试人员：测试开发人员写的代码
• 开发人员：写代码，实现新功能或者修复bug
• 产品经理：提需求
• 研发组长：代码审查，合并代码

具体的流程与对应角色

动作：新需求

角色：产品经理

1. 创建issue，打需求（一级需求）标签，指派给研发组长。
2. 研发组长，指派给相应的开发人员，标记里程碑。

角色：开发人员

1. 通过指派人，和“需求”标签来搜索新需求。
2. 基于master新建新需求分支，编写代码实现新需求。
3. 代码编写完成之后，将代码合并到test分支。
4. 提pr
5. 到gitea上找到相应的issue，然后将issue和提的pr关联起来，将issue标记为“已实现”。并将测试需求指派给测试人员。

角色：测试人员

1. 通过指派人，和“已实现”标签来搜索新需求，测试新的需求是否如期实现。
2. 如果有bug，新增issue来记录这个bug。并且将bugissue关联到需求issue。
3. 如果新需求没有bug或者所有关联的bug都修复完毕，将issue标记为“确认实现”，且将这个需求关联的pr也标记为“确认实现”

动作：修复bug

角色：测试人员

1. 创建issue，打bug标签，指派给相关的开发人员
2. 等待开发人员修改bug。
3. 通过指派人和“已解决”标签,找到要复测的bug，进行复测。
4. 如果bug修复成功，则标记为“确认解决”，并删除“已解决”标签，且将关联的pr标记为“确认解决”。如果bug未修复成功，则标记为“解决失败”，并删除“已解决”标签。然后指派给开发人员。

角色：开发人员

1. 通过指派人，和bug标签或者“解决失败”标签来搜索未解决的bug。
2. 基于master新建修复bug分支，编写代码修改bug。
3. 代码编写完成之后，将代码合并到test分支。
4. 提PR（注意，如果是新需求产生的bug，不需要重新提pr，直接使用新需求的那个pr）
5. 到gitea上找到相应的issue，将issue标记为“已解决”，然后将issue和提的pr关联起来。并将bug指派给测试人员。

动作：合并代码

角色：研发组长

1. 查看PR标题包含“确认解决”或者“确认实现”的标签。
2. 查看PR是否关联了issue，没关联issue的不可合并。（因为你不知道有没有bug）
3. 查看关联了PR的issue是否标记为“确认解决”或者“确认实现”，如果是则可以合并。先关闭掉所有相关的issue
4. 检查代码是否符合规范。（code review）
5. 关闭关联的issue之后，合并PR。

动作：发布新版本到生产环境

角色：研发组长

1. 查看所有待合并的PR是否都已经合并完成。
2. 将master的分支直接合并到prod。
3. 发布prod分支

动作：临时修复生产环境bug

角色：开发人员

1. 基于master分支新建bug修复分支。
2. 代码编写完毕后将bug修复分支合并到test分支。
3. 测试通过后，提一个PR。

角色：研发组长

1. code reivew之后，再合并PR
2. 将这个PR涉及到的提交cherry pick到prod分支
3. 发布prod分支