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

为什么要建立分支

news 2026/8/9 3:54:01

这是很多初学者都会有的疑问。我用实际场景来解释一下：

只用 main 分支的问题

想象一个场景：你的游戏引擎已经发布给用户使用了（v1.0），现在你要开发新功能（比如添加光线追踪）。如果你直接在 main 分支上开发：

Day 1: 你开始写光线追踪代码，但还没写完，编译不过 Day 3: 用户报告了一个严重 Bug（游戏崩溃），需要你紧急修复

问题来了：

你的 main 分支现在有未完成的光线追踪代码，编译都过不了
你无法基于 main 分支发布热修复版本
用户只能等你把光线追踪写完才能拿到 Bug 修复

多分支的好处

1.并行开发不互相干扰

main ●────────●────────●────────● \ / release1.0 ●──────────────● (稳定的发布版本) \ feature/rtx ●────●────● (光线追踪开发中) \ hotfix/bugfix ● (紧急 Bug 修复)

main: 稳定的主线
release1.0: 当前发布的版本
feature/rtx: 新功能分支（可能开发几周，随时可能编译不过）
hotfix/bugfix: 紧急修复分支

2.代码审查和质量控制

# 开发者完成一个功能gitcheckout-bfeature/new-physics# ... 写代码 ...gitpush origin feature/new-physics# 在 GitHub 上创建 Pull Request，让同事审查代码# 审查通过后才合并到 main

好处：

防止"半成品"代码直接进入主分支
多人可以 Review 代码，发现潜在问题
保持 main 分支始终可编译、可发布

3.实验性开发不担心搞砸

main ●────────●────────● \ experiment ●────●────●──● (尝试新架构) / abandoned ●──● (发现方向错了，直接删除分支)

如果实验失败，直接删除分支即可，main 分支完全不受影响。

4.多版本维护

假设你的引擎：

v1.0 已经给用户使用
v2.0 正在开发新功能
但 v1.0 用户报告了 Bug

main (v2.0开发中) ●────●────●────● / release/1.0 ●────●────● (维护旧版本) \ hotfix/crash-fix ● (修复崩溃 Bug，发布 v1.0.1)

你可以基于release/1.0分支修复 Bug 并发布 v1.0.1，同时 v2.0 的开发完全不受影响。

常见的分支策略

Git Flow（大型项目）

main ●────────────────●────────────● \ / \ / develop ●────●────● ●────●────● / \ / feature/a ●────● ●────● feature/b \ / release/1.0 ●────● hotfix/1.0.1 ●

GitHub Flow（小型/敏捷项目）

main ●────────●────────●────────● \ / \ / feature/a ●────● ●────● feature/b ●────●

简单规则：

main永远保持稳定、可发布
任何开发都建分支
通过 Pull Request 合并回 main

实际例子：你刚才的操作

main ●────────────────────● \ / release1.0 ●────────────────● (我们创建的) \ ● 你的新功能提交

为什么创建 release1.0 分支？

main 可能还在继续开发- 可能有其他人在 main 上提交新代码
release1.0 是一个快照- 标记"这个版本是可以编译发布的"
用户可以基于 release1.0 使用- 而不用担心 main 分支的不稳定性

总结

场景	单分支 (main only)	多分支
开发新功能	❌ 可能破坏现有代码	✅ 在分支上随意实验
紧急修复 Bug	❌ 被未完成的代码阻塞	✅ 基于稳定版本快速修复
多人协作	❌ 代码冲突频繁	✅ 各自开发，PR 合并
代码审查	❌ 无法区分"完成"和"进行中"	✅ PR 机制保证质量
多版本维护	❌ 无法同时维护新旧版本	✅ 每个版本独立分支