为什么需要分支

假如你的项目已经完成开发、测试并已经上线了。
上线后你再开发新的功能，这时测试突然发现上线的版本有个重大的bug。
此时应该怎么修复bug呢？是在当前已经开发新需求的基础上进行修复吗？
答案是否定的
原因是：如果是在已经开发新需求的基础上进行修复bug，那么新需求还没开发好，更没有测试，怎么立刻（或最可能快的）上线？！
再次如果新功能的开发和bug修复的代码都涉及到同一段代码冲突了怎么办 。
很显然不能在当前开发的代码基础上进行bug修复工作
完美的解决方案是：在当时完成的那个版本中进行bug fix
这样带来的好处是：

• bug修复好之后可立即上线，不会因为新需求还没有完成或测试而延迟上线时间
• bug修复是在原来上线的那个版本进行修复的，引起新bug的风险小，如果是在新需求的基础上修复bug, 那么新功能可能会带来新的bug

几个重要的概念

在建立项目版本库时，可首先建好项目文件夹，并在其中建立trunk, branches, tags三个空的子目录。这样在trunk中开始进行开发

• trunk是主分支，是日常开发进行的地方。
• branches是分支。一些阶段性的release版本，这些版本是可以继续进行开发和维护的，则放在branches目录中。又比如为不同用户客制化的版本，也可以放在分支中进行开发。
• tags目录一般是只读的，这里存储阶段性的发布版本，只是作为一个里程碑的版本进行存档。

案例

准备工作
1，首先在你svn项目下创建 trunk branches tags 三个目录 如图：

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

• 集中式(trunk进行主要开发)：直接在trunk下开发 要上线时 直接用trunk 发布版本（个人开发 推荐）
• 分散式(分支进行主要开发)：在每个人的分支下开发 要上线时 在合并到trunk 在进行发布版本（团队开发推荐）

集中式（trunk进行主要开发）
1.基于trunk,创建release_ 1.0打tag
此时的目录结构为

svn://proj/
    +trunk/ (freeze)
    +branches/
    +tags/
        +tag_ release_ 1.0 (copy from trunk)

2.2.0开始开发，trunk此时为2.0的开发版
3.此时1.0有bug, 需要修改，基于1.o的tag做branch
此时的目录结构为

svn://proj/
    +trunk/ ( dev 2.o)
    +branches/
        +dev_ 1.0_ bugfix (copy from tag/release_ 1.0)
    +tags/
        +release_ 1.0 (copy from trunk)

4.在1.0 bugfix branch迸行1.0 bugfix开发，在trunk迸行2.0开发
5.在1.0 bugfix完成之后，基于dev_ 1.0_ bugfix的branch做release等
6.根据需要选择性的吧dev_ 1.0_ bugfix这个分支merge回trunk (根据具体情况来定)
分散式（分支进行主要开发）
1.1.0开发，做 dev1.0的branch
此时的目录结构

SVN://proj/
    +trunk/ (不担负开发任务）
    +branches/
    +dev_1.0(copy from thrunk)
    +tags/

2.1.0开发完成，，merge dev1.0到trunk
此时目录结构：

svn://proj/
    +trunk/ (merar from branch dev_1.0) 
    +branches/
    +dev_1.0(开发任务结束,freeze) 
    +tags/

3.根据tmnk做1.0的tag
此时目录结构：

svn://proj/
+trunk/ (mercLr from branch dev_1.0) 
+branches/
    +dev_1.0(开发任务结束，freeze) 
+tags/
    +tag_release_1.0(copy from trunk)

4.1.0开发，做dev2.0分支
此时目录结构：

svn://proj/
+trunk/ (mergr from branch dev_1.0) 
+branches/
    +dev_1.0(开发任务结束,freeze) 
    +dev_2.0(逬行 2.0 开发）
+tags/
 +tag_release_1.0(copy from trunk)

5.1.0有bug.直接6dev1.0&分支上修复
此时目录结构：

svn://proj/
+trunk/ (mercLr from branch dev_1.0) 
+branches/
    +dev_1.0(1.0 bugfix)
    +dev一 2.0(逬行 2.0 开发）
+tags/
    +tag_release_1.0(copy from trunk)

6.选择性的进行代码merge

第一种开发模式（trunk进行主要开发，集中式）：
优点：管理简单。
缺点：当开发的模块比较多，开发人数/小团队比较多的时候，很容易产生冲突而影响对方的开发。因为所有的改动都有可能触碰对方的改动。
第二种开发模式（分支进行主要开发，分散式）：
优点：各自开发独立，不容易相互影响。
缺点：管理复杂，merge的时候很麻烦，容易死人。

合并分支
选择你要合并的分支 右键选择-> tortoisesvn ->Merge

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述