公共 GIT-SVN 创建的存储库的公共和私有分叉的推荐工作流程
我正在尝试设置三件事：
- 公共 SVN 存储库的公共 GIT 镜像
- 该存储库的公共分支，多个贡献者可以在其中暂存补丁
- 公共存储库的私人分支 #2
我知道如何执行 #1 但我寻找有关 #2 和 #3 的建议：如何配置、如何保持同步、要避免的事情等。
这里有更多详细信息：
我正在使用一个基于 SVN 的开源 Web 应用程序，其补丁提交机制是缓慢且低效：补丁附加到问题跟踪系统中提交的错误上，几周或几个月后，这些补丁就会进入主干。
一个单独的问题是，我需要维护项目的私有分支，其中包含只有我的公司需要的附加功能。但我想要一种简单的方法让我的分叉能够跟上来自主干的最新官方提交。
我想找到一个基于 GitHub 的解决方案来解决这两个问题。我希望最终得到三件事：
- “镜像” - SVN 的 GitHub 镜像，通过自动化流程自动与最新的 SVN 更改保持同步（如 本文）是我或其他补丁贡献者将运行的。这将使我或其他任何人都可以轻松创建项目的公共或私人分支，而无需使用 SVN。
- “contrib” - 对于我自己和我信任的一些补丁提交者，我想建立一个“镜像”的公共分叉（或分支？），我们可以在其中提交我们想要的补丁看到最终出现在SVN中。这也可能使核心提交者更容易、更高效地将补丁拉回 SVN。
- “ourfork” - 最后，我们公司希望建立一个“contrib”的私有分支，多个开发人员可以添加仅适用于我们公司实现的私有功能
一些具体问题：
- 该方法有意义吗？我们应该使用更简单的解决方案吗？
- 如何确保“contrib”与“mirror”保持同步？只要新提交不冲突，GitHub 是否有自动应用新提交的魔力？假设不是，那么确保 contrib 与其父级保持同步的良好工作流程是什么？
- 从逻辑上讲，“ourfork”将是“mirror”的孙子。使其与“镜像”和“贡献”的更改保持同步的正确工作流程是什么？我应该将“contrib”设置为我唯一的遥控器吗？或者将两者都设置为遥控器 - 如果是这样，正确的合并过程是什么？
我阅读了 @rq 的答案，内容类似我怀疑它回答了上面的大部分问题，但我是 Git 新手，我不确定他的答案是否适用于我的情况。
I'm trying to set up three things:
- a public GIT mirror of a public SVN repo
- a pubilc fork of that repo where multiple contributors can stage patches
- a private fork of the public repo from #2
I know how to do #1 but am looking for advice on #2 and #3: how to configure, how to keep in sync, things to avoid, etc.
Here's more details:
I'm working with an SVN-based open-source web application whose patch-submitting mechanism is slow and inefficient: patches are attached to bugs submitted in an issue-tracking system, and weeks or months later those patches make it into the trunk.
A seprate problem is that I need to maintain a private fork of the project with additional features that only my company will need. But I want an easy way for my fork to stay up to date with the latest official commits from the trunk.
I'd like to figure out a GitHub-based solution to both these problems. I'd like to end up with three things:
- "mirror" - GitHub mirror of SVN, automatically kept in sync with the latest SVN changes via an automated process (like in this article) that I or another patch-contributor will run. This will make it easy for me or anyone else to create a public or private fork of the project without messing around with SVN.
- "contrib" - for myself and a few patch submitters I trust, I'd like to set up a public fork (or branch?) of "mirror" where we can commit patches we'd like to see eventually show up in SVN. This may also make it easier and more efficient for the core committers to pull patches back into SVN.
- "ourfork" - finally, our company wants ot set up a private fork of "contrib" where multiple devs can add private features which only apply to our company's implementation
Some specifc questions:
- does the approach make sense? Is there a simpler solution we should be using instead?
- how to ensure that "contrib" is kept in sync with "mirror"? Is there GitHub magic to automatically apply new commits as long as they don't conflict? Assuming no, what's a good workflow to ensure contrib stays in sync with its parent?
- "ourfork" will logically be a grandchild of "mirror". What's the right workflow to keep it up to date with changes from both "mirror" and "contrib"? Should I set up "contrib" as my only remote? Or set up both as remotes-- and if so what's the right process for merging?
I read @rq's answer to a similar question and I suspect it answers most of the questions above, but I'm a Git newbie and I'm not sure if his answer applies to my case.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我建议您查看 SubGit。它是一个创建链接到 SVN 存储库并保持同步的 Git 存储库的工具。与其他解决方案相比，它具有以下优势：
并在同一毫秒内另一个进入 SVN，没什么不好
将会发生：如果他们的更改发生冲突，其中一个只会得到一个
“过时”错误）
分支（不仅仅是主分支）和标签等等。
但有一个限制：您应该有权访问 SVN 服务器，因此基于 GitHub 的解决方案可能无法工作。但是您可以查看 GitHub 替代品，例如 GitLab、Luna-tool 等（Git Server Like GitHub?< /a>）。
I would recommend that you have a look at SubGit. It’s a tool to create and keep in sync a Git repository linked to an SVN repository. It has advantages over other solutions like:
and another one into SVN within the same millisecond, nothing bad
will happen: if their changes conflict, one of them will just get an
“out-of-date” error)
branches (not only master) and tags and so on.
But there’s a restriction: you should have an access to the SVN server, so maybe your GitHub-based solution won’t work. But you can have a look at GitHub replacements like GitLab, Luna-tool and others (Git Server Like GitHub?).
我无法给出完整的答案，因为您的设置非常要求。
我也许会尝试让一位 SVN 提交者加入。然后我会让他负责在 git-svn 克隆之上重新调整功能分支，然后将更改提交回 Subversion。我最近做了一个非常简单的工作流程示例 截屏视频。
不过，这确实需要与 SVN 提交者之一建立非常紧密的反馈循环，并且为了保持历史记录的线性，您必须进行大量的变基操作，这再次使得分布式存储库保持同步变得困难。我不确定这对你有用。
I can't give a complete answer, as your setup is quite demanding.
I would perhaps try to get one of the SVN committers on board. I would then set him in charge of rebasing feature branches in on top of the git-svn clone, and then dcommitting changes back to Subversion. I recently did a very simple example of this workflow in a screencast.
This does require a very tight feedback loop with one of the SVN committers though, and in order to keep history linear, you would have to do a lot of rebasing, which again makes it hard to keep distributed repositories in sync. I'm not sure this will work out for you.