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

Question

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

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

以下是我们日常工作要做的。

1. A、B、C(小组中的人)进行编码工作。
2. A、B、C 将工作 checkin 到 git 分支 integration-test。
3. 将最新的变化从 SVN trunk 重新设置为 integration-test
4. 构建镜像并进行集成测试。
5. 测试通过，A、B、C 将他们的代码 checkin “SVN”
6. 转到第 1 步

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

那么，对于这种场景有什么好的做法吗？

Answer 1

你会遇到的一个问题是 git svn rebase 实际上重写了 git 存储库的提交历史。这将导致与从该 repo 中提取的任何人发生冲突。最好的解决方案是让每个人都自己git svn svn 存储库。

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

其他人可以使用 git pull --force 强制他们的本地存储库与远程存储库匹配。尽管被警告，因为这将使更改点之后所做的任何提交无效。例如，假设我们有以下提交结构:

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

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

       D----E  topicA----G----H----I  master

请注意提交 D 和 E 现在是如何漂浮在仙境中的？这是因为分支点现在不再与 B 匹配，而是现在的 G。

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

假设我们错误地从一个提交点创建了一个分支，这将导致上述的漂浮仙境。那么，在启动 git pull --force 之前，您必须挥动 git wonder 魔杖。像这样:

糟糕。 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 存储库旁边运行中央访问 git 存储库的痛苦。