我的项目中出现了一些复杂的颠覆合并：长期分离的大分支。 Svn给出了太多的冲突 - 其中一些似乎是虚假的。
鉴于git因为优秀的合并经验而受到称赞，
将git-svn 仅用于使合并更易于管理的好处是否有用？
你能推荐其他替代方案（例如svk，hgsvn）来减轻合并的痛苦吗？
有些冲突很容易解决（例如java import，whitespaces） - 所以我也想知道是否有任何自动解决方案。
将来可能会完全切换到DVCS（我们中的一些人会喜欢），但现在不行。 （更新：这不再是真的 - 团队最近完全切换并对此感到高兴。）
提前致谢。
PS：有些帖子似乎有关（例如git-svn merge 2 svn branches），但他们没有完全回答这个问题。
更新：看完我的-novice-回答后再向下（和向上:)这条路。
答案 0 :(得分：34)
答案 1 :(得分：3)
我自己刚刚解决了这个问题。 simpler method将传递git merge --squash选项，该选项将执行合并而不记录合并提交，保持历史呈线性，以免混淆git-svn。
我的合并也非常大，我必须设置git config diff.renamelimit 0以便git能够正确找到所有重命名。
答案 2 :(得分：3)
有一些新工具可以修复git-svn的许多问题，并为使用Subversion和Git提供更好的体验。
除此之外，这些工具还解决了一些分支和合并问题。以下是概述：
GIT-SVN
来自文档：
CAVEATS
...
不建议在您计划提交的分支上运行git merge或git pull。 Subversion不以任何合理或有用的方式表示合并;因此使用Subversion的用户无法看到您所做的任何合并。此外，如果您从作为SVN分支的镜像的git分支合并或拉出，则dcommit可能会提交到错误的分支。
不提交合并提交主要有三个原因：
git-svn不会自动为合并分支发送svn：mergeinfo属性。结果Subversion无法跟踪git执行的那些合并。这包括正常的Git合并和樱桃选择。
由于git-svn不自动转换svn：ignore，svn：eol-style和其他SVN属性，因此合并提交在Git中没有相应的元数据。因此，dcommit不会将这些属性发送到SVN存储库，因此它们会丢失。
dcommit始终将更改发送到合并提交的第一个父级引用的分支。有时，更改会显示在用户不期望的位置。
SubGit是一个Git-SVN双向服务器端镜像。
如果有人可以本地访问Subversion存储库，可以将SubGit安装到其中：
$ subgit configure $SVN_REPOS
# Adjust $SVN_REPOS/conf/subgit.conf to specify your branches and tags
# Adjust $SVN_REPOS/conf/authors.txt to specify git & svn authors mapping
$ subgit install $SVN_REPOS
...
$ INSTALLATION SUCCESSFUL
此时SubGit将Subversion存储库转换为Git（它也在相反的方向工作）并安装SVN和Git钩子。结果Subversion和Git存储库是同步的：每次提交和推送都会启动挂钩，立即转换传入的修改。
SubGit将svn：ignore属性转换为.gitignore文件，将svn：eol-style和svn：mime-type属性转换为.gitattributes，因此Git中的合并提交会保留此元数据。
当推送合并提交时，SubGit会将所有新提交转换为Subversion修订版。它尊重svn：mergeinfo属性，因此SVN之后会正确跟踪合并操作。
即使用户推送非常复杂的Git历史记录，SubGit也会转换所有提交，使合并跟踪数据保持有效。我们曾经立即推出了git.git存储库的整个历史记录，并将其正确转换为SVN。
SubGit是一种商业产品。它对于开源和学术项目以及最多10个提交者的项目都是免费的。
有关详细信息，请参阅SubGit documentation和git-svn比较页。
SmartGit是git-svn的客户端替代方案。
SmartGit还支持svn：ignore，svn：eol-style和svn：mime-type属性转换。它还为合并提交设置了svn：mergeinfo属性。它甚至为cherry-pick提交更新了必要的合并跟踪数据。
SmartGit是商业Git和Mercurial客户端。它可以免费用于非商业用途。
完全披露：我是SubGit开发人员之一。