主干、分支、标签：SVN 里的目录约定

SVN 讲分支，很多时候讲的不是某种“轻量引用”，而是仓库目录怎么组织。

什么时候看这页

• 你想知道 trunk / branches / tags 到底是不是必须的
• 你要建功能分支、热修分支或发布标签
• 你发现团队里有人直接在 tags 下继续改代码，想确认这事到底靠不靠谱

最常见的一套目录结构

/trunk
/branches
/tags

这不是 SVN 强制要求，但基本已经是行业约定。

我一般这样理解：

• trunk：主干，日常集成线
• branches：功能开发、联调、热修
• tags：某一时刻的发布快照

场景 1：我要从主干切一个功能分支

SVN 建分支最常见的做法是服务器端复制：

svn copy ^/trunk ^/branches/feature-order -m "create feature-order branch"

然后把你本地工作副本切过去：

svn switch ^/branches/feature-order

这里的 ^/ 表示“仓库根目录相对路径”。我自己很喜欢这种写法，因为不用每次都敲完整 URL，改域名或协议时也更稳一点。

场景 2：我要做一个发布标签

svn copy ^/trunk ^/tags/release-1.2.0 -m "tag release-1.2.0"

这一步的核心目的不是“再开一条开发线”，而是留一个可回看的发布快照。

所以标签创建出来之后，我会把它当成只读。

SVN 不会物理阻止你继续改 tags，但团队最好把这件事当作禁区，不要靠“技术上能改”来指导流程。

场景 3：线上版本出问题，要从标签开热修

如果你的发布流程里标签很稳定，可以从标签再拷一条热修分支：

svn copy ^/tags/release-1.2.0 ^/branches/hotfix-1.2.1 -m "create hotfix-1.2.1"

这个模式在老项目里挺常见，因为它能让“修的是哪一版线上代码”非常清楚。

为什么 SVN 建分支看起来像复制目录，但成本没那么夸张

很多人第一次看到 svn copy 会觉得：

这不是把整个项目复制一份吗？

从使用感受上像，但在仓库实现层面，它不是那种粗暴拷贝磁盘文件的思路，通常比想象中轻。

所以别因为命令长得像“复制目录”，就误以为分支一定很重。

我比较建议的几条约定

• trunk 只留相对可集成的代码
• 功能开发放到 branches
• tags 当作发布快照，不继续开发
• 分支名尽量有业务语义，不要全靠日期或拼音缩写猜

常见坑

• 直接在本地复制目录，不等于创建了 SVN 分支
• 新建分支后只在服务器上有目录，工作副本如果没 switch，你还在原来的线
• 把标签当分支继续开发，后面发布追溯会很乱
• 团队没有统一 trunk / branches / tags 约定，新人接手时很容易迷路