上周帮朋友改一个电商后台的优惠券功能，本地调好后直接 git push 到 main 分支，结果测试环境立刻崩了——因为另一个同事正往同一分支合支付模块的代码，俩人没沟通，接口字段冲突，页面白屏。这种事，真不是段子。
分支不是摆设，是安全带
很多人把 Git 分支当成“多开几个文件夹”，其实它更像工地上的隔离带：开发、测试、上线各走各的道，互不踩脚。常用分支就三类：main（或 master）——线上稳定版，只允许从 release 合并；develop——日常集成区，所有功能分支都往这儿提 PR；feature/xxx——每人一个独立小天地，比如 feature/user-login-v2，改完测完再合并，不搅和别人的事。
一个真实的工作流：从写代码到上线
假设你要加个「订单导出 Excel」按钮：
git checkout -b feature/order-export develop
git add .
git commit -m "add export button and basic API call"
git push origin feature/order-export然后在 Git 平台（比如 Gitee 或 GitHub）提 Pull Request，目标分支选 develop。等同事 Code Review 通过，自动跑完单元测试和 ESLint，再点合并。这时候你的改动才进到集成主干，不影响别人开发。
上线前：用 release 分支兜底
发版前别急着动 main。先切个 release/1.2.0 分支，从 develop 拉出来：
git checkout -b release/1.2.0 develop
# 这里只修紧急 bug，不加新功能
git commit -m "fix: export filename encoding issue"
git push origin release/1.2.0测试团队在这条分支上压测。没问题了，再一次性合并到 main 和 develop：
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "release version 1.2.0"
git checkout develop
git merge --no-ff release/1.2.0最后删掉 release 分支。整个过程可追溯、可回滚，不怕手抖。
部署环节，别让分支名乱飞
CI/CD 工具（比如 Jenkins、GitLab CI）能自动识别分支触发不同流程。举例：
- 推送到
feature/*→ 自动跑 lint + 单元测试，不部署； - 推送到
develop→ 测试环境自动构建并部署； - 打
v*tag → 生产环境拉取对应 tag 构建，启动新容器。
关键点就一个：部署脚本里别硬写分支名，用 $CI_COMMIT_TAG 或 $GIT_BRANCH 这类环境变量动态判断。否则哪天 rename 分支，整条流水线就卡死。
有次我们误把 develop 的构建产物推到了生产镜像仓库，原因就是部署脚本里写了 if [ $BRANCH == 'develop' ]; then docker push xxx/prod ——变量没取对，条件恒真。后来全改成基于 tag 部署，再没出过这种低级错误。
分支管理不是炫技，是给团队省时间、少背锅。每天多花两分钟起个规范分支名，可能就避免一次凌晨三点的线上救火。