你是否经历过这种场景：临到发版，一堆功能代码挤在一起，测试分不清范围，修复一个Bug可能引发三个新Bug？发布过程像一场豪赌？
问题的核心往往在于分支策略和流程的混乱。今天，我们就来建立一套在绝大多数场景下都简单、清晰、高效的代码管理标准。
一、核心目标：我们要解决什么？
-
主线稳定：确保主分支的代码随时可以发布到生产环境。
-
并行开发：让多个功能开发互不干扰。
-
发布清晰：清楚地知道这次发布包含了什么，出了问题能快速定位和回滚。
-
简化流程：规则越简单，越容易执行，越不容易出错。
二、极简分支策略：两条主线 + 功能分支
忘掉那些复杂的分支模型。对于90%的项目，你只需要两种长期存在的主分支和一种临时分支：
| 分支类型 | 谁用？ | 作用 | 禁忌 |
|---|---|---|---|
| 主分支 (Main/Master) | 所有人 | 神圣不可侵犯。它始终与生产环境运行的代码完全一致。 | 严禁直接推送代码。唯一来源是合并请求。 |
| 开发分支 (Develop) | 开发者 | 新功能集成的大本营 。这里的代码是下一个版本的预览。 | 不要从这里直接发版。 |
| 功能分支 (Feature) | 单个开发者 | 从 develop 拉取，用于开发一个新功能或修复。 |
生命周期要短，完成必须合并删除。 |
怎么操作？
-
所有新功能开发，都必须从最新的
develop分支切出一个新的功能分支。 -
分支命名要有意义，例如：
feature/user-payment或fix/login-issue。
三、核心流程：如何执行？
整个流程的核心是 "切新分支开发" 和 "合并请求（Pull Request）"。
1. 开发新功能流程
记住：一个功能，一个分支，一个合并请求。
-
准备 ：基于最新的
develop分支，切出新分支git checkout -b feature/awesome-new-thing develop。 -
编码：在你的功能分支上专心工作，频繁提交。
-
提审 ：完成后，发起一个到
develop分支的合并请求（Pull Request）。 -
审查：
-
必须有同事审查你的代码。
-
必须有自动化工具（CI）检查你的代码：能否成功编译？单元测试是否都通过？代码风格是否符合规范？
-
CI检查不通过，绝对禁止合并！
-
-
集成 ：审查通过，CI全绿，才能将功能分支合并回
develop。 -
清理 ：合并成功后，立即删除这个功能分支。保持仓库整洁。
2. 发布版本流程（这是关键！）
当 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。
3. 修复线上紧急Bug
线上出现紧急Bug，需要立刻修复怎么办？
-
基于主分支修复 ：从
main分支的最新Tag （比如v1.2.0）切出一个热修复分支，例如hotfix/critical-payment-bug。 -
快速修复：在这个分支上以最快速度修复问题并测试。
-
紧急发布：
-
将修复好的
hotfix分支合并到main，并打上新Tagv1.2.1。 -
同样至关重要 ：将
hotfix分支也合并回develop，确保修复不会丢失。
-
-
部署 ：部署新Tag
v1.2.1到生产环境。 -
清理：删除热修复分支。
四、如何坚决避免发版混乱？------ 三大纪律
-
主分支保护原则 ：
main分支是"王冠"，必须设置成保护分支 。任何代码只能通过合并请求 进来，且合并请求必须 通过CI检查和至少一个同事的审查。封死直接推送的后门。 -
功能原子化原则 ：一个合并请求只做一件事（一个功能或一个修复）。坚决反对把多个不相关的修改放在一个分支里提交。这样代码审查范围清晰，回滚风险低。
-
标签化发布原则 ：永远只部署打了Tag的代码。Tag就是你的快照。出了问题，一分钟就能回滚到上一个Tag的版本。严禁直接部署某个分支的最新代码。
总结
这套规范的核心就是：
-
开发 在
功能分支→ 集成到develop。 -
发布 时用
发布分支隔离测试 → 稳定的代码合并到main并打Tag。 -
修复 从
main的Tag切热修复分支→ 修复后合并回main和develop。
规则简单，关键在于严格执行 。尤其是保护主分支 和打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> |