背景简介

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

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

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

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

分支管理与协作流程

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

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

1、dev功能开发

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

1. 2.提测

当功能开发完成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 pre
git pull origin pre        # 确保是最新代码
git checkout -b hotfix/fix-button-not-working

• 在 hotfix 分支中修复 bug

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

• 创建合并请求

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

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

总结

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

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

1. 回原材料工厂排查修理
2. 重新打样
3. 提交新样品
4. 送给客户

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

——转载自：石小石Orz