冲突的解决原则
不是自己修改的地方就使用主干的。
需要特别注意的是：
分支同步主干时，远端（theirs）是主干，本地（mine/working）的是分支；
分支合入主干时，本地（mine/working）的是主干，远端（theirs）是分支。
二进制文件的冲突解决
对于*.jar *.png 等二进制文件的冲突，如果这些文件与你的业务开发是无关的，直接右键"Resolve"即可。
汉字注释中的"真假李逵"
在执行merge后，会发现代码中有些汉字注释有提示改动了，但内容却仍是一模一样的情况。见图1。
图1. 汉字注释"真假"
出现这种情况的原因是在写汉字注释时不是使用的统一的编码(如:utf-8)，就会出现看起来一模一样的注释内容，但SVN仍却显示有改动的提示。这种情况有可能导致编译失败。经查，图4中左边使用的是"utf-8"编码，但右边却使用"gbk"编码。出现这种情况时得及时统一文件编码。
*.prej冲突的解决
该冲突的产生原因未明，解决方法是直接删除该文件即可。
冲突的解决范围
由于手Q是多个工程联合编译的，这里首先要认识一下根目录的概念。
根目录是指能全编App的目录。
进行分支的同步与合入主干时，所有的merge操作都是针对根目录进行操作的。但这两个操作的步骤需要解决冲突的范围是不一样的。
分支同步主干时，解决冲突的范围是根目录下的所有文件及文件夹，然后进行提交。
分支合入主干时，解决冲突的范围一般只需要是主App下面的文件及文件夹。如若其它Library App与你自己开发的业务相关，只要是经过自己修改的，那也在解决冲突的范围内，不在自己业务范围内则不用处理了，节省时间吧。
非常非常重要：冲突解决后的代码复审
分支合入主干后，最头疼的情况是什么？是发现刚合入的代码冲掉了主干原本的代码或把主干已经删除的代码又恢复了，这种情况一发生，那就只能是代码回滚，再来操作一次分支合入。要哭死了！
避免这个失误的出现，只有小心为上，可以这么做。
解决冲突时深入一个一个文件夹逐一解决，解决完每一个文件夹里的所有冲突时，右键该文件夹，点击"SVN Commit"，然后逐一查看列出来的被修改的代码文件。一旦发现SVN的比较结果中有出现前后版本差异，但内容却不是自己所开发的业务需要的，此时要慎重再慎重，确认再确认，这种情况一般都是解决冲突时版本管理出错了。需Revert重新解决该文件的冲突。
本文为Sodino所有，转载请注明出处：http://blog.csdn.net/sodino/article/details/17126905
分支合入主干流程
嗯..没图说不清，见下图2吧。
图2. 分支合入主干时序图
图中标题Branch表示分支代码库，checkout版本号为ver.m的代码至本地新建的文件夹branch.working。然后再merge主干代码Ver.A至branch.working，解决完冲突后提交至分支生成新版本ver.n。第一步完成。
第二步首先checkout主干代码Ver.A至本地新建文件夹trunk.working，使用merge操作将分支ver.n合入trunk.working，第二步完成。标识此时trunk.working的临时版本号为Ver.An。。
如果在完成前两步的过程中主干有同学提交了新代码，则需要update至最新代码并解决冲突，这样trunk.working版本为Ver.AnC，解冲突后提交至主干。至此，合入操作完成。