大家好，我是石小石！
背景简介
前几天项目在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 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直接修改问题不大，可以看看这个示例：
你是一个信誉良好的企业老板，你的样品准备提交客户的时候突然发现了问题。你正常的流程应该是：
- 回原材料工厂排查修理
- 重新打样
- 提交新样品
- 送给客户
除非你是黑心老板，样品有问题直接凑合修一下直接给客户。
