SVN：工作中的版本控制管理

       昨天在接到这周的任务时，老大特意叮嘱了一句落实公司的研发版本管理制度。原本一直以为对版本的控制只要养成时常更新的习惯、提交时确认所有文件（包括增加的文件）的有效提交，以及防止或者解决好代码的冲突就可以了（博主是个实习生）。但是看到公司的版本管理制度里面看到对于研发日常reBase的要求，居然一无所知，于是跑去百度，总结归纳如下：

（正文之前想先说明，博主实习生，但是所有的分享都会自己实践过，尝试的环境有必要也会说明， 故而是负责任的技术分享，接受所有认真的批评！也希望大神们多多指正并提出宝贵的建议 ）

1.对于SVN最基础的了解和Repository与本地代码的结构：

推荐一篇博文    http://blog.****.net/vbirdbest/article/details/51122637 ，描述得非常详细

通过自己操作一遍基本流程（创建仓库-->放入项目-->下载代码-->提交修改 以及后面的分支拉取和分支主干之间的merge操作等）后，才会对SVN的结构有更加清晰的了解。

走了一遍上面的流程后，我才对Repository与本地代码的结构开始有了初步清晰的理解：

• 拉分支在仓库内部完成；
• 重点是merge的操作，接下去就merge操作的应用场景和原理进行剖析。

2.merge操作的应用场景和原理（关于reBase: reBase是GIT中的操作，而SVN中只有merge这个操作）

       场景（也是我这次遇到的）：老大给我拉了个branch，那么我在这个分支上面开始开发，但是由于运维那里合并其他分支代码的过程出了错，也就是说在我的分支被拉取之前，trunk的代码就是错误的。而在运维一顿操作使得主干上面的代码正确了之后，我的分支代码仍然（当然）还是错误的情况，怎么办？重新拉分支吗？组长就会说养你不如养猪。这个时候就需要把主干代码merge到自己分支上（准确的说是 merge一系列对代码的修改）。

       很多的博文会长篇演示，说到这里再分享一篇好文：http://blog.****.net/e3002/article/details/21469437

       那么我只讲这个merge操作：

      第二个不清楚，一般主干分支之间的暗送秋波，都是第一个。点击next

     

URL to merge from指的是你要从哪里merge到此处。

通过左图的show log出现右图，上面说了： merge准确的说是对一系列对代码的修改的同步。右图勾选你想要同步过来的代码修改版本（通常根据时间和注释来选择）

 

最后一步，默认设置，可以点击一下右下角的Test merge看看。然后直接点击Merge就OK了。

讲完了Merge这个操作，讲讲用途，其实这个操作可以用在分支与分支之间，也可以在分支和主干间双向使用，分支merge到主干即是合并分支，主干merge到分支即是“reBase”（打引号是因为SVN并无此操作，只是借此语义），而上面讲到的使用场景，就是使用"reBase"的时候。

 另外，我也分享一下自己的实验过程（常规的不说了，说一下有亮点的）：

1.我先在branch中修改了一个文件A，想要把分支合并到主干的时候，我想：merge是把仓库里的branch merge到仓库中的trunk还是本地代码的trunk呢？于是我在修改branch并且commit，merge后，重新check out，发现这时仓库里导出来的trunk里的A文件是修改之前的，也就是说，merge是把仓库里的branch merge到本地代码的trunk（突然想到这个是因为，操作的就是本地代码的trunk，所以当然是到本地代码的trunk，那么这边就当是解释第一张图片的“交叉merge"了）；

2.merge的过程中同样要注意冲突的产生。不要看merge的操作复杂，它本质上也就是分支和主干之间的互相update而已。