svn中branch与tag底层均为轻量级目录拷贝，但branch允许持续开发与合并，tag必须严格只读以保证归档可信性；功能开发和紧急修复用branch，正式发布用tag，误用需及时修正。
要在SVN中正确隔离功能开发与版本归档，必须理解branch和tag在底层实现上完全相同、但语义截然不同的事实——它们都是轻量级的目录拷贝，却承担着不可互换的职责。
Branch与Tag的技术本质
svn copy命令对trunk执行一次复制操作，无论目标路径是/branches/fix-login或/tags/v1.0.0，在仓库内部都只生成一个指向特定修订版本（revision）的指针，不复制实际文件内容。这使得创建branch或tag几乎瞬时完成，且空间开销极小。
关键区别在于约定俗成的使用规则：【branch目录下的内容允许持续提交、修改、合并】，而【tag目录一旦建立，任何直接提交都将被团队规范禁止】。违反后者将导致“标签失真”——你认为的v1.0.0快照，实际已混入未经验证的变更。
什么时候该创建Branch
方法一：为新功能开辟独立开发线
在trunk稳定可测的前提下，执行 svn copy http://svn.example.com/proj/trunk http://svn.example.com/proj/branches/feature-payment -m "Start payment integration" → 检出该分支进行开发 → 完成后通过svn merge将变更集整合回trunk。
方法二：紧急修复已发布版本
当v1.0.0已在生产环境运行，用户反馈严重缺陷，而trunk已进入v2.0开发阶段，此时应从/tags/v1.0.0创建分支：svn copy http://svn.example.com/proj/tags/v1.0.0 http://svn.example.com/proj/branches/hotfix-v1.0.1 -m "Fix critical auth bypass in v1.0.0" → 仅在此分支修复并测试 → 发布v1.0.1补丁包。
注意：绝不可直接在/tags/v1.0.0下修改代码——那会破坏该标签作为可信归档点的价值。
什么时候该创建Tag
第一步：确认代码状态
确保待标记的代码已在trunk（或经批准的branch）上完成全部测试、文档就绪、安装包构建成功，且修订版本号（如r3827）已锁定。
篇文章是针对git版本控制和工作流的总结，如果有些朋友之前还没使用过git，对git的基本概念和命令不是很熟悉，可以从以下基本教程入手： Git是分布式版本控制系统，与SVN类似的集中化版本控制系统相比，集中化版本控制系统虽然能够令多个团队成员一起协作开发，但有时如果中央服务器宕机的话，谁也无法在宕机期间提交更新和协同开发。甚至有时，中央服务器磁盘故障，恰巧又没有做备份或备份没及时，那就可能有丢失数据的风险。感兴趣的朋友可以过来看看
第二步：执行原子性标记
运行 svn copy http://svn.example.com/proj/trunk http://svn.example.com/proj/tags/v1.0.0 -m "Release v1.0.0, r3827"。此操作立即生成一个不可变快照，后续对该路径的任何提交都会被权限系统或pre-commit钩子拦截。
第三步：验证标记完整性
检出http://svn.example.com/proj/tags/v1.0.0到空目录，运行构建脚本并比对输出哈希值，确认与发布前验证结果一致。若发现差异，说明标记操作未基于正确修订版本，必须删除该tag并重做。
Branch与Tag的误用场景及修正
场景1：把临时实验代码扔进/tags/experiment-202606
这是对tag语义的根本性违背。正确做法是立即删除该路径，改用/branches/experiment-202606，并在README中注明“此分支不保证稳定性，勿用于发布”。
场景2：在hotfix分支合并回trunk后，忘记删除该branch
残留的/branches/hotfix-v1.0.1会持续接收无关提交，污染历史。应在merge完成后执行 svn delete http://svn.example.com/proj/branches/hotfix-v1.0.1 -m "Remove obsolete hotfix branch after merge to trunk"。
场景3：为同一功能反复打多个tag（如v1.0.0-alpha、v1.0.0-beta、v1.0.0-rc1）
只要这些是不同修订版本的快照，就完全合理。但必须确保每个tag名称明确反映其状态，且所有rc类tag均需经过同等严格测试流程。
