2个团队的git-svn bridge的常规工作流程

Question

最近，我读了很多有关GIT-SVN桥的东西，我自己尝试了一下，但是当事情变得艰难时，我以某种方式失败了。

环境我们有2个团队：一个使用SVN，另一个是反叛者并使用GIT。 为了同步，我在两个仓库之间建立了一座桥梁。 SVN团队有x个开发人员，一天要推送10次，并且大部分都是红色版本，GIT团队有6个开发人员，他们只想每周获取一次，或者在有东西要提交的时候，只获取一次，以便使构建大部分保持绿色。

用例： “网桥”不是自动化的（还），因此它在我的计算机上，因此我有责任合并分支并正确地提交它们。 因此，GIT团队分为2个团队：其中一些在“ branch1”分支工作，其余的在“ branch2”分支工作。 它们始终成对工作，因此当完成“ branch1”时，我们将为下一个任务创建另一个分支。

我试图做的事情：为了保持清晰，我从master创建了一个分支，称为“ masterSpace”。 我每天早上都在master上做git-svn rebase，然后将更改合并到masterSpace中。 在需要开发人员提交内容的地方，开发人员可以从masterSpace“ branch1”创建。 完成后，我必须在SVN上提交所有内容。 我尝试过这样

merge "branch1" into "masterSpace".
checkout master
git svn rebase
git rebase masterSpace
git dcommit
git checkout masterSpace
merge "master" into "masterSpace". 

然后，开发人员将从该masterSpace创建一个新分支，使所有内容都保持最新状态，然后过程重复进行

问题：我在只有一次提交且运行良好的分支上进行了尝试，但经过2个星期的工作后事情变得很艰难……然后我的工作流失败了。 取消提交后，相同的提交在master和“ masterSpace”上具有不同的ID，因此下次我尝试取消提交时，遇到了很多冲突。 即使我将master合并到masterSpace之后。 我什至尝试了一个简单的场景，其中：

 I have a "branchX" with changes
 I merge them on "masterSpace"
 rebase them on master and finally dcommit them.
 Then I made a single change on "masterSpace" 
 I rebased it into "master"

在此之后，我就像提前了10次提交（因为我猜为先前提交的ID）。 所以...死胡同

Q1：解决方案？ 什么是我们的环境和用例的正确工作流程，以便GIT和SVN团队都可以同步和和平地工作？ 我决定“ masterSpace”是多余的，它将无法像我想象的那样工作。 尽管如此，我仍然必须为dcommit找到一个快速的解决方案，这样我的团队才不会浪费时间或代码。 一些有用的信息：我们每2周更改一次分支。 完成后，我们可以丢弃使用过的分支，并从主分支创建另一个分支。

问题2：如何自动制作所有内容？ 在不久的将来，我计划在詹金斯上移动我的“桥梁”。 是否有可能找到使它自动运行的解决方案？ 类似于在“ jenkinsbranch”上合并分支。 Jenkins自动构建此分支，如果绿色则放弃提交，如果没有，则等待另一次修复构建的推送

在我的初始方案中，我计划将jenkins上的“ masterSpace”作为“ master”。 开发人员会将其分支合并到“ masterSpace”中，詹金斯将创建一个svn-rebase并自动构建它，如果它为绿色，则放弃所有更改。 否则，它等待开发人员修复构建。 但是...似乎我错了。

TL：DR如果一个团队在2个不同的分支上工作几个星期并希望在SVN中将其提交（并与SVN同步），那么正常的工作流程是什么？

Answer 1

我曾在git-svn的环境中工作过，可以说当双方的变更/冲突率很高时，很难使同步变得平滑。 在您的设置中，我将尝试查看SubGit是否像他们声称的那样好。

如果您坚持使用git-svn，可能会使用以下两项技术使您的生活更轻松：

• 尽量避免合并，并在各处使用rebase。 包括工作分支。 回答第3季度-根据masterSpace或master定期调整工作分支的masterSpace 。
• 为了方便同步，我会将masterSpace分开。 在我的情况下，我称它为master ，其中svn分支将使用svn前缀，例如svn/trunk 。 对于其他镜像的svn分支类似。 我将进一步使用我的命名。
• 我不会将master svn/trunk 。 相反，我会先将svn/trunk更改重新设置为master （如果有）。 在这一点上，我将svn/trunk技术合并为master 。 这些修订的状态应该是相等的（您可以检查git diff svn/trunk master ），以防万一发生合并冲突-只需与-s ours合并，尽管我认为git的最新版本在这种情况下足够聪明。 现在， master等于svn/trunk和git知道这个通过技术融合，我想变基被合并到顶部从工作分支的变化master ，携带master对这些变化（ git push . HEAD:master ） ，从结果master获取一个分离的HEAD，然后对svn/trunk进行dcommit。 在这一阶段，我们将再次获得svn/trunk和master ，它们具有相同的内容，但由于svn dcommit而具有不同的修订版。 再次，我将svn/trunk技术合并到master来标记一个平等点。