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

本文转载自: 望风塔
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分支

你可能感兴趣的:(git,github,svn)