git Fork 并将 Google Code Subversion 存储库同步到 GitHub
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/796991/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Fork and synchronize Google Code Subversion repository into GitHub
提问by optixx
How can I fork and keep in sync with an Google Code Subversion repository that I don't have write access to, into a GitHub repository?
如何将我没有写入权限的 Google Code Subversion 存储库分叉并与 GitHub 存储库保持同步？
I want to be able to develop my own features in my Git repository, but I also want to synchronise against the Google Code Subversion repository. To fetch fixes from Google Code project side.
我希望能够在我的 Git 存储库中开发自己的功能，但我也想与 Google Code Subversion 存储库同步。从 Google Code 项目端获取修复。
I know about git-svn and used it before to up- and downstream to an Subversion repository I had full control over. But I don't know how keep in sync with a Google Code Subversion repository.
我知道 git-svn 并在之前使用它到我完全控制的 Subversion 存储库的上游和下游。但我不知道如何与 Google Code Subversion 存储库保持同步。
回答by richq
The remote branch from git-svn is pretty much the same as a regular Git remote. So in your local repository you can have your git-svn clone and push changes out to GitHub. Git doesn't care. If you create your git-svn clone and push the exact same changes out to GitHub, you'll have an unofficial mirror of the Google Code repository. The rest is vanilla Git.
来自 git-svn 的远程分支与常规 Git 远程分支几乎相同。因此，在您的本地存储库中，您可以克隆 git-svn 并将更改推送到 GitHub。Git不在乎。如果您创建 git-svn 克隆并将完全相同的更改推送到 GitHub，您将拥有 Google 代码存储库的非官方镜像。剩下的就是普通的 Git。
git svn clone http://example.googlecode.com/svn -s
git remote add origin [email protected]:example/example.git
git push origin master
Now that you have this, occasionally you will have to synchronise the Subversion repository with Git. It'll look something like:
既然您有了这个，偶尔您将不得不将 Subversion 存储库与 Git 同步。它看起来像：
git svn rebase
git push
In gitk or whatever, this would look something like this:
在 gitk 或其他任何东西中，这看起来像这样：
o [master][remotes/trunk][remotes/origin/master]
|
o
|
o
And when you run git svn rebase, you would have this:
当你运行时git svn rebase，你会得到这个：
o [master][remotes/trunk]
|
o
|
o [remotes/origin/master]
|
o
|
o
So now running git pushwould push those commits out to GitHub, the [remotes/origin/master]branch there. And you'd be back to the scenario in the first ASCII art diagram.
所以现在运行git push会将这些提交推送到 GitHub，那里的[remotes/origin/master]分支。你会回到第一个 ASCII 艺术图中的场景。
The problem now is, how do you work your changes into the mix? The idea is, you don't ever commit onto the same branch that you are git-svn-rebase-ing and git-pushing. You need a separate branch for your changes. Otherwise, you would end up rebasing your changes on top of the Subversion ones, which could upset anyone who clones your Git repository. Follow me? OK, so you create a branch, let's call it "features". And you make a commit and push it out to GitHub to the features branch. Your gitk would look something like this:
现在的问题是，您如何将您的更改融入到组合中？这个想法是，您永远不会提交到与 git-svn-rebase-ing 和 git-pushing 相同的分支。您需要一个单独的分支来进行更改。否则，您最终会在 Subversion 的基础上重新调整您的更改，这可能会让克隆您的 Git 存储库的任何人感到不安。跟着我？好的，所以你创建了一个分支，我们称之为“功能”。然后您进行提交并将其推送到 GitHub 到 features 分支。你的 gitk 看起来像这样：
o [features][remotes/origin/features]
|
o
|
o [master][remotes/trunk][remotes/origin/master]
|
o
Here you've got your features branch a couple of commits ahead of the Google Code branch, right? So what happens when you want to incorporate new stuff from Google Code? You'd run git svn rebasefirst and get this:
在这里，您的 features 分支比 Google Code 分支早了几次提交，对吗？那么当您想从 Google 代码中合并新内容时会发生什么？你会git svn rebase先运行并得到这个：
o [features][remotes/origin/features]
[master][remotes/trunk] o |
| o
o /
|/
o[remotes/origin/master]
|
o
If you git pushmaster out, you can imagine the [remotes/origin/master]being at the same point as master. But your feature branch doesn't have the changes. Your choices now are to merge master into features, or rebase features. A merge would look like this
如果你git push掌握了，你可以想象[remotes/origin/master]与 master 处于同一点。但是您的功能分支没有更改。您现在的选择是将 master 合并到 features 中，或者 rebase features。合并看起来像这样
git checkout features
git merge master
o [features]
/|
/ o [remotes/origin/features]
[master] o |
| o
o /
|/
o
|
o
Then you push features out to GitHub. I've left off the remotes for master to save space, they'd be at the same point as [master].
然后你将功能推送到 GitHub。为了节省空间，我已经离开了 master 的遥控器，它们将与[master]处于同一点。
The rebase approach is slightly more evil - you'd have to push with --force as your push would not be a fast-forward merge (you'd pull the features branch from under someone who had cloned it). It's not really considered OK to do this, but nobody can stop you if you are determined. It does make some things easier too, such as when patches get accepted upstream in slightly reworked form. It'd save having to mess about with conflicts, you can just rebase --skip the upstreamed patches. Anyway, a rebase would be like this:
rebase 方法稍微有点邪恶 - 您必须使用 --force 进行推送，因为您的推送不会是快进合并（您将从克隆它的人那里拉出功能分支）。这样做并不是真的被认为可以，但是如果你下定决心，没有人可以阻止你。它也确实让一些事情变得更容易，例如当补丁以稍微重新设计的形式被上游接受时。这样可以省去处理冲突的麻烦，您只需重新设置 --skip 上游补丁即可。无论如何，rebase 应该是这样的：
git rebase master features
o [features]
|
o
| o [remotes/origin/features]
[master] o |
| o
o /
|/
o
|
o
And then you would have to git push --forcethat. You can see why you need to force it, the history has a big old schism from the [remotes/origin/features]to the new current post-rebase [features].
然后你就必须git push --force这样做。你可以看到为什么你需要强制它，从[remotes/origin/features]到新的当前 post-rebase [features]历史有很大的旧分裂。
This all works, but it is a lot of effort. If you are going to be a regular contributor, the best bet would be to work like this for a while, send some patches upstream and see if you can get commit access to Subversion. Failing that, perhaps don't push your changes out to GitHub. Keep them local and try and get them accepted upstream anyway.
这一切都有效，但需要付出很多努力。如果你打算成为一名常规贡献者，最好的办法是像这样工作一段时间，向上游发送一些补丁，看看你是否可以获得 Subversion 的提交访问权限。否则，也许不要将您的更改推送到 GitHub。将它们保留在本地并尝试让它们在上游被接受。
回答by Mechanical snail
svn2github service
svn2github 服务
The website http://svn2github.com/provides a service to fork any publicly-accessible SVN repository onto Github (at https://github.com/svn2github/projectname). I tried it; upon pressing "Make a mirror" it apparently did nothing for a few seconds and displayed the message "error", but it actually worked. The new repository was in fact created, containing the code from the SVN repo.
网站http://svn2github.com/提供了将任何可公开访问的 SVN 存储库分叉到 Github（位于https://github.com/svn2github/projectname）的服务。我尝试过这个; 按“制作镜子”后，它显然在几秒钟内什么也没做，并显示“错误”消息，但它确实有效。实际上创建了新存储库，其中包含来自 SVN 存储库的代码。
You would then fork the repository it creates, and work on your own fork. You would then submit your changes to the upstream project using their bugtracker.
然后，您将分叉它创建的存储库，并在您自己的分叉上工作。然后，您将使用他们的错误跟踪器将更改提交到上游项目。
Looking at existing repositories under the service's Github user (e.g. "svn2github pushed to master at svn2github/haxe 5 hours ago"), it does seem to regularly pull in changes from the SVN repository. There's no information on who runs the service on the website, so I wouldn't bet on it continuing to run indefinitely, but it works for now (and if it ever goes down, you can still manually update your fork).
查看服务的 Github 用户下的现有存储库（例如“svn2github 5 小时前在 svn2github/haxe 上推送到 master”），它似乎确实定期从 SVN 存储库中提取更改。没有关于谁在网站上运行该服务的信息，所以我不会打赌它会无限期地继续运行，但它现在可以使用（如果它出现故障，您仍然可以手动更新您的 fork）。
Launchpad
发射台
If you're not set on using Git and Github, another alternative is to use Launchpad.net. Launchpad can automatically import SVN (also CVS) repositories into a personal bzr branch. To do this, create a Launchpad project, then go to the new import page, select Subversion and enter the URL (e.g. http://projectname.googlecode.com/svn/trunk/). Depending on the project size, the initial import can take up to a few hours. Subsequent imports will run periodically.
如果您不打算使用 Git 和 Github，另一种选择是使用 Launchpad.net。Launchpad 可以自动将 SVN（也包括 CVS）存储库导入个人 bzr 分支。为此，创建一个 Launchpad 项目，然后转到新的导入页面，选择 Subversion 并输入 URL（例如http://projectname.googlecode.com/svn/trunk/）。根据项目大小，初始导入可能需要几个小时。后续导入将定期运行。
For more documentation, see VCS Imports on Launchpad Help.
有关更多文档，请参阅Launchpad 帮助上的 VCS 导入。
回答by akaihola
A walk-through for synchronizing from Google Code to GitHub is available at fnokd.com. The author uses an always-on remote server and a cron job to automate the synchronization and keeps the SVN trunk in a GitHub branch called "vendor".
fnokd.com上提供了从 Google 代码同步到 GitHub 的演练。作者使用一个永远在线的远程服务器和一个 cron 作业来自动同步，并将 SVN 主干保存在一个名为“vendor”的 GitHub 分支中。
回答by nick black
GitHub now supports directly importing subversion projects (see http://help.github.com/import-from-subversion/). Just create a new repo and then click "Import from Subversion" at the "Next Steps" screen. It doesn't support further syncing, though :/.
GitHub 现在支持直接导入 subversion 项目（参见http://help.github.com/import-from-subversion/）。只需创建一个新的存储库，然后在“后续步骤”屏幕上单击“从 Subversion 导入”。但它不支持进一步同步：/。
回答by Marcin Gil
Hmm.. In my company I was doing nearly the same. Just having both .svn and .git repo in the same directory (you checkout svn repo and create git repo in this working copy).
嗯.. 在我的公司里，我做的几乎是一样的。只需将 .svn 和 .git repo 放在同一目录中（您签出 svn repo 并在此工作副本中创建 git repo）。
Then using svn up and git push did the thing. Of course if you diverge a lot you'll have to merge things by hand.
然后使用 svn up 和 git push 做了这件事。当然，如果你分歧很大，你将不得不手动合并。
回答by Bombe
I'm not quite sure what it is that you want but, of course can you pull from a subversion repository and push to a Git repository from the same working copy. And you can also git svn dcommitback to the subversion repository. You can't make the GitHub repository sync against the subversion repository, though. Also, when you have commits in your working copy that are not yet in the subversion repository you will need to rebase them if the subversion repository was updated, forcing you to git push --forcethe “new” commits to GitHub.
我不太确定您想要什么，但是，您当然可以从 subversion 存储库中提取并从同一个工作副本推送到 Git 存储库。您还可以git svn dcommit返回到 subversion 存储库。但是，您不能使 GitHub 存储库与 subversion 存储库同步。此外，当您的工作副本中有尚未在 subversion 存储库中的提交时，如果更新了 subversion 存储库，您将需要重新设置它们，迫使您git push --force向 GitHub 提交“新”提交。
回答by Ellen Spertus
I found these instructions on Yu-Jie Lin's blog:
我在Yu-Jie Lin的博客上找到了这些说明：
First clone the Subversion repository and push to the Git:
首先克隆 Subversion 存储库并推送到 Git：
git svn clone https://foo.googlecode.com/svn/ git-foo
cd git-foo
git remote add git-foo [email protected]:username/foo.git
git push git-foo master
After committing in the Subversion repository, run
在 Subversion 存储库中提交后，运行
cd /path/to/git-foo
git svn fetch
git svn rebase
git push git-foo master
