Question

我们使用Subversion作为主要VCS。我使用Git作为方便的客户端。现在我无法正确地将功能分支合并到发布分支中。

最初功能分支（功能）是从发布分支（ Release1.0 ）创建的。后来人们意识到 Release1.0 已经关闭，现在该功能应该基于 Release2.0 开发。
没问题。

git rebase --onto Release2.0 HEAD~30

有些提交匹配Release2.0分支中的代码演变

git rebase -i HEAD~14

此时我决定不再对svn进行更改，但是将所有开发历史记录保留在功能分支中并与发布分支合并（以后我可能会将其发送到另一个地方）

svn rm ....feature
svn cp ....Release2.0 ...feature -m"Feature based on Release2.0"
git svn fetch && git svn rebase
git branch tmp Release2.0 && git checkout tmp
git rebase --onto feature HEAD~35
git checkout feature && git merge tmp
git svn dcommit

为了使svn：mergeinfo保持同步，我在svn

中进行了实际的合并

svn merge -rxxx:yyy feature
git-svn  fetch && git svn rebase

完成？没有！根据Git，功能分支和Release2.0分支未合并。 Release分支只有一个额外的提交。

问题是：虽然功能分支已被删除并且从另一个地方重新创建，但Git此时显示了合并。因此它拒绝显示合并操作（存在未合并的提交，但它们来自分支的已删除部分）因此，在这种情况下创建功能分支时应使用其他名称以避免此类问题。

好吧，我已经得到了教训，现在我知道将来如何避免这种情况，但现在是否可以解决这个问题，或者是否有可能在将来以其他方式解决这个问题？我试图手动更改svn：mergeinfo它可以工作，但这意味着我需要标记所有提交，直到分支点合并在svn：mergeinfo中。

Answer 1

这似乎证实了 git-svn 关于rebase的限制，如CAVEATS section所示：

为了简化和与Subversion互操作，建议所有git svn用户clone，fetch和dcommit直接来自SVN服务器，并避免全部git存储库和分支之间的git clone/pull/merge/push操作。

您可以在SVN端重新创建合并信息，但Git不会在git-svn fetch＆amp;＆amp; git svn rebase。
默认情况下，git-svn不关心merginfo。

但是，“Can git-svn correctly populate svn:mergeinfo properties?”提及

git-svn的当前状况自提出以来已发生变化   具体来说，在git 1.7.5中，在svn:mergeinfo返回svn时设置dcommitting的支持有限。

git svn dcommit现在接受-mergeinfo=<mergeinfo>标记。

使用与已删除的名称相同的名称创建的合并分支

1 个答案: