与主svn仓库使用git-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步

的问题是：因为我们的改变已经提交到Git的分支integration-test在步骤2中。并且我们在步骤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之前，你必须挥动混乱的魔杖。像这样：

糟糕。 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 

希望这解释了尝试运行中央访问git回购一边svn回购的痛苦。