如何将子项目的拉取请求集成到主项目的子目录中？

Question

我正在考虑使用混合开放源代码软件和闭源软件的git存储库结构。目前的情况有点像大杂烩。多个开发人员正在从事地理分布的项目。授权存储库位于私有 GitLab 服务器上。

目录结构如下：

repo
|-- core (open source)
|-- moduleA (open source)
|-- moduleB (open source)
|-- moduleC (closed source)

实际上有更多的模块，但无论如何。

我评估了子模块以及子树，但它们不适合我们的开发过程。我找到了这个相关的问题，但那里的答案不满足我：Proper Git workflow for combined OS and Private code?

单独的回购是目前的情况，就像从svn迁移之前一样，我们也不满意。

我认为这是一个可行的解决方案，是一个大型仓库，并且有一个Jenkins工作，运行git subtree split将开源模块拆分为单独的存储库，然后将它们推送到外部世界，< EM> GitHub的。这将是开发团队最简单的工作方式，只需要在Jenkins中进行一次设置。我在Detach (move) subdirectory into separate Git repository中找到了逐步说明。

但现在来到我的实际问题。

当开源代码在 GitHub 上时，我们将收到来自外部贡献者的拉取请求。他们的补丁将发送到存储库的 root ，而位于 GitLab 中的authorative私有存储库中，以及开发人员的补丁中。工作站，更改应适用于子目录。

1. 如何将root的pull请求集成到子目录？
2. 当代码被集成，并且Jenkins在开源和私有之间拆分代码时， GitHub 会选择合并拉取请求并自动关闭吗？我想我可以将这个问题简化为：GitHub用什么来关闭拉取请求？我认为应该是安全的，前提是问题1的答案提供了可逆的东西。

编辑：我正在思考一个稍微不同的流程：

1. git subtree split将开源模块拆分为单独的存储库。
2. git subtree将开源模块重新组合到一个新的存储库中。
3. 将新存储库推送到GitHub。

这具有以下优点：

• 内部GitLab仓库和外部GitHub仓库的目录结构完全相同（当然除了封闭源代码外）
• 只需要向外界发布一个回购。
• 我可以将提取请求与git cherry-pick合并。

缺点：

• 这有点令人费解。
• 拉取请求仍然不会自动关闭。

Answer 1

我将接受Proper Git workflow for combined OS and Private code?的接受答案：2个单独的回购，一个用于公共代码，一个用于私人代码。