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

Question

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

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

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

1. A，B，C（小组中的人）进行编码工作。
2. A，B，C将工作检入git分支integration-test。
3. 将最新更改从SVN trunk重新定位到integration-test
4. 构建图像并进行集成测试。
5. 测试通过，A，B，C检查他们的代码为'SVN'
6. 转到第1步

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

那么，这种情况是否有良好的做法？

Answer 1

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

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

其他人可以使用git pull --force强制他们的本地存储库与遥控器匹配。虽然被警告，因为这将使改变点之后的任何提交无效。例如，我们有以下提交结构：

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

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

       D----E  topic

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

请注意提交D和E现在如何漂浮在奇迹之地？那是因为分支点现在不再与B匹配，但现在是G。

要解决此问题，您需要确保您的本地分支点来自一个不会因运行git svn rebase而改变的提交。强制拉动遥控器后，您可以git rebase将本地分支更新为远程分支。

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

糟糕。 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的痛苦。