最近我读了很多关于GIT-SVN桥的东西,自己尝试过,但是当事情变得粗糙时我会失败。
环境 我们是两个团队:一个使用SVN,另一个是反叛并使用GIT。为了同步,我在2个回购之间创建了一个桥梁。 SVN团队有x个开发人员每天推送10次并且主要是红色构建,GIT团队有6个开发人员,他们想要每周只获取一次或者他们有什么要提交,所以他们保持构建大部分为绿色。
使用案例 “桥”不是自动的(还),因此它在我的计算机上,所以我负责合并分支并正确地提交它们。 因此,GIT团队分为两部分:其中一些工作在分支“branch1”上,其余部分工作在“branch2”上。它们总是成对工作,所以当“branch1”完成时,我们为下一个任务创建另一个分支。
我尝试做的事情: 为了清楚起见,我从master创建了一个名为“masterSpace”的分支。我每天早上都会在master上执行git-svn rebase,然后将更改合并到masterSpace中。开发人员在需要devs提交东西的时候从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周后事情变得很糟糕......然后我的工作流程失败了。 在我退出之后,相同的提交在主人和“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”是多余的,它永远不会像我想象的那样工作。不过,我必须为dcommits找到一个快速的解决方案,这样我的团队就不会浪费时间或代码。一些有用的信息:我们每2周改变一个分支aprox。完成后,我们可以丢弃已使用的分支并从主分区创建另一个分支
Q2:如何自动制作所有内容? 在不久的将来,我打算在詹金斯身上移动我的“桥梁”。是否有可能找到使其自动运行的解决方案?像在“jenkinsbranch”上合并一个分支的东西。 Jenkins会自动构建这个分支,如果它的绿色它会提交它,如果没有,等待另一个将修复构建的推送
在我的初始场景中,我计划在jenkins上将“masterSpace”作为“主人”。开发人员将他的分支合并到“masterSpace”中,jenkins会自动生成一个svn-rebase并自动构建它,如果它是绿色的则然后提交所有更改。否则,它等待开发人员修复构建。但是......好像我错了。
TL:DR 当一个团队在两个不同的分支机构工作几周并希望在SVN中同意这些分支并与SVN保持同步时,正常的工作流程是什么?
答案 0 :(得分:0)
我曾在git-svn这样的环境中工作,可以说当双方的变化/冲突率很高时,同步很难顺利进行。在您的设置中,我会尝试查看SubGit是否与他们声称的一样好。
如果你坚持使用git-svn,可能会让你的生活更轻松的几种技术:
masterSpace
或master
定期对您的工作分支进行重新定价。 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
的顶部,并携带{{ 1}}对这些更改(master
),取结果git push . HEAD:master
的分离的HEAD,并对master
进行dcommit。在此阶段,由于svn dcommit,我们将再次获得svn/trunk
和svn/trunk
具有相同内容但不同的修订版本。同样,我会将master
与svn/trunk
进行技术合并,以标记平等点。