svn 给笔者的一大印象就是非常容易产生冲突，特别是项目加入新人后，由于初期没有强硬地制定规范，导致后期合并代码时灾难连天。决定在此分享这些“亡羊补牢”的规则，也算是避免 svn 产生合并冲突的一点经验。
一个简单的分支管理策略
正式分享 tips 前，先交代一下目前在用的 svn 管理策略，因为本文避免合并冲突的一些要点就是建立在此策略之上的。
类似于 git 的轻度规则，主要分为 dev、master、release 三种分支。
以 master 为核心，保存完整代码。release 则允许剔除未编译前端 js、测试用例、项目文档等运行环境不需要的文件，减轻发布体积。功能开发在各 dev 进行。因此 master 和 release 只需要处理代码合并。
1 | 发布分支 主干 开发分支 |
如何避免冲突
1. 编辑器装好 svn 相关插件。
不同于“装机必备”的 git ，很多编辑器没有自带 svn 的管理插件，需要用户自己安装。
尤其重要的功能是可以实时对比 diff，本地和远程仓库的差异一览无遗，不要再疑惑为什么本地顺畅线上崩盘了。
windows 开发环境可能需要配置 svn 环境变量，但不要偷懒，这点工作一劳永逸。
2. 细化提交。
当合并时，假如发现同一个提交下存在还未达到上线状态的变更，这种情况如果忽略合并某些代码，会导致该开发分支和 master 分支不再一致，为后继的开发者挖坑。
3. 开发分支也要规范 commit log。
尽管开发分支可能在功能完成后就被删除，依然要有意识地为各个 commit 打上前缀、标签。
假设某开发分支是多人协作，若 commit log 有合适的标签，可以增加合并时的检索效率，避免遗漏部分久远的提交。当然，除非业务关联性较大，放在一个分支方便做同时修改，最好还是分模块、分特性单独建开发分支。
4. 所有的合并操作，采取针对版本号的更改。
其实主要面向需要长期维护的开发分支，直接合并目录树会携带大量不稳定变更。
5. 对完整的分支执行合并。
对整个分支目录执行合并，而不是对单个文件、单个子目录做合并，否则结合第 2 点，这极容易埋下隐患。
6. 牢记发布分支 release 是 master 的快照。
禁止跨过 master 在 release 直接提交代码。更危险的是在 release 提交的代码和 master 不一致，好在上次遇到这么做的被我及时制止了。XD
进一步要求，不要在 master 直接提交解决冲突以外的代码。
7. 定期把 master 的所有更改合并回开发分支。
尤其是涉及工具类、公共模块的更改。当开发分支维护不下去时，以 master 为基准重建开发分支。
8. 遇到 GUI 解决不了的冲突，命令行参数了解一下。
大杀器，说多了都是泪……
小结
以上内容是笔者几乎照搬着对 git 的理解来总结的，可能并不成熟。不过经过了一年的实践，这些“规范”操作的确达到了避免冲突的目的，且远没有复杂过 git rebase 工具流。
制定规范是一回事，更应该要求团队成员继续加深对版本管理库的理解，思考分支合并存在的意义，养成更好的提交习惯。