0

最近我读了很多关于 GIT-SVN 桥的东西，我自己尝试过，但是当事情变得艰难时我不知何故失败了。

环境 我们是2个团队：一个用SVN，一个用rebel，用GIT。为了同步，我在 2 个存储库之间建立了一座桥梁。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 周的工作后事情变得很糟糕......然后我的工作流程失败了。在我 decommited 之后，相同的提交在 master 和“masterSpace”上有不同的 ID，所以下次我尝试 dcommit 时，我遇到了很多冲突。即使在我将 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”是多余的，它永远不会像我想象的那样工作。不过，我必须为 dcommits 找到一个快速的解决方案，这样我的团队才不会浪费时间或代码。一些有用的信息：我们大约每 2 周更换一个分支。完成后，我们可以扔掉用过的分支并从master创建另一个

Q2：如何让一切自动化？ 在不久的将来，我计划将我的“桥梁”移到詹金斯身上。是否有可能找到一种解决方案使其自动运行？比如在“jenkinsbranch”上合并一个分支。Jenkins 自动构建这个分支，如果它是绿色的，它会提交它，如果不是，等待另一个推送来修复构建

在我最初的场景中，我计划将“masterSpace”作为 jenkins 的“master”。开发人员会将他的分支合并到“masterSpace”中，jenkins 会创建一个 svn-rebase 并自动构建它，如果它是绿色的，则 dcommits 所有更改。否则，它会等待开发人员修复构建。但是……好像我错了。

TL:DR 当一个团队在 2 个不同的分支上工作了几周并希望在 SVN 中提交它们（并与 SVN 同步）时，正常的工作流程是什么？

4

1 回答 1

0

我曾在这样的环境中使用 git-svn 工作过，并且可以说当双方的更改/冲突率都很高时，同步很难顺利进行。在您的设置中，我会尝试查看SubGit是否像他们声称的那样好。

如果你坚持使用 git-svn，一些可能会让你的生活更轻松的技术：

  • 尽量避免合并并在任何地方使用变基。包括工作分支。回答 Q3 - 根据您的masterSpace或master.
  • masterSpace为了方便同步，我会将您分开。在我的情况下，我将它称为mastersvn 分支将使用svn前缀的地方，例如svn/trunk. 对于其他镜像 svn 分支也是如此。我将进一步使用我的命名。
  • 我不会重新定位master到svn/trunk. 相反，如果有的话，我会首先将更改从svn/trunkon变基。在这一点上，我对intomaster进行了技术合并。这些修订的状态应该是相等的（你可以检查），所以如果你遇到合并冲突 - 只需与 合并，尽管我认为最近版本的 git 在这种情况下已经足够聪明了。现在这等于并且 git 通过技术合并知道这一点，我会将工作分支中的更改重新合并到d 承诺。在这个阶段，我们将得到并且svn/trunkmastergit diff svn/trunk master-s oursmastersvn/trunkmastermastergit push . HEAD:mastermastersvn/trunksvn/trunkmaster由于 svn dcommit 再次具有相同的内容但不同的修订。同样，我会做一个技术合并svn/trunktomaster来标记一个相等点。
于 2015-03-24T18:42:31.493 回答