我为一个使用Subversion作为主要VCS的团队工作，但几乎每个人都开始通过git-svn在本地使用git。现在我们正在考虑完全转换为git。
作为中间步骤，最好同时使用它们两个。问题不在于那些非常乐意切换到git的用户，而是我们围绕Subversion构建的持续集成/构建基础架构。管理当然不会对任何大爆炸导致的停机时间感到激动，我们每两周发布一次新功能，几乎每天都会发布错误修复和其他小问题。理想情况下并行运行这些系统会使最终的开关成为无问题。
问题似乎是不存在源自Subversion存储库的共享git存储库。每个并行git svn merge / rebase都会创建新的git提交，这些提交都是重复的。并行我指的是两个开发人员在他们自己的同一个git存储库的克隆中进行合并或重组。更糟糕的是，git svn dcommits似乎改变了git commit的ID。
这种环境是否可能，或者git-svn真的只是一个单用户工具？
答案 0 :(得分：5)
首先，我建议不要打算尝试做两个中央存储库，一个svn和一个git，当然不能用svn作为核心存储库。 SVN倾向于忽略git的哈希提交标识，因此它不是一条简单的双向街道。
现在最好咬紧牙关而不是以后处理一团糟。
我认为有效的svn的一个目的，即使对于继续svn用户并不是非常有用，也是一个只读存储库。换句话说，您可以设置svn来镜像git存储库（至少是主分支），允许checkout，但不允许提交回svn。这样，如果有人想要审查代码或行为，并熟悉svn或svn工具，他们就可以利用这些知识。他们只是不会处于完全开发模式。
保持svn over git的原因主要是熟悉，所以你最好的选择可能是A：
使用基本命令集进行教育，该命令集允许某人将他们最基本的行为从svn思维转换为git用法（http://git.or.cz/course/svn.html）。这样他们可能没有做到git提供的最好的东西，但他们将能够做到需要获得git承诺的简单基础。
和B：
代表一段时间。虽然有些人正在学习git，但让他们在更加知识渊博的git用户的上游提供补丁/分支以合并功能，＆amp;帮助他们，直到他们达到速度和舒适的工具。
最后，没有太多关于ftp是svn的事实，因为svn是git，为了利用这些优势，你需要非常充分地投入。