git-svn 和远程 git repo 同步
在我的工作场所，我们使用 SVN 进行版本控制。当我发现它时，我切换到了 git-svn，最近我决定将我的一些私有分支同步到另一个远程 git 存储库。然后，工作流程包括通过 git-svn 从 SVN 存储库进行变基和推送到 SVN 存储库，同时处理单独的私有功能分支，这些分支被推送到远程 git 存储库，以便我可以在必要时在家中处理它们。
现在，每次我从 git-svn 变基时，我的远程 git 存储库都会要求先拉取。有时，在执行拉取时，更改不会完全合并，尽管远程存储库应该包含与 svn 同步的本地存储库相同的提交。最近，我尝试删除远程分支，然后再将它们再次推送到远程存储库，但这是不对的。
是 git 没有为这种工作流程设置，还是我做错了什么？
谢谢你！
At my workplace we use SVN for version control. I switched to git-svn when I found out about it, and recently I decided to sync some of my private branches to another remote git repo. The workflow, then, consists of rebasing from and pushing to the SVN repo via git-svn, while working on separate private feature branches that are pushed to the remote git repo so I can work on them at home if necessary.
Now, every time I rebase from git-svn, my remote git repo asks to be pulled first. Sometimes, the changes don't merge cleanly when doing a pull, even though, supposedly, the remote repo should contain the same commits that my local one that's synced with svn. Lately I resorted to deleting the remote branches before pushing them again to the remote repo, but that can't be right.
Is git just not set up for this sort of workflow, or am I doing something wrong?
Thank you!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
首先，感谢马修提供的链接——它们对我找到自己的解决方案很有帮助。
这样做是可能的，但需要注意的是，它需要一些小心，并且很可能对涉及的提交者数量有限制。我的用例基本上就是 mitjak 所描述的；需要和/或希望使用两个远程存储库（一个 SVN 和另一个 Git）的单个用户。就我而言，前者在防火墙后面工作，另一个在异地（也是私有的）。目标是能够使用 Git 处理存储库的本地副本，并让两个远程存储库都满意。
我的过程：
这一切都取决于
git svn dcommit更改与原始 git 提交关联的 SHA1 的事实。牢记这一点，在本地提交后，我[可选地git svn rebase然后]git svn dcommit，生成最终的 SHA1。那时，我推送到我的远程 git 存储库。如果正如 Chacon 所说，您想要做的只是使用 git 提供更高效的克隆点，那么您就完成了。但您可能还希望能够：步骤1表示没有问题；在提交到本地“纯 git”存储库之后，
git Push到远程 git 存储库。步骤2又没问题了；回到混合 git/svn 存储库中，
git pull从远程 git 存储库中提取更改。此时，与新拉取的修订版关联的 SHA1 与远程 git 存储库中的 SHA1 同步。第三步是这个过程变得有点棘手的地方。您可以如上所述 git svn dcommit 这些更改，将它们推送到 SVN 存储库，但情况与上面描述的有点不同。在这种情况下，您现在在远程 SVN 和 git 存储库中具有相同的修订版本，但由于 dcommit，它们具有不同的 SHA1。我通过以下方式处理此问题：
在步骤 2 中的拉取过程中，我记下关联的开头 SHA1；例如，
这里感兴趣的 SHA1 是 34b6260。
git log origin应确认这是远程 git 存储库中具有关联的 git-svn-id 的最后一次提交。然后，我执行以下操作：执行远程存储库的强制更新，以排除我从“pure git”本地存储库所做的“pure git”提交 - 小心使用！在这种情况下，我知道我在本地有这些提交；他们只是有与 dcommit 不同的 SHA1。然后，我将 git push 到远程存储库，添加我刚刚删除的提交的“git-svn-id”版本，并且远程存储库保持同步。
将“纯 git”本地存储库与远程 git 存储库重新同步是最后一步，但类似的处理会产生令人满意的结果。在这种情况下，远程 git 存储库现在包含提交的“git-svn-id”版本，而本地“pure git”存储库仍然包含原始 SHA1。处理这个问题最简单的方法是从远程 git 存储库中 git fetch ，然后使用 git reset --hard origin 来强制本地 git 存储库镜像偏僻的。
First, thanks to Matthew for the links -- they were helpful to me in coming to my own solution for this problem.
It's possible to do this, but the caveats are that it requires some care and very probably has limits with respect to the number of committers involved. My use case is basically what mitjak describes; a single user that has a need and/or desire to utilize two remote repositories, one SVN and the other Git. In my case the former is at work behind a firewall and the other is offsite (also private). The goal is to be able to work on a local copy of the repository using Git and keep both remote repositories happy.
My procedure:
This all hinges on the fact that
git svn dcommitchanges the SHA1's associated with the original git commits. With that point firmly in mind, after making a commit locally, I [optionallygit svn rebasethen]git svn dcommit, producing the final SHA1. At that point, I push to my remote git repo. If as Chacon states all that you want to do is provide a more efficient cloning point using git you are done. But you may also want to be able to:Step 1 represents no problem; following a commit to your local "pure git" repository
git pushto the remote git repository.Step 2 is again no problem; back in your hybrid git/svn repository,
git pullthe changes from the remote git repository. At this point the SHA1's associated with the newly pulled revisions are in sync with those in the remote git repository.Step 3 is where the process gets a little trickier. You can
git svn dcommitthese changes as described above to push them up to the SVN repository, but then the situation is a bit different than that described above. In this case, you now have the same revisions in the remote SVN and git repositories, but they have different SHA1's because of the dcommit. I handle this in the following way:During the pull in Step 2, I note the associated beginning SHA1; e.g.,
So here the SHA1 of interest is 34b6260.
git log originshould confirm that this is the last commit in the remote git repository that has a git-svn-id associated with it. I then do the following:performing a forced update of the remote repository to exclude the "pure git" commits that I made from the "pure git" local repository -- use with care! In this case, I know that I have these commits locally; they just have different SHA1's from the dcommit. I then
git pushto the remote repository, adding the "git-svn-id"-versions of the commits that I just removed, and the remote repositories are in sync.Re-syncing the "pure git" local repository with the remote git repository is the final step, but similar care produces satisfactory results. In this case, the remote git repository now contains the "git-svn-id"-versions of the commits, while the local "pure git" repository still contains the original SHA1s. The easiest way to deal with this is to
git fetchfrom the remote git repository, thengit reset --hard originto force the local git repository to mirror the state of the remote.在 Pro Git 第 9.1 章，Scott Chacon 指出：
根据以下陈述：
如果不从远程 git 存储库中拉取，Subversion 似乎无法处理您所需的工作流程，因此 Subversion 只具有单一的线性历史。
2010 年 9 月 1 日晚上 8:37 更新
您可能需要查看 高级：将另一个远程 GIT 存储库链接到您的 GIT 和 GIT-SVN，参见大亚湾的文章同步存储库 。
In chapter 9.1 of Pro Git, Scott Chacon states:
Based on the statements:
it appears that Subversion cannot handle your desired workflow without pulling from your remote git repo so that Subversion has only a single linear history.
Update 01-Sep-10, 8:37 PM
You might want to check out the section Advanced: Linking another, remote GIT repository to your GIT and GIT-SVN in the article Synchronizing Repositories by Daya Bay.
也许这个帖子可能会让人感兴趣，尽管 git-svn 可能已经发生了变化。
我还会使用
fetch而不是pull，并在执行之前使用gitk等工具快速查看一下是否会发生冲突合并。Perhaps this thread might be of interest, although git-svn may have changed since.
I'd also use
fetchrather thanpulland have a quick look to see if there will be conflicts using a tool such asgitkbefore doing the merge.