我是一个使用SVN作为修订控制的大团队.
我是大团队的一个小组,试图使用git对这个子组的代码进行一些集成测试.
以下是我们想要为dailay工作做的事情.
integration-test.SVN trunk来integration-test 问题是:因为我们的更改已integration-test在步骤2中提交到git分支中,并且我们SVN在步骤5 中将更改提交到了.因此,在下一轮的第3步中,合并将对所有更改产生冲突.
那么,这种情况有一个很好的做法吗?
您将遇到的一个问题是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
注意提交D和E现在如何漂浮在奇迹之地?这是因为分支点现在已不再有什么相匹配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的痛苦.
| 归档时间: |
|
| 查看次数: |
141 次 |
| 最近记录: |