使用git-svn使用主svn存储库的git工作流

Roc*_*cky 3 git git-svn

我是一个使用SVN作为修订控制的大团队.

我是大团队的一个小组,试图使用git对这个子组的代码进行一些集成测试.

以下是我们想要为dailay工作做的事情.

  1. A,B,C(小组中的人)进行编码工作.
  2. A,B,C将工作检查到git分支integration-test.
  3. 变基从最新的变化SVN trunkintegration-test
  4. 构建映像并进行集成测试.
  5. 测试通过,A,B,C检查他们的代码为'SVN'
  6. 转到第1步

问题是:因为我们的更改已integration-test在步骤2中提交到git分支中,并且我们SVN在步骤5 中将更改提交到了.因此,在下一轮的第3步中,合并将对所有更改产生冲突.

那么,这种情况有一个很好的做法吗?

Tre*_*ris 5

您将遇到的一个问题是git svn rebase实际上重写了git存储库的提交历史记录.这将导致与从该回购中撤出的任何人发生冲突.最好的解决方案是每个人都可以git svn自己访问svn存储库.

如果你想设置一个远程仓库,这样你就可以共享分支,那么每个人都必须要知道,如果远程git分支被重新命名为svn,他们将不得不强制将新的修订历史记录应用到他们的本地git repos.

其他人可以通过使用强制他们的本地回购匹配遥控器git pull --force.虽然被警告,因为这将使改变点之后的任何提交无效.例如,假设我们有以下提交结构:

       D----E  topic
      /
A----B----C----F  master

然后我们git pull --force用来更新我们的本地存储库,然后从那里开始更改提交的sha1 B.我们的新结构如下所示:

       D----E  topic

A----G----H----I  master

注意提交DE现在如何漂浮在奇迹之地?这是因为分支点现在已不再有什么相匹配B,但现在是G.

要解决此问题,您需要确保本地分支点源自不会通过运行更改的提交git svn rebase.强制拉动遥控器后,您可以git rebase将本地分支更新为远程分支.

假设我们错误地从提交点创建一个分支,这将导致上面描述的浮动仙境.那么,在你开始之前你必须挥动git奇迹魔杖git pull --force.像这样:

哎呀.B将被覆盖pull.

       D----E  topic
      /
A----B----C----F  master

那么,我们只需要对git rebase A topic不会改变的提交进行更改.

  D'---E'  topic
 /
A----B----C----F  master

然后,一旦变化进入,我们就可以git rebase G topic将我们的变化带回到我们知道的变化.

       D'---E'  topic
      /
A----G----H----I  master

希望这解释了尝试在svn repo旁边运行中央访问git repo的痛苦.