3

我在一个使用 SVN 作为修订控制的大团队中。

我在一个大团队的一个小组中，他们尝试使用 git 对该小组中的代码进行一些集成测试。

以下是我们想要为日常工作做的事情。

  1. A、B、C（小组中的人）做他们的编码工作。
  2. A,B,C 将工作签入 git branch integration-test。
  3. 将最新更改从SVN trunk重新设置为integration-test
  4. 构建镜像并进行集成测试。
  5. 测试通过，A、B、C 将他们的代码签入“SVN”
  6. 转到第 1 步

问题是：因为我们的更改已经integration-test在步骤 2 中提交到 git 分支。我们在步骤 5 中提交了更改SVN。因此，在下一轮的步骤 3 中，合并将与所有更改发生冲突。

那么，这种情况有没有好的做法？

4

1 回答 1

5

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

如果你想设置一个远程仓库以便共享分支，那么每个人都必须知道，如果远程 git 分支被重新设置为 svn，他们将不得不强制将新的修订历史应用到他们的本地 git 仓库。

其他人可以使用git pull --force. 尽管被警告，因为这将使更改点之后所做的任何提交无效。例如，假设我们有以下提交结构：

       D----E话题
      /
A----B----C----F大师

然后我们使用git pull --force更新我们的本地存储库，然后更改从 . 开始的提交的 sha1 B。我们的新结构将如下所示：

       D----E话题

A----G----H----我师傅

请注意提交D和E现在如何漂浮在奇妙的土地上？那是因为分支点现在不再与过去匹配B，而是现在G。

要解决这个问题，您需要确保您的本地分支点源自不会被运行更改的提交git svn rebase。强制拉远程后，您可以git rebase将本地分支更新到远程分支。

假设我们犯了从提交点创建分支的错误，这将导致上述浮动仙境。好吧，那么您必须在启动git pull --force. 像这样：

哎呀。B将被覆盖在pull.

       D----E话题
      /
A----B----C----F大师

好吧，那么我们只需要git rebase A topic在不会更改的提交上进行更改。

  D'---E'主题
 /
A----B----C----F大师

然后，一旦发生更改，我们就可以git rebase G topic将更改恢复到我们知道它们所在的位置。

       D'---E'主题
      /
A----G----H----我师傅

希望这可以解释尝试在 svn 存储库旁边运行中央访问 git 存储库的痛苦。

于 2012-05-09T05:56:55.797 回答