首先,感谢Matthew提供的链接——它们对我解决这个问题非常有帮助。
虽然可能需要一些小心和很可能存在与提交者数量有关的限制,但这是可以做到的。我的用例基本上就像mitjak描述的那样;单个用户需要或希望利用两个远程存储库,一个是SVN,另一个是Git。在我的情况下,前者位于防火墙后面的工作场所,而后者则在外部(也是私人的)。目标是能够使用Git在本地副本上工作并使两个远程存储库保持同步。
我的步骤:
所有操作都依赖于一个事实:git svn dcommit会更改与原始git提交相关联的SHA1。牢记这一点之后,在本地进行提交后,我[可选git svn rebase
然后] git svn dcommit
,生成最终的SHA1。此时,我将其推送到我的远程git存储库中。如果像Chacon所说的那样,你只想使用git提供更高效的克隆点,那么你已经完成了。但是,你可能还希望能够:
- 从另一个本地“纯git”存储库推送到远程git存储库,然后
- 同步混合git/svn存储库,然后
- 将这些更改推送到SVN存储库。
第1步没有问题;在本地“纯git”存储库提交后,git push
到远程git存储库。
第2步也没有问题;回到你的混合git/svn存储库,在远程git存储库中git pull
更改。此时,新拉取的修订版本关联的SHA1与远程git存储库中的SHA1同步。
第3步是整个过程变得有点棘手的地方。你可以像上面描述的那样使用git svn dcommit
将这些更改推送到SVN存储库,但此时情况与上述情况有所不同。在这种情况下,你现在在远程SVN和git存储库中拥有相同的修订版本,但由于dcommit,它们具有不同的SHA1。我以以下方式处理:
在第2步中进行拉取时,我注意到相关的起始SHA1;例如,
git pull
输入someone@example.org的密码:
远程:对象计数:5,完成。
远程:压缩对象:100%(3/3),完成。
远程:总共3个(增量0),重用0个(增量0)
解包对象:100%(3/3),完成。
来自ssh://example.org/pub/scm/demonstrate
34b6260..17cd887 master -> origin/master
更新34b6260..17cd887
快速前进
file3 | 2 +-
1个文件已更改,插入1个(+),删除1个(-)
所以这里感兴趣的SHA1是34b6260。 git log origin
应该会确认这是远程git存储库中具有与之关联的git-svn-id的最后一次提交。然后我执行以下操作:
git push -f origin 34b6260:master
执行强制更新远程存储库,以排除我从“纯git”本地存储库中进行的“纯git”提交--请小心使用!在这种情况下,我知道我在本地拥有这些提交;它们只是具有不同的SHA1与dcommit。然后,我git push
到远程存储库,添加刚刚删除的提交的“git-svn-id”版本,远程存储库同步。
重新将“纯git”本地存储库与远程git存储库同步是最后一步,但类似的注意会产生令人满意的结果。在这种情况下,远程git存储库现在包含提交的“git-svn-id”版本,而本地的“纯git”存储库仍然包含原始SHA1。处理这种情况最简单的方法是从远程git存储库中git fetch
,然后使用git reset --hard origin
强制本地git存储库镜像远程状态。