乐趣区

学习一线互联网公司git的工作流让你面试不再尴尬

jiezi

本文转载自：望风塔
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
  • 产品经理：提需求
  • 研发组长：代码审查，合并代码

具体的流程与对应角色

因为每个角色做的事情都不一样，所以我按照角色和动作划分了一下。

动作：新需求

角色：产品经理
  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 分支
退出移动版