二、SVN版本管理-多需求代码合并

上篇文章写了单个需求（任务号）的代码合并。在逻辑处理上相对简单一些。下面继续写一下多个需求的代码合并该怎样实现。
多需求合并概念介绍：
假设需求1是开发用户登陆功能，需求2是开发密码修改功能。此时需求1和需求2均已经开发完毕，需求1对应的版本号是r1、r2、r5。需求2对应的版本号是r3、r4 。现在要用cherry pick的模式把需求1和需求2合并到测试环境的分支上。12345之外的版本号不做合并（如图）。

image.png

首先把实现多需求合并需要的svn命令列举如下：

检出分支到本地：
svn checkout branch_url local_dir --username *** --password *** --non-interactive --no-auth-cache

更新本地工作副本：
svn update local_dir --username *** --password *** --non-interactive --no-auth-cache

clean本地工作副本:
svn cleanup local_dir

查询分支最近N条log：
svn log branch_url -l 2 --username *** --password *** --non-interactive --no-auth-cache

查询源分支到目标分支的合并历史记录：
svn mergeinfo src_branch_url dest_branch_url --revision start_rivision:HEAD --show-revs merged --username *** --password *** --non-interactive --no-auth-cache

预合并：
svn merge -r 0:5 src_local_dir dest_local_dir --username *** --password *** --non-interactive --no-auth-cache --dry-run

合并（此处分三次合并，下面会有详细解释）：
svn merge -r 0:2 src_local_dir dest_local_dir --username *** --password *** --non-interactive --no-auth-cache
svn merge -r 2:4 src_local_dir dest_local_dir --username *** --password *** --non-interactive --no-auth-cache
svn merge -r 4:5 src_local_dir dest_local_dir --username *** --password *** --non-interactive --no-auth-cache

回滚本地工作副本
svn revert -R local_dir

首先是把这两个需求对应的版本号查出来，剔除掉合并过的版本号（前提是这些版本号都没有做过回滚，对于做过回滚的版本号，是不需要剔除的，如何判断一个版本号是否做过回滚，再后续的代码回滚篇章中会提及）。一般查询需求号对应的版本号，需要根据commitlog里的关键字去匹配。例如需求1对应的版本号的commitlog里应该包含“需求1”字样。
剔除完合并过的版本号之后，根据版本号做一个排序。假设，剔除完之后的需求1对应的版本号是：r1、r2、r5，需求2对应的版本号是r3、r4。做完排序之后的结果应该是r1、r2、r3、r4、r5。
排完序之后，先做一个预合并，命令如下：

svn merge -r 0:5 src_local_dir dest_local_dir --username *** --password *** --non-interactive --no-auth-cache --dry-run

预合并如果有冲突的话，就直接终止后续的操作了，等待人工解决完冲突之后，再重新进行合并。
预合并如果没有冲突的话，就进行真正的合并操作。此时重点就来了，是不是直接就执行svn merge -r 0:5就好了呢？答案是否定的。正确的合并姿势如下：

先合并r1、r2版本
svn merge -r 0:2 src_local_dir dest_local_dir --username *** --password *** --non-interactive --no-auth-cache
提交到svn远程分支
svn commit -m "需求1 用户登陆功能" local_dir --username *** --password *** --non-interactive --no-auth-cache

再合并r3、r4版本
svn merge -r 2:4 src_local_dir dest_local_dir --username *** --password *** --non-interactive --no-auth-cache
提交到svn远程分支
svn commit -m "需求2 修改密码功能" local_dir --username *** --password *** --non-interactive --no-auth-cache

再合并r5版本
svn merge -r 4:5 src_local_dir dest_local_dir --username *** --password *** --non-interactive --no-auth-cache
提交到svn远程分支
svn commit -m "需求1 用户登陆功能" local_dir --username *** --password *** --non-interactive --no-auth-cache

看完了上面三段操作，大家就清楚了，如果直接用svn merge -r 0:5命令一次性全部合并，也可以合并成功，但是合并完了commit的时候就蒙圈了，不知道commitlog里应该写啥了，因为合并的代码里既有需求1的代码也有需求2的代码。最重要的一点是，合并到目标分支上，会把需求1的代码和需求2的代码揉到一起，没办法区分。假如我现在有如下场景，就没办法支持了：

开发分支---->集成测试分支---->用户测试分支
开发分支往集成测试分支上合并的时候，合需求1和需求2。集成测试分支测试完毕之后，需求1测试通过了，需求2测试没通过。现在需要把需求1合并到用户测试分支，而需求2不合。

所以再合并操作的时候，还是要把不同的需求对应的版本号区分开合并。

总结

这里仅介绍了多需求合并的最简单场景，对与更加复杂的场景，整个技术实现的骨架不会变，无非就是根据不同的业务场景去添枝加叶罢了。