共计 1855 个字符，预计需要花费 5 分钟才能阅读完成。
本文转载自：望风塔
Git 虽然是一个好工具，但是想要用好却不容易。网上有很多教你如何使用 git 命令的教程，但是很少有人教你怎么管理你项目的分支（git 工作流）。
假设给你一个超大项目，你怎么去修复线上 bug，怎么去保证分支始终是干净可用，怎么保证项目的代码稳定性呢？
我们探究出了一套管理方法，你学了就是属于你的经验了。
管理工具
首先，我们不会使用禅道之类的工具记录 bug 和需求，而是使用 github 中的 issue 功能。因为 bug 和需求是和分支有关联的，如果使用第三方工具（禅道），那么将和分支脱节，难以做到统一的管理。当然你也可以选择使用 gitea 和 gogs 之类的工具，和 github 的功能是一样的。本文以 gitea 为例来讲解。
分支的分类
首先我们将分支分为 固定的 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 分支
正文完