小开

嗯。.在我的公司，我几乎也在做同样的事情。两者兼而有之。Svn 和。在同一目录下创建 git repo (在这个工作副本中检出 svn repo 并创建 git repo)。

然后使用 svn up 和 git push 完成这件事。当然，如果你分歧很大，你将不得不手工合并东西。

小开

最佳答案

来自 Git-svn 的远程分支与普通的 Git 远程分支非常相似。因此，您可以在本地存储库中克隆 git-svn 并将更改推送到 GitHub。Git 不在乎。如果您创建了 git-svn 克隆，并将完全相同的更改推送到 GitHub，那么您将拥有一个 Google Code 存储库的非官方镜像。剩下的是香草 Git。

git svn clone http://example.googlecode.com/svn -s
git remote add origin git@github.com:example/example.git
git push origin master

现在你有了这个，有时候你需要同步 Subversion 存储库和 Git，它看起来像这样:

git svn rebase
git push

在 gitk 或者其他什么网站上，这个应该是这样的:

o [master][remotes/trunk][remotes/origin/master]
|
o
|
o

当你运行 git svn rebase的时候，你会看到:

o [master][remotes/trunk]
|
o
|
o [remotes/origin/master]
|
o
|
o

因此，现在运行 git push将把这些提交推送到 GitHub，即 [遥控器/原产地/主机]分支。您将回到第一个 ASCII 艺术图中的场景。

现在的问题是，如何将您的更改应用到混合中？其思想是，永远不要提交到您正在使用 git-svn-rebase 和 git-push 的同一个分支上。您需要一个单独的分支来进行更改。否则，您将最终在 Subversion 之上重新设置更改的基础，这可能会使任何克隆 Git 存储库的人感到不安。跟我来？好的，你创建了一个分支，我们称之为“特性”。然后提交一个提交，并将其推送到 GitHub 的特性分支。你的 GITK 应该是这样的:

o [features][remotes/origin/features]
|
o
|
o [master][remotes/trunk][remotes/origin/master]
|
o

在这里，你已经在 Google Code 分支之前提交了一些特性分支，对吗？那么，当你想要合并来自 Google Code 的新东西时，会发生什么呢？你先运行 git svn rebase，然后得到这个:

                           o [features][remotes/origin/features]
[master][remotes/trunk] o  |
|  o
o /
|/
o[remotes/origin/master]
|
o

如果你把 git push掌握出来，你可以想象 [遥控器/原产地/主机]和主机在同一个点上。但是您的特性分支没有变化。您现在可以选择将 master 合并到特性中，或者重新设置特性的基础。合并就像这样

git checkout features
git merge master


o [features]
/|
/ o [remotes/origin/features]
[master] o  |
|  o
o /
|/
o
|
o

然后将特性推送到 GitHub。为了节省空间，我把遥控器关掉了，它们应该和 [主人]在同一个点上。

Rebase 方法稍微有点邪恶——您必须使用——强制，因为您的推送不会是快速向前合并(您将从克隆它的人那里拉出功能分支)。这样做并不被认为是可以的，但是如果你下定决心，没有人可以阻止你。它确实使一些事情变得更容易，比如当补丁以稍微修改的形式被上游接受时。这样可以省去处理冲突的麻烦，您可以直接调整基础——跳过上传的补丁。无论如何，一个 rebase 应该是这样的:

git rebase master features


o [features]
|
o
|  o [remotes/origin/features]
[master] o  |
|  o
o /
|/
o
|
o

然后你必须要 git push --force。你可以看到为什么你需要强制它，历史有一个大的旧的分裂从 [遥控器/原产地/特征]到新的当前后基 [特写]。

这一切都工作，但它是一个很大的努力。如果你想成为一个常规贡献者，最好的办法就是像这样工作一段时间，向上游发送一些补丁，看看你是否可以获得 Subversion 的提交访问权。如果做不到这一点，也许就不要将更改推送到 GitHub。让他们留在本地，尽量让他们在上游被接受。

小开

我不太确定您想要的是什么，但是您当然可以从 subversion 存储库中提取并从相同的工作副本中推送到 Git 存储库。您也可以将 git svn dcommit返回到 subversion 存储库。但是，您不能让 GitHub 存储库与 subversion 存储库同步。此外，当您在工作副本中提交了还没有在 subversion 存储库中的内容时，如果 subversion 存储库已经更新，那么您将需要重新设置它们的基础，从而迫使您向 GitHub 提交“ new”内容。

小开

从 Google Code 到 GitHub 的同步演练可以在 Fnokd.com上找到。作者使用一个始终在线的远程服务器和 cron 作业来自动执行同步，并将 SVN 中继线保存在 GitHub 分支中，该分支称为“供应商”。

小开

GitHub 现在支持直接导入颠覆项目(参见 http://help.github.com/import-from-subversion/)。只需创建一个新的回购，然后在“下一步”屏幕上点击“从 Subversion 导入”。但是它不支持进一步的同步:/。

小开

Svn2github 服务

网站 http://svn2github.com/提供了将任何公开可访问的 SVN 存储库分叉到 Github (在 https://github.com/svn2github/projectname)的服务。我尝试了一下，在按下“制作一面镜子”后，它显然几秒钟内没有任何反应，并显示了消息“错误”，但它实际上工作了。新的存储库实际上已经创建，其中包含来自 SVN 回购的代码。

然后您可以使用它创建的存储库分支，并使用自己的分支。然后，您可以使用它们的 bug 跟踪器将您的更改提交给上游项目。

查看服务的 Github 用户下的现有存储库(例如“ svn2github 在5小时前被推向 svn2github/haxe 的主服务器”) ，它似乎经常从 SVN 存储库中获取更改。目前还没有关于谁在网站上运行这项服务的信息，所以我不敢打赌它会无限期地运行下去，但是它现在是有效的(如果它停止运行，你仍然可以手动更新你的分叉)。

发射台

如果您没有使用 Git 和 Github，另一种选择是使用 Launchpad.net。Launchpad 可以自动将 SVN (也是 CVS)存储库导入到个人 bzr 分支中。为此，创建 Launchpad 项目，然后转到新的导入页面，选择 Subversion 并输入 URL (例如 http://projectname.googlecode.com/svn/trunk/)。根据项目的大小，初始导入可能需要几个小时。随后的导入将定期运行。

有关更多文档，请参见在 Launchpad 帮助中导入 VCS。

小开

我在林的博客上发现了这些说明:

首先克隆 Subversion 存储库并推送到 Git:

git svn clone https://foo.googlecode.com/svn/ git-foo
cd git-foo
git remote add git-foo git@github.com:username/foo.git
git push git-foo master

在 Subversion 存储库中提交之后，运行

cd /path/to/git-foo
git svn fetch
git svn rebase
git push git-foo master

将 Google Code Subversion 存储库分叉并同步到 GitHub

Svn2github 服务

发射台