我在 pre 直接修改 bug，被领导批评了
石小石Orz约 3 分钟
（创作者训练营强势上线，速戳上图了解）
大家好，我是石小石！
背景简介
前几天项目在 pre 回归时，测试发现一个 bug，经过排查，我发现漏写了一行代码。
由于此时 test、dev 的代码已经进入新的迭代开发了，因此为了图方便，我直接在 pre 上修改了代码，并直接推送发布。
没想到，随后就收到了来自领导的批评：为什么不拉个 hotfix 分支修复合并？你直接修改代码会让代码难以追踪、回滚，以后上线全是隐患!
确实，即使只有一行代码的修改，也不应该直接在 pre 直接更改，我深刻的反思了自己。
分支管理与协作流程
一般来说，一个项目从开发到上线共包含四个环境。
| 「开发环境」 | dev | |
| 「测试环境」 | test | dev合并而来 |
| 「预发布环境」 | pre | |
| 「生产环境」 | prodmain |
以我们公司为例，大致的协作规范流程如下：
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 pre
git pull origin pre # 确保是最新代码
git checkout -b hotfix/fix-button-not-working
2 「在 hotfix 分支中修复 bug」
进行代码修改、调试、测试。
「创建合并请求」
bug 修复且通过 qa 验证后，我们就可以合并至pre等待审核。
使用 hotfix，大家一看到这个分支名字，大家就知道这是线上急修的问题，容易跟踪、回溯和管理。你直接在 pre 改，其他人甚至都不知道发生了 bug。
总结
通过本文，大家应该也进一步了解 pre 环境的 bug 处理规范，如果你还觉得小问题在 pre 直接修改问题不大，可以看看这个示例：
你是一个信誉良好的企业老板，你的样品准备提交客户的时候突然发现了问题。你正常的流程应该是：
回原材料工厂排查修理 重新打样 提交新样品 送给客户
除非你是黑心老板，样品有问题直接凑合修一下直接给客户。
关注更多AI编程资讯请去AI Coding专区：https://juejin.cn/aicoding