【版本控制SVN】系列——（1）分支合并原创
一把枸杞
65次浏览
编辑于2021年03月08日 14:02:51
SVN
主线/主干/主分支 用来做主方向开发的，比如新功能的开发
branches
分支 建立的分支目的是用来和做并行开发 在分支中修改在主干中不会被修改的文件，以便修改完成后合并到主干中； 使用场景有： 1、为不同用户客制化的版本，放在分支中进行开发----开发分支 2、模块开发完成后，需要修改，比如在维护的各个版本----维护分支
tags
标记 用于标记某个可用的版本，用来进行阶段发布的 branch和tag在实现上都是svn copy，在SVN里面是没有区别的，它们具体的使用是由人主观的根据规范和需要来选择而不是强制的。
举例
假设目前在开发的是最新的3.0版本，而且1.0/2.0版本也在进行维护
project
|
+-- trunk
+ |
+ +----- H.java (3.0版本的最新文件）
+
+-- branches
+ |
+ +-- r1.0
+ + |
+ + +---- H.java （1.x版本的最新文件）
+ +
+ +-- r2.0
+ |
+ +---- H.java （2.x版本的最新文件）
+
+-- tags (此目录一般只读)
|
+-- r1.0
+ |
+ +---- H.java （1.0版本的发布文件）
+
+-- r1.1
+ |
+ +---- H.java （1.1版本的发布文件）
+
+-- r1.2
+ |
+ +---- H.java （1.2版本的发布文件）
+
+-- r2.0
+ |
+ +---- H.java （2.0版本的发布文件）
+
+-- r2.1
|
+---- H.java （2.1版本的发布文件）
SVN命令
合并（Merge）
TortoiseSVN->Merge
Merge Type:
Merge a range of revisions（合并一个范围的版本）此类型应用最为广泛
主要是把分支中的修改合并到主干上来。在主干上点击右键选择合并
该类型只可以选择分支合并的版本，主干不能选择版本
Merge two different trees（合并一个范围的版本）
这种类型则是无论是主干还是分支都可以选择合并的版本
注意：
在使用merge功能时，一定要在合并目的地选择merge功能，而不是在数据源处选择merge。
SVN里面的from和to很容易被字面意思搞混，容易理解成“从。。到。。”。其实可以理解为，from为左边，起始状态，to为右边，最终状态。他们之间会做diff比较，之后将to的内容更新到from。
举例：
#前面的1是开分支之前trunk的版本号，后面的2是merge时trunk的版本号
svn merge -r 1:2 svn://localhost/www/trunk
cd trunk
#12973是分支开始的版本号，13006是分支结束的版本号
svn merge -r 12973:13006 svn://localhost/www/branches/branch
代码合并
方法1：人工合并
操作步骤：
update两个分支的代码，然后手动合并（先两个文本对比一次，合并后再文本对比一次），最后提交；
存在的问题：
但是文件修改的很多，依靠人工去比对合并会出现比如代码合并少了或者符合等错误、效率慢问题；
多人修改同一个文件，避免覆盖的方式修改
方法2：svn客户端工具合并
场景：
a)从trunk主干merge到分支
b)从分支merge到trunk主干
c)分支合并
操作步骤：
update两个分支的代码，TortoiseSVN->Merge>Merge a range of revisions，最后提交；
注意：
合并仅仅是合并到本地文件夹目录，所以合并完成后，记得要Commit提交到SVN
代码回滚
第一种情况：改动没有被提交（commit）
解决：手动删除源代码后再update或者svn revert命令放弃未提交的修改
第二种情况：改动已经被提交（commit）
解决： svn merge命令来进行回滚
假设最新版本号是28，回滚到版本号25：
svn merge -r 28:25 something
为了保险起见，再次确认回滚的结果：
svn diff [something]
3、提交回滚：
svn commit -m "Revert revision from r28 to r25,because of ..."
提交后版本变成了29
拉取分支/打tag
Branch/tag
推荐阅读