Subversion(SVN) 是一个开源的版本控制系統,常用于源码的版本管理。在EAS系统某版本补丁开发的过程中开发者实现了某些特性，或完成缺陷修复后，需要将代码改动同步到其他版本的标准代码上，这种过程称为代码回迁。笔者在接下来总结了回迁过程中使用发现SVN使用上存在的不足，并使用另一个版本管理工具git用于对比。 1. 无法将多个提交压缩为一个提交。 在开发一个功能的时候，由于仍在摸索合适的实现方式，或是修复缺陷，或是代码评审需要对代码进行优化，均会反复的修改并提交代码，会造成一个功能有很多次提交。当开发在回迁的时候，会遇到回迁 的提交过于碎片化的问题，为了保证回迁的完整性，开发需要花大量精力去甄别并合并多个提交的代码。而Git提供squash功能，它能将多个提交压缩为一个提交，对于回迁的开发者而言，回迁一个提交和回迁多个提交会更省心些。 2. SVN无法在开发各自**本地**完成**代码合并**。 当开发需要同时开发多个功能时，在本地合并代码就显得十分有用了。首先开发可以增量式开发，将开发的半成品预提交到本地的代码仓库，一方面能够避免不同功能开发的代码相互干扰，另一方面提交到本地的代码不会影响到构建所使用的的远程仓库代码。然而SVN属于集中式版本管理系统，合并过程发生在服务端，且存在单点故障的风险。而Git属于分布式版本管理系统，开发可以在本地多次提交合并代码，并使用squash命令整理为干净的提交后 一次性合并得到服务端。 本文旨在发现SVN在回迁过程中存在的问题，并横向对比了另一版本管理工具git的一些可以解决问题的功能。笔者希望抛砖引玉，能够激发讨论找到对应的解决办法。当然，SVN具有管理方便，使用简单，代码一致性和安全性高等特点，具体使用什么工具进行代码的版本管理，需要根据部门团队的实际情况和需要进行选择。