供应商分支机构在Git [英] Vendor Branches in Git

问题描述

子模块不能用于较小的子模块，因为即使是子项目也必须包含在其中当用户试图克隆或下载'父'。

子树合并不能使用，因为子项目正在积极开发，并且子树合并使其很难将这些更新合并到原始项目中。

我被告知该解决方案在SVN世界中被称为Vendor Branches，并且它非常简单在Git中，甚至不需要处理。
在网路上有一半的教程。

尽管如此，我似乎无法完成它的工作。

有人可以请（请相信吗？）解释我可以如何创建一个项目存在于另一个项目中的结构，并且可以从同一个工作目录开发和更新这两个项目。
当客户端尝试下载父项目时，理想情况下[或者更确切地说，这是非常重要的，如果不支持的话]，他应该自动给予子项目的最新版本。

请不要向我解释我应该如何使用子模块或子树合并，甚至是SVN：Externals。此主题是以下SO主题的产物，如果有在那里错过了，请把它张贴在那里。这个线程试图获得
了解如何供应商分支，以及更长，更清晰，更愚蠢的解释我收到我会更快乐。

我认为submodules是供应商分支的方法。

这是你应该如何使用submod ...嗯，只是开个玩笑。

只是一个想法;你需要：在同一个目录下开发主项目和子项目（称为系统方法 / strong>：您开发，标记和合并所有系统）

或将您的子项目视为供应商分支（这是允许您访问定义良好的供应商外部组件或文件集的版本，并且每个版本的外部组件都只使用新版本进行更新：称为组件方法 ，所有系统都被看作是自己开发的独立组件集合）

这两种方法不兼容：

>

• 第一种策略与子树合并兼容：您既在项目又在子项目中工作。 第二个用于子模块，但子模块用于定义配置（您需要工作的标签列表）：每个git子模块，与svn不同：externals，被固定到一个特定的提交ID，这就是允许你定义一个配置（如在S C M：software configuration 我喜欢第二种方法，因为大多数情况下，当你有一个项目和一个子项目时，他们的生命周期是不同的（他们不是以相同的节奏开发，没有同时标记，也没有相同的名称）。
  
  
  

  在你的问题中真正阻止这种方法（基于组件）的是两者都可以从同一个工作目录开发和更新的部分。
  
  我真的希望你重新考虑这个需求，因为大多数IDE完全能够处理多个源目录，并且可以在其中完成子项目开发s
  
  

  samgoody增加：
  
  

  
  

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

  
  

  如果我理解正确，您处于开发环境（您正在处理的文件集）与分发环境完全相同的配置中（在发布平台上复制相同的一组文件）

  
  
  

  这一切都是针对粒度问题完成的：

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

  ---

  
  
  

  samgoody补充道：
  
  

  
  

  原始线程列出了子模块的问题 - 主要是GitHub的下载不包含它们），并且它们被困在一个特定的提交中。

  
  

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

  
  

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

  
  
  

    $ gh子模块init 
   $ gh子模块更新
    

  
  
  

  
  

  会将子模块拉入当前的存储库。

  
  

  至于它们停留在某个特定的提交上：这就是子模块的所有点，允许您使用配置 （标记版本的组件列表），而不是最新的潜在不稳定的文件集。

  
  
  

  samgoody提及：
  
  

  
  

  我需要避免使用子树和子模块（请参见问题），并且如果方法合理，而不是争论太多，则会更好地解决此需求。

  您的要求是完全合法的，我不想判断它的理由：我以前的答案只是为了提供更大的上下文，并尝试说明通用SCM工具。

  
  
  

  S ubtree合并应该是这里的答案，但意味着只合并为主项目提交的文件提交，而不合并为子项目提交的提交。如果你可以管理这种部分合并，我会认为这是一条正确的道路。

  
  
  

  我没有看到一种原生的Git方式来做你想做的事不使用子树合并或子模块。
  
  我希望真正的Git guru会在这里发布一个更合适的答案。
  

  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屋！