git - Git 中的供应商分支

Question

一个 Git 项目中包含第二个项目，其内容正在独立处理。

子模块不能用于较小的，因为当用户尝试克隆或下载“父”时，甚至必须包含子项目。

不能使用子树 merge ，因为子项目正在积极开发，子树 merge 使得将这些更新 merge 回原始项目非常困难。

我被告知该解决方案在 SVN 世界中被称为“供应商分支”，并且它在 Git 中非常简单，甚至不需要寻址。
网络上充斥着半生不熟的教程。

尽管如此，我似乎无法让它发挥作用。

有人可以请(非常请？)解释我如何创建一个结构，使一个项目存在于另一个项目中，并且两者都可以从同一工作目录进行开发和更新。
理想情况下[或者更确切地说:这很重要，如果不支持的话]当客户尝试下载“父”项目时，他应该自动获得子项目的最新版本。

请不要向我解释我应该如何使用子模块或子树 merge 甚至 SVN:Externals。该线程是 the following SO thread 的产物，如果那里遗漏了什么，请在那里张贴。这个线程试图得到
对 Vendor 分支的理解，以及越长、越清晰、越傻的解释，我就会越高兴。

Answer 1

我认为子模块是“供应商分支”的必经之路。
这是您应该如何使用 submod... 嗯，开玩笑的。

只是一个想法;你要:

在同一目录下开发主项目和子项目(称为“ 系统方法 ”:您开发、标记和 merge 所有系统)

或将您的子项目视为“供应商分支”(该分支允许您访问供应商外部组件的明确定义版本 - 或“文件集” - ，并且仅使用每次发布该外部组件的新版本:称为“ 组件方法 ”，整个系统被视为自己开发的独立组件的集合)

这两种方法不兼容:

第一个策略与子树 merge 兼容:您正在处理项目和子项目。

第二个与子模块一起使用，但是子模块用于定义一个 配置 (你需要工作的标签列表):每个 git 子模块，不像 svn:externals，被固定到一个特定的提交 id，这就是允许您定义配置(如在 SCM 中:“软件配置管理”)

我喜欢第二种方法，因为大多数时候，当你有一个项目和一个子项目时，它们的生命周期是不同的(它们不是以相同的节奏开发，不是同时标记在一起，也不是同名) .

在您的问题中真正阻止这种方法(“基于组件”)的是“两者都可以从同一工作目录开发和更新”部分。
我真的敦促您重新考虑该要求，因为大多数 IDE 完全有能力处理多个“源”目录，并且子项目开发可以在其自己的专用环境中完成。

samgoody 补充说:

Imagine an eMap plugin for both Joomla and ModX. Both the plugin and the Joomla-specific code (which is part of Joomla, not of eMap) are developed while the plugin is inside Joomla. All paths are relative, the structure is rigid, and they must be distributed together - even though each project has its own lifecycle.

如果我理解正确的话，您所处的配置中，开发环境(您正在处理的文件集)与分发环境(在发布平台上复制相同的文件集)完全相同

这一切都是为了一个粒度问题:

如果两组文件不能没有另一组，那么它们应该被视为一个大项目(和子树 merge )，但这迫使它们被标记并 merge 为一个。
- 如果一个依赖于另一个(可以单独开发)，那么它们应该在自己的 Git 存储库和项目中，第一个依赖于第二个作为子模块的特定提交:如果子模块是在第一个组件的右子树中定义，所有相对路径都被考虑。

samgoody 补充说:

The original thread listed issues with submodules - primarily that GitHub's download doesn't include them (vital to me) and that they get stuck on a particular commit.

我不确定 GitHub 的下载最近是否有问题:那篇“Guides: Developing with Submodules”文章确实提到:

Best of all: people cloning your my-awesome-framework fork will have no problem pulling down your my-fantastic-plugin submodule, as you’ve registered the public clone URL for the submodule. The commands

$ gh submodule init
$ gh submodule update

Will pull the submodules into the current repository.

至于“他们卡在特定提交上”:这是子模块的全部内容，允许您使用配置(组件的标记版本列表)而不是最新的潜在不稳定文件集。

samgoody 提到:

I need to avoid both subtrees and submodules (see question), and would rather address this need without arguing too much if the approach is justified

您的要求是完全合法的，我不想判断其合理性:我之前的回答只是为了提供更大的上下文并尝试说明通常可用于通用 SCM 工具的选项。

子树 merge 应该是这里的答案，但意味着只 merge 回主项目文件的提交，而不是子项目的提交。如果您可以管理这种部分 merge ，我认为这是正确的道路。

然而，我没有看到一种不使用子树 merge 或子模块的本地 Git 方式来做你想做的事情。
我希望真正的 Git 大师会在这里发布更充分的答案。