使用子git将git分支合并到svn分支

我正在使用BitBucket的Subgit插件将svn存储库镜像为git存储库。只有主干分支（在git中称为master）被标记为同步，但是使用git存储库的开发人员已经创建了一个功能分支，并向git分支提交了十几个提交（未同步）

现在两个分支都有几个提交，我们希望将git功能分支合并回trunk svn分支。subgit文档并不完全清楚以下各项是否有效：

git checkout master
git merge feature
git push

另一件需要注意的事情是，合并将需要合并提交，因为存在必须解决的冲突

• subgit是否支持此工作流
• 这会扰乱SVN回购协议吗
• 是否会保留功能分支上的所有单个提交
• 或者我应该将功能分支重新设置到master上，然后按下按钮吗

此工作流

git checkout master
git merge feature
git push

由SubGit支持（在本例中这无关紧要，但我建议使用

git merge --no-ff feature

防止快进合并）；结果取决于您的配置。我将描述几个案例

案例1。（不是您的情况，但需要知道）如果主干和分支都配置为通过SubGit同步。在这种情况下，效果相当于“svn merge”命令：

svn:mergeinfo

将被更新。当然，特性分支中的单个提交也将进入SVN，因为特性分支被配置为同步

案例2。（我认为，在您的案例中，请选中“sheelds=”选项以确保）只有trunk配置为要翻译，而feature分支没有；此外，在存储库的SVN镜像加载项设置中设置了“sheelds=”选项，该选项通常如下所示：

shelves = shelves/*:refs/shelves/*

但准确的数值并不重要。 在这种情况下，“git push”将推送来自主分支和功能分支的所有提交（即使您没有显式推送功能分支），因为提交可以通过“merge commit parent”链接访问。另一方面，功能分支Git引用不会被推送，因此SubGit无法知道功能分支的名称。在这种情况下，SubGit将在SVN中的“shelfs”名称空间中发明一些临时名称，例如，

shelfs/shelf

，对应于功能分支的提交。然后它将一个接一个地将这些个人提交翻译成SVN。最后，它将在SVN主干中创建一个合并提交，更新

SVN:mergeinfo

；毕竟，它将删除SVN中的

shelfs/shelf

（但您可以使用旧版本引用它，Subversion永远不会忘记）

为了更好地理解这一点，我建议这样做。第二张图片对应于这种情况，例如情况2，而第一张图片对应于情况1

案例3。（不是您的情况，但有些用户更喜欢这种行为）只有trunk配置为转换，而feature分支不是；而且您根本没有“sheelds=”选项。在这种情况下，SVN中将忽略功能分支中的所有单个提交，

SVN:mergeinfo

将不更新。因此，您将在SVN主干中获得所有更改，但不是作为单个提交，而是作为单个SVN提交，将所有更改压缩在一起，就像您正在使用

git merge --squash feature

而不是

git merge feature

请注意，在Git端，单个提交仍将被保留，它们只是不会被转换为单个修订

我还想补充一点，在SVN镜像加载项中，不仅支持此工作流，而且您或您的团队成员也可以使用Bitbucket服务器UI创建一个请求，然后使用UI将其合并。本例中的行为与使用“git merge”+“git push”时大致相同，即它将是上述3种情况之一

你的其他问题呢：

• 这会扰乱SVN回购协议吗

不，不会的，尽管这取决于你对混乱的定义。有些人更喜欢“案例2”，称“案例3”一团糟，另一些人则持相反意见。在这两种情况下，您都可以配置附加组件以实现所需的行为

• 是否会保留功能分支上的所有单个提交

在案例1和案例2中——是，在案例3中——否，它们将被压缩为单个SVN版本。在所有情况下，单个Git提交都将按原样保留

• 或者我应该将功能分支重新设置到master上，然后按下按钮吗

你可以，但我不建议你那样做。一般来说，我建议使用

git-pull--rebase

，而不仅仅是

git-pull

。但是当合并一个特征分支时，合并它比重新设置它的基础要好。如果您重新设置它的基址，您将直接在主节点（因此在SVN主干节点）中看到来自特性分支的单个提交，这一部分就可以了。但是功能分支引用将被更新，您必须

使用

--force

选项推送更新后的功能分支参考，通常不建议这样做；或

保持功能分支不变，因此本地具有不一致的功能分支引用及其提交重复集两次：在“主”和功能分支中

这与SubGit无关（SubGit只会将它在“master”中找到的内容转换为SVN trunk），但会给纯Git带来不便

---

我是SubGit开发者之一。

忘了svn吧。@0andriy我希望我能！！！但SVN回购协议是一种古老的现有回购协议，企业目前不愿放弃。折衷的办法是使用Subgit，这样一些开发人员就可以使用git了。。。我希望你们能找到一些解决方案，尽管更明显的是SVN被遗忘了。看起来我实际上是在案例3中！我删除了配置中的shelfs选项，将其添加回来会给我一个超时（svn repo在慢速连接上是远程的）。我已决定重新设置该功能的基础