为什么要建立分支

这是很多初学者都会有的疑问。我用实际场景来解释一下只用 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 用户报告了 Bugmain (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 机制保证质量多版本维护❌ 无法同时维护新旧版本✅ 每个版本独立分支简单来说main 分支 稳定的产品就像商店里卖的成品feature 分支 车间里的半成品可能还没做好release 分支 已经打包好的特定版本v1.0, v1.1…hotfix 分支 紧急抢修不经过车间直接修成品你刚才创建的release1.0分支就是给能编译成功的版本拍了一张快照这样即使用户报告问题或者你想继续开发新功能都有一个稳定的基础可以回退。