我最近一直在使用git-svn通过git管理一个旧的svn存储库。
我最近一直在这样创建的分支机构工作：
git checkout -b local-branch svn-branch
之后我一直在那个分支工作，并使用以下方式回到svn-branch：
git svn dcommit
现在是时候将本地分支合并回主人了我试着做以下事情：
git checkout master
git merge local-branch
到目前为止，这么好。现在我想将合并提交给subversion，所以我试试这个：
git svn dcommit
然而，现在我的主人正在回复svn-branch分支，而不是我预期的主干。有没有我想念的东西，或者这种合并只是不建议在这样的svn分支之间合并？
作为旁注，我改为通过svn进行合并，但我希望避免尽可能多地使用svn。处理这个问题的首选方法是什么？
答案 0 :(得分：3)
git svn dcommit始终将更改发送到git-svn-id签名中指定的url，该签名是HEAD历史记录中第一个父提交链的最新内容。
我想，你的合并是快速转发的（即主引用可以从local-branch / svn-branch访问），所以它只是通过“git merge”设置为local-branch而不是合并提交创建。
作为建议总是使用--no-ff选项和“git merge”，因为Subversion没有快进合并这样的概念。 （您可以将此选项（merge.ff=true）设置为config [或branch.master.mergeoptions至“ - no-ff”默认设置为Git＆lt; 1.7.6]但请注意“git pull “如果你使用超过1个遥控器，也会变得非快进”
为了避免使用SVN和/或git-svn：如果您可以访问存储库服务器，那么您可以查看提供纯Git（而不是git-svn）接口的SubGit项目。颠覆。即使在SubGit的情况下 - 强烈建议使用ff选项，因为无法将快进合并（和快进rebase）与分支移除和娱乐从另一个提交区分开（对于任何Git＆lt; - ＆gt; SVN都是如此）翻译工具）。
但也许任何其他原因（我不知道任何其他原因）在最新的提交消息中导致带有分支URL（而不是中继URL）的“git-svn-id”。无论如何要确保master指向正确的提交。