Git 中的供应商分支

Vendor Branches in Git

提问by SamGoody

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

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

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.

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

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 versionof 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.

请不要向我解释我应该如何使用子模块或子树合并甚至 SVN:Externals。该线程是以下 SO 线程的产物，如果在那里遗漏了什么，请在那里张贴。该线程试图了解如何使用 Vendor 分支，并且越长、越清晰、越傻，我收到的解释就越开心。

回答by VonC

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

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

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 configurationmanagement")

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

I like the second approach because most of the time, when you have a project and a sub-project, their lifecycleis 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.

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

---

---

samgoody adds:

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.

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

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.

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

---

---

samgoody adds:

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 的下载不包括它们（对我来说至关重要）并且它们卡在特定的提交上。

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

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

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

最重要的是：克隆你的my-awesome-frameworkfork 的人可以轻松地拉下你的my-fantastic-plugin子模块，因为你已经为子模块注册了公共克隆 URL。命令

$ 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:

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

我需要同时避免子树和子模块（请参阅问题），并且如果该方法合理，我宁愿在不争论太多的情况下解决此需求

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.

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

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 方式来做你想做的事情。
我希望真正的 Git 大师会在这里发布更充分的答案。

回答by Paul

I finally have a few hours access to the net before I head back to the mountains. We'll see if I have anything to contribute clarity into your situation.

在我回到山上之前，我终于有几个小时可以上网了。我们会看看我是否有什么可以澄清你的情况。

My (probably oversimplified) understanding is you have (offsite) vendor(s) developing plug-in(s) for your project where your (in-house) team is developing code for your main project using an externally sourced framework. Vendor doesn't make changes to your code and probably doesn't need your bleeding edge development, but does need your stable code to develop and test their work. Your team doesn't make changes to the framework, but does sometimes contribute changes to the plug-in.

我（可能过于简单化）的理解是您有（异地）供应商为您的项目开发插件，您的（内部）团队正在使用外部来源的框架为您的主项目开发代码。供应商不会更改您的代码，也可能不需要您的前沿开发，但确实需要您的稳定代码来开发和测试他们的工作。您的团队不会对框架进行更改，但有时会为插件做出更改。

1. Like VonC (who usually thinks things thru very thoroughly) I don't think Git has a perfectfit for your requirements. And like him, I think using subtree merge pattern is the closest fit. I'm not a Git guru, but I have been successful at bending Git to a wide range of needs. Maybe Git doesn't meet your needs:

   • SVN will let you have multiple repos within one, which seems important for you. I think this would mean either using externals or the Vendor Branch pattern to come close to what you want.

   • Mercurial has an extension, Forest,for using nested repos, which seems to fit your mental model better. I chose Git over Mercurial 15 months ago, but HG was stable and for many uses I think it is comparable to Git. I don't know how stable the extension is.

2. If I were in your situation, I'd use two Git repos -- one for the Plugin and one for the MainProject. The vendor would do development in the Plugin repo and would have a release branch that they pull current versions of the plug-in into without the rest of the development environment. That branch would be pulled into the MainProject repo as a vendor branch, and then merged into your main development branch. When your team works on a change to the plug-in, they develop it in a feature branch off of your main development branch and submit it to the vendor repo as patches.This gives you a very clean workflow, relatively easy to set-up and learn, while keeping the develop history segregated.

   I'm not trying to be argumentative, but simply to say this is Git's best fit for my understanding of your situation. The easiest way to set this up would use the subtree merge, but this does not run changes thru it in both directions, which was my objection to using that pattern.

3. If your team is really actively involved in the plugin development or you really want to have the development history of both project and plug-in integrated in one Git repo, then just use one Git repo. You can extract the plug-in and its history for the records of your vendor as explained here, from time to time. This may give you less encapsulation than you intend, but Git is not designed for encapsulation -- Git's data structure is based on tracking changes within one whole project.

1. 就像 VonC（通常会非常彻底地思考问题）一样，我认为 Git 并不完全适合您的要求。和他一样，我认为使用子树合并模式是最合适的。我不是 Git 专家，但我已经成功地将 Git 用于满足广泛的需求。也许 Git 不能满足您的需求：

   • SVN 会让你在一个内拥有多个 repos，这对你来说似乎很重要。我认为这意味着要么使用 externals 要么使用 Vendor Branch 模式来接近你想要的。

   • Mercurial 有一个扩展，Forest，用于使用嵌套存储库，它似乎更适合您的心智模型。15 个月前，我选择 Git 而不是 Mercurial，但 HG 很稳定，而且在许多用途上我认为它可以与 Git 相媲美。我不知道扩展的稳定性如何。

2. 如果我处于您的情况，我会使用两个 Git 存储库——一个用于插件，一个用于 MainProject。供应商将在插件存储库中进行开发，并将有一个发布分支，他们将插件的当前版本拉入其中，而无需开发环境的其余部分。该分支将作为供应商分支被拉入 MainProject 存储库，然后合并到您的主要开发分支中。 当您的团队对插件进行更改时，他们会在您的主开发分支之外的功能分支中开发它，并将其作为补丁提交给供应商存储库。这为您提供了一个非常干净的工作流程，相对容易设置和学习，同时保持开发历史隔离。

   我不是想争论，而只是说这是 Git 最适合我对您的情况的理解。设置它的最简单方法是使用子树合并，但这不会在两个方向上通过它运行更改，这是我反对使用该模式的原因。

3. 如果您的团队真的积极参与插件开发，或者您真的希望将项目和插件的开发历史集成到一个 Git 存储库中，那么只需使用一个 Git 存储库。您可以不时地按照此处的说明提取插件及其历史记录以作为供应商的记录。这可能会给您提供比您预期的更少的封装，但 Git 不是为封装而设计的——Git 的数据结构基于跟踪整个项目中的更改。

Maybe I've misunderstood your situation and none of this applies. If so I apologize. Thanks for the details that you and VonC have worked out, which have filled in many holes that I originally had in trying to understand your question.

也许我误解了你的情况，这些都不适用。如果是这样，我道歉。感谢您和 VonC 制定的细节，这些细节填补了我最初试图理解您的问题时遇到的许多漏洞。

回答by weberjn

If you look just for the original question's title:

如果您只查找原始问题的标题：

a good template for vendor branch pattern with git is on

带有 git 的供应商分支模式的好模板已启用

https://www.roe.ch/Git_Reference

https://www.roe.ch/Git_Reference

section Vendor branch pattern

部分供应商分支模式