我在 pre 直接修改 bug，被领导批评了 （创作者训练营强势上线，速戳上图了解）大家好，我是石小石！ 背景简介前几天项目在 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 修改 bugpre是预发布环境分支，作用是：「模拟线上环境」，确保代码上线前是可靠的，它应「只接收已审核通过的改动」，而不是 “随便修的东西”。 如果直接在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 点击"阅读原文"了解详情~ 阅读原文