我在 pre 直接修改 bug，被领导批评了

jinchanchan

背景简介

前几天项目在pre回归时，测试发现一个bug，经过排查，我发现漏写了一行代码。

由于此时test、dev的代码已经进入新的迭代开发了，因此为了图方便，我直接在pre上修改了代码，并直接推送发布。

没想到，随后就收到了来自领导的批评：为什么不拉个hotfix分支修复合并？你直接修改代码会让代码难以追踪、回滚，以后上线全是隐患!

确实，即使只有一行代码的修改，也不应该直接在pre直接更改，我深刻的反思了自己。

分支管理与协作流程

一般来说，一个项目从开发到上线共包含四个环境。

环境	分支名示例	作用说明
开发环境	dev	日常开发，集成各功能分支的代码，允许不稳定，便于测试和联调
测试环境	test	提供给 QA 团队回归测试，要求相对稳定；一般从 dev合并而来
预发布环境	pre	模拟线上环境，临上线前验证，接近正式发布版本，禁止频繁变更
生产环境	prod / main	最终上线版本，代码必须安全稳定、经过充分测试

以我们公司为例，大致的协作规范流程如下：

1、dev功能开发

由于功能是几个人共同开发，每个人开发前都需要从 dev 分支拉出 feature/xxx 分支；本地开发完成后提合并回 dev；

• 提测
  

当功能开发完成dev 稳定后合并进 test，然后QA 回归测试环境；如发现问题，在 hotfix/xxx 修复后继续合并回 test（实际开发中，为了简化开发流程，大家都是直接在test修改bug）。

3. 预发布验证

测试通过，临近上线时，会从 test 合并进 pre。pre 仅用于业务验证、客户预览，不会在开发新功能；遇到bug的话，必须基于pre拉一个hotfix分支，修复完通过验证后，在合并回pre。

4. 正式上线

从 pre 合并到 prod ，并部署上线；

【顺便吆喝一句，技术大厂跳板，软件工程师（前端/后端/测试），多城市有位，待遇还不错，感兴趣试一试。】

为什么不能直接在pre修改bug

pre 是预发布环境分支，作用是：模拟线上环境，确保代码上线前是可靠的，它应只接收已审核通过的改动，而不是“随便修的东西”。

如果直接在 pre 上修改，会出现很多意料之外的问题。如：

• 代码来源不清晰，审查流程被绕过
• 多人协作下容易引发冲突和覆盖（bug重现）
  

这样时间久了我们根本不知道哪个 bug 是从哪冒出来的，代码就会变得难以维护和溯源。

因此，基于pre拉一个hotfix/xxx 分支是团队开发的规范流程：

• 创建热修分支（hotfix 分支）
  

从 pre 分支上拉一个新的临时分支，命名建议规范些，如：

git checkout pregit pull origin pre        # 确保是最新代码git checkout -b hotfix/fix-button-not-working

• 2在 hotfix 分支中修复 bug
  

进行代码修改、调试、测试。

• 创建合并请求
  

bug修复且通过qa验证后，我们就可以合并至pre等待审核。

使用hotfix，大家一看到这个分支名字，大家就知道这是线上急修的问题，容易跟踪、回溯和管理。你直接在 pre 改，其他人甚至都不知道发生了 bug。

总结

通过本文，大家应该也进一步了解pre环境的bug处理规范，如果你还觉得小问题在pre直接修改问题不大，可以看看这个示例：

你是一个信誉良好的企业老板，你的样品准备提交客户的时候突然发现了问题。你正常的流程应该是：

• 回原材料工厂排查修理
• 重新打样
• 提交新样品
• 送给客户
  

除非你是黑心老板，样品有问题直接凑合修一下直接给客户。

——转载自：石小石Orz

​