因为我一直在使用 Git，所以我喜欢这样一个事实，即您可以创建一个本地分支，您可以将其压缩到您的主分支并 DCommit 到 SVN（在主干上），然后删除该本地分支（在 Git 上）。
现在我想了解如何处理 SVN 分支。我需要与团队合作开发一项新功能，但我们不想在 Trunk 上这样做。所以显然我们需要从主干分支并在该分支上工作，直到我们对工作感到满意并合并回主干。
从 Git 前端的角度来看如何做到这一点有什么想法吗？我敢肯定那里有很多资源，但我还没有找到可以向我解释的东西。
所以只是为了确保我解释自己，我知道如何单独使用 Git 和 SVN 主干。这很容易也很好。但是我需要从主干分支到 SVN 并使用 Git 在该分支上工作（同时希望仍然可以使用 Git 访问 SVN 主干）直到工作完成，然后将该分支合并回 SVN 上的主干（再次使用 Git）。如果有人可以让我对此有所了解，我将不胜感激！是否可以在单个 Git 存储库中拥有它？
提前致谢。（如果仍然不清楚，请告诉我）。
几个月前我写了一篇关于这个话题的博客：http ://www.jillesvangurp.com/2012/08/04/git-presentation/
简而言之，您可以在单个 git 存储库中跟踪多个 svn 分支，但您确实不应该这样做。有一次搞砸了，我基本上再也不会尝试在一个存储库中跟踪多个 svn 分支了。它太易变了，太容易在svn中造成重大损害。基本上，本地一切似乎都很好，我提交了我的更改。但实际上我重新排序了一些确实不应该重新排序的提交，并且在上游造成了很多损害。最后我不得不做一个大的 svn 还原。很尴尬。
因此，改为使用单独的 git 存储库来跟踪每个 svn 分支，并将这些存储库用作仅 git 存储库上的远程存储库，在该存储库中，您实际工作时将其推送到不同的远程存储库。像这样隔离 git 和 svn 很有意义。确保保持你的历史线性（svn 不做非线性），并确保始终针对上游进行 rebase。
在这种情况下，在分支/存储库之间移动提交（在 git 世界中也是如此）的一种更安全的方法是使用 git format-patch 和 git am。或者，您可以在存储库中使用 git cherry-pick。
我终于发现了使用 Git 处理 SVN 分支需要做什么。我已经尝试过下面提到的东西（除了我指定的地方），所以我相当有信心，只要我不做任何有趣或不合时宜的事情，我从 Git 到 SVN 的提交应该可以正常工作。但当然我对可能发生的任何问题不承担任何责任！我愿意接受进一步的评论/评论。
即使我不使用标准布局克隆 SVN 存储库，我也应该配置指向 subversion 上相关 SVN 路径的遥控器。
克隆一个 SVN 分支（SVN 路径应该指向包含主干、分支和标签的根路径）：
git svn clone -s http://myrepo.com c:/my/local/path
如果您已经有一个 SVN 分支的克隆，您需要手动将遥控器添加到其他 SVN 分支，请查看以下内容：
重要的是您有一个跟踪远程分支的本地分支。
git checkout -b localbranch remotes/remote_branch
现在您可以提交该本地分支，并且每次完成后都可以像在主干中一样执行此操作：
git svn fetch
git svn dcommit
当您最终完成该 SVN 分支并希望合并到主干时，您可以执行以下操作（它从该分支获取所有内容并将其重新设置为 master）：
git checkout master
git merge localbranch
git rebase -i trunk (just save the message)
git svn fetch
git svn dcommit
如果你愿意，你也可以只做一个壁球合并（如果你不想把所有这些小签到都带过来）：
git merge --squash localbranch
git svn fetch
git svn dcommit
在执行真正的 DCOMMIT 之前，您可能会进行试运行以确保一切正常（包括目的地）。
git svn dcommit -dry-run
但是，如果您预计合并冲突（这是我在网上看到的，但我没有尝试过，我只是提到），请在git checkout master上面显示的行之前执行以下操作。这是一个本地分支，它不跟踪应该用于解决合并冲突和东西的远程分支。这是否有必要是另一回事。
git checkout -b merge_work master
git merge localbranch
git checkout master
git rebase merge_work
我为自己和其他可能想在未来尝试这个的人写下来。