当前位置：首页 > ds >正文

发版混乱怎么规范

ds 2025/8/23 7:56:13

你是否经历过这种场景：临到发版，一堆功能代码挤在一起，测试分不清范围，修复一个Bug可能引发三个新Bug？发布过程像一场豪赌？

问题的核心往往在于分支策略和流程的混乱。今天，我们就来建立一套在绝大多数场景下都简单、清晰、高效的代码管理标准。

忘掉那些复杂的分支模型。对于90%的项目，你只需要两种长期存在的主分支和一种临时分支：

怎么操作？

整个流程的核心是 “切新分支开发” 和 “合并请求（Pull Request）”。

记住：一个功能，一个分支，一个合并请求。

准备：基于最新的 develop 分支，切出新分支 git checkout -b feature/awesome-new-thing develop。
编码：在你的功能分支上专心工作，频繁提交。
提审：完成后，发起一个到 develop 分支的合并请求（Pull Request）。
审查：
- 必须有同事审查你的代码。
- 必须有自动化工具（CI）检查你的代码：能否成功编译？单元测试是否都通过？代码风格是否符合规范？
- CI检查不通过，绝对禁止合并！
集成：审查通过，CI全绿，才能将功能分支合并回 develop。
清理：合并成功后，立即删除这个功能分支。保持仓库整洁。

当 develop 分支集成了足够的功能，准备发布一个新版本时：

启动发布：从 develop 分支切出一个发布分支，以版本号命名，例如 release/v1.2.0。
- 问：为什么不用develop直接发？答：为了隔离。发布前的最终测试和修复可能会产生新的提交，我们不想影响正在开发下一个版本的人。
测试与修复：QA团队只测试这个 release/v1.2.0 分支。发现的所有Bug，都在这个发布分支上修复。
发布上线：
- 测试通过后，将 release 分支合并到 main 分支。
- 至关重要的一步：在 main 分支上打一个标签（Tag），标签名就是版本号 v1.2.0。这个Tag就是你发布和回滚的精确坐标。
- 将 release 分支也合并回 develop 分支，确保修复的Bug在后续开发中也不会再现。
部署：将打上Tag的 main 分支代码部署到生产环境。
清理：删除发布分支 release/v1.2.0。

线上出现紧急Bug，需要立刻修复怎么办？

基于主分支修复：从 main 分支的最新Tag（比如 v1.2.0）切出一个热修复分支，例如 hotfix/critical-payment-bug。
快速修复：在这个分支上以最快速度修复问题并测试。
紧急发布：
- 将修复好的 hotfix 分支合并到 main，并打上新Tag v1.2.1。
- 同样至关重要：将 hotfix 分支也合并回 develop，确保修复不会丢失。
部署：部署新Tag v1.2.1 到生产环境。
清理：删除热修复分支。

主分支保护原则：main 分支是“王冠”，必须设置成保护分支。任何代码只能通过合并请求进来，且合并请求必须通过CI检查和至少一个同事的审查。封死直接推送的后门。
功能原子化原则：一个合并请求只做一件事（一个功能或一个修复）。坚决反对把多个不相关的修改放在一个分支里提交。这样代码审查范围清晰，回滚风险低。
标签化发布原则：永远只部署打了Tag的代码。Tag就是你的快照。出了问题，一分钟就能回滚到上一个Tag的版本。严禁直接部署某个分支的最新代码。

这套规范的核心就是：

规则简单，关键在于严格执行。尤其是保护主分支和打Tag这两个动作，是避免混乱的生命线。

操作目的	常用 Git 命令
拉取最新代码	`git pull origin <branch_name>`
创建/切换分支	`git checkout -b <new_branch_name>`
提交更改	`git add .` `git commit -m "message"`
推送分支	`git push -u origin <branch_name>` (首次) `git push` (后续)
合并分支	`git merge <source_branch>`
打版本标签	`git tag -a <tag_name> -m "message"`
推送标签	`git push origin <tag_name>`
删除本地分支	`git branch -d <branch_name>`
删除远程分支	`git push origin --delete <branch_name>`