Git 中的供应商分支 [英] Vendor Branches in Git

问题描述

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

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

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

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

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

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

请不要向我解释我应该如何使用子模块或子树合并甚至 SVN:Externals.这个线程是以下SO线程的产物，如果有的话在那里错过了，请务必在那里张贴.这个线程试图得到对 Vendor 分支的理解，以及越长、越清晰、越傻的解释，我就会越开心.

解决方案

我认为子模块是供应商分支"的最佳选择.
这是您应该如何使用 submod... 嗯，开玩笑的.

只是一个想法；你想要:

• 在同一目录中开发主项目和子项目(称为系统方法":您开发、标记和合并所有系统)
• 或将您的子项目视为供应商分支"(该分支允许您访问供应商外部组件的明确定义版本 - 或文件集" - ，并且仅更新随着该外部组件的每个版本的新版本:即所谓的组件方法"，所有系统都被视为自己开发的独立组件的集合)

这两种方法不兼容:

• 第一个策略与子树合并兼容:您正在处理项目和子项目.
• 第二个与子模块一起使用，但子模块用于定义配置(您需要工作的标签列表):每个 git 子模块，与 svn:externals 不同，被固定到特定的提交 ID，这允许您定义配置(如 SCM:软件配置管理")

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

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

<小时>

samgoody 补充说:

<块引用>

想象一个适用于 Joomla 和 ModX 的 eMap 插件.插件和 Joomla 特定代码(它是 Joomla 的一部分，而不是 eMap 的一部分)都是在插件在 Joomla 内部时开发的.所有路径都是相对的，结构是刚性的，它们必须分布在一起——即使每个项目都有自己的生命周期.

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

>

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

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

<小时>

samgoody 补充说:

<块引用>

原始线程列出了子模块的问题 - 主要是 GitHub 的下载不包括它们(对我来说至关重要)并且它们卡在特定的提交上.

我不确定 GitHub 的下载最近是否有问题:指南:使用子模块进行开发" 文章确实提到:

<块引用>

最重要的是:克隆您的 my-awesome-framework fork 的人将没有问题拉下您的 my-fantastic-plugin 子模块，因为您已经注册了子模块的公共克隆 URL.命令

$ gh 子模块初始化$ gh 子模块更新

<块引用>

将子模块拉入当前存储库.

至于他们陷入特定提交":这是子模块的全部意义，允许您使用配置(标记版本的组件列表)而不是最新的可能不稳定的文件集.

samgoody 提及:

<块引用>

我需要同时避免子树和子模块(见问题)，如果方法合理，我宁愿解决这个需求而不会争论太多

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

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

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

A Git project has within it a second project whose content is being worked on independently.

Submodules cannot be used for the smaller, as even the subproject must be included when users attempt to clone or download the 'parent'.

Subtree-merging cannot be used, as the subproject is being actively developed, and subtree merging makes it very difficult to merge those updates back into the original project.

I have been informed that the solution is known in the SVN world as "Vendor Branches", and that it is so simply done in Git so as to not even need addressing. Half-baked tutorials abound on the 'net.

Nonetheless, I cannot seem to get it to work.

Can someone please (pretty please?) explain how I can create a structure whereby one project exists within another, and both can be developed and updated from the same working directory. Ideally [or rather: it is quite important, if unsupported] that when a client attempts to download the 'parent' project, that he should be given the latest version of the subproject automatically.

Please do NOT explain to me how I should use submodules or subtree-merges or even SVN:Externals. This thread is the outgrowth of the following SO thread, and if something was missed there, please DO post it there. This thread is trying to get an understanding of how to Vendor branches, and the longer, clearer, and more dummied an explanation I receive the happier I will be.

解决方案

I think submodules are the way to go when it comes to "vendor branch".
Here is how you should use submod... hmmm, just kidding.

Just a thought; you want:

• to develop both main project and sub-project within the same directory (which is called a "system approach": you develop, tag and merge the all system)
• or to view your sub-project as a "vendor branch" (which is a branch which allows you to access a well-defined version of a vendor external component - or "set of files" - , and which is only updated with the new version every release of that external component: that is called a "component-approach", the all system is viewed as a collection of separate components developed on their own)

The two approaches are not compatible:

• The first strategy is compatible with a subtree-merge: you are working both on project and sub-project.
• The second one is used with submodules, but submodules is used to define a configuration (list of tag you need to work): each git submodules, unlike svn:externals, are pinned to a particular commit id, and that is what allows you to define a configuration (as in SCM: "software configuration management")

I like the second approach because most of the time, when you have a project and a sub-project, their lifecycle is different (they are not developed at the same rhythm, not tagged together at the same time, nor with the same name).

What really prevents that approach ("component-based") in your question is the "both can be developed and updated from the same working directory" part.
I would really urge you to reconsider that requirement, as most IDE are perfectly capable to deals with multiple "sources" directories, and the sub-project development can be done in its own dedicated environment.

---

samgoody adds:

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.

If I understand correctly, you are in a configuration where the development environment (the set of files you are working on) is quite the same than the distribution environment (the same set of file is copied on the release platform)

It all comes done to a granularity issue:

• if both sets of files cannot exist one without the other, then they should be viewed as one big project (and subtree-merged), but that force them to be tagged and merged as one. -if one depends on the other (which can be developed alone), then they should be in their own Git repository and project, the first one depending on a specific commit of the second as a sub-module: if the sub-module is defined in the right subtree of the first component, all relative paths are respected.

---

samgoody adds:

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.

I am not sure GitHub's download is an issue recently: that "Guides: Developing with Submodules" article does mention:

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.

As for the "they get stuck on a particular commit": that is the all point of a submodule, allowing you to work with a configuration (list of tagged version of components) instead of a latest potentially unstable set of files.

samgoody mentions:

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

Your requirement is a perfectly legitimate one, and I do not want to judge its justification: my previous answers are only here to provide a larger context and try to illustrate the options usually available with a generic SCM tool.

Subtree merge should be the answer here, but would imply to merge back only commits made for files for the main project, and not commits made for the sub-projects. If you can manage that kind of partial merge, I would reckon it is the right path to follow.

I do not see however a native Git way to do what you want that does not use subtree-merge or submodule.
I hope a true Git guru will post here a more adequate answer.

这篇关于Git 中的供应商分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！