发现git vendor扩展。
我的中级博客的交叉发布： https : //medium.com/opsops/git-vendor-295db4bcec3a
我想介绍处理git存储库供应的正确方法。
什么是“供应商”？
供应是一种将他人的工作整合到自己的工作中的方法。 与第三方库“链接”相反。 应用程序没有将该库作为依赖项，而是将该库用作自己的源代码的一部分，并将该代码“内部”保留在自身内部。
通常，销售是通过语言工具完成的：捆绑器，货物，点子等。 但是有时候您需要提供一些现有工具集未涵盖的东西，或者某种多语言的东西，因此不可能找到用于此目的的“核心”语言工具。
针对这种情况的解决方案是在git级别上进行供应。 您有自己的git存储库（我称之为“ 目标存储库”），并且想要将其他存储库（我称为“ 源存储库”）作为目录合并到您的（目标存储库）中。
您可以从精心设计的供应商系统中获得的期望（无论是否是Git）：
- 能见度 您想知道某些代码是由供应商提供的，这意味着它们不是由提交者编写的。
- 出处 您想知道它的来源。 两年前有人整合到您的仓库中的仓库是什么？ 那是什么版本/提交？
- 可更新性 您希望能够在原始存储库中修复了一些错误（或具有期待已久的新功能）时更新该代码。 作为可更新性的特殊情况，您希望能够删除供应商代码（并且仅删除它）。
- 重复性 供应商不应该是艺术，它应该是严格的防错过程。 无论谁完成了操作，供应商foo进入bar都应产生相同的结果。
- 可运输性。 克隆您的存储库的人应该能够以与您完全相同的方式继续处理供应商。 这意味着所有与供应商有关的信息都应保留在git中，并应在推/拉过程中进行传递。
- 治理。 所有供应商的更改应保持“原样”，直到有人对其进行更新。 而且，您不希望有意外的（破坏性的）更新，而且即使源仓库不再可用，您也绝对希望保持供应商提供的东西可用。
- 可修补性。 您希望能够调整供应商代码，并且仍然能够将其更新为较新的版本。 优选地，没有冲突，但至少在发生冲突的地方具有清晰的可见性。
并且，考虑到Git的git特性，您希望该系统对分支友好。 如果分支A的供应商代码版本为a1，分支B的版本为b1，则您希望每次在A和B之间切换时都在它们之间进行切换。此外，您希望能够将版本a1更改为a2，将版本b1更改为b2不用担心另一个分支中的版本。
...并且您希望能够提供多个外部存储库，因此，不应将每个回购作为一次性事件。
如您所见，这是一长串要求。 在获得最佳解决方案（git供应商）之前，我分析了现有（其他）解决方案。
复制粘贴
复制粘贴是提供任何东西的恶意方式，我对此无话可说。 您失去了出处，可见性和可更新性。 但是，您不会失去可运输性，因为首先它与旧存储库之间没有链接。 不要那样做供应商。
git Git
这是一个愚蠢但可行的技巧。 在您的存储库中创建一个文件夹vendored_foobar，进入vendored_foobar并克隆该foobar。 返回顶层并确认您所做的所有更改。
优点：操作简单，提供本地来源，治理和出色的可扩展性。
缺点：它很脆弱，不能在推送中保留（嵌套的.git文件夹未包含在您的存储库中，因此对于外部观察者而言，供应商提供的代码与您自己的代码无法区分）。 因此，从长远来看，您将失去可运输性和出处。
子模块
这个想法是，您在另一个git中管理了一些git文件夹。 这是git提供的最古老的“东西”。 不幸的是，它对分支不友好，并且缺乏对供应商代码的管理。 如果远程存储库不存在，则无法使用子模块。
并且不要忘记克隆此存储库有多困难。
git子树
Git可以使用“子树”方式将外部git作为文件夹合并到本地git存储库中。 除了可更新性，可重复性，出处和可见性外，它几乎是完美的。 除非手动挖掘git历史记录，否则无法看到git repo的哪一部分是卖出的，哪一部分不是卖出的。 而且您不知道这些更改来自何处。 如果提交者尚未编写此信息，则信息将丢失。 而且，如果他/他拥有该信息，则该信息不可重复，因为在填写该信息期间可能会发生细微的变化。
因此，请输入获奖者git供应商。
Git供应商
Git供应商是Brett Langdon大约三年前编写的git的惊人扩展。 在bash中大约只有200行，但是写得如此好，以至于我对此没有任何抱怨（它具有一个好的程序应具备的一切：手册页，帮助，bash完成，合理的错误处理和故障安全防护）。
它使用git子树，并对其进行扩展，以覆盖git子树中供应商的松散环节。
检查每个要点：
- 可见性。 只需调用
git vendor list然后查看所有git vendor list东西。 - 出处。 它显示了远程存储库，并允许查看提供了什么提交。
- 升级能力。
git vendor update ，它支持分支，标签和提交，以此来精确指出要采取的措施。 当然，您可以执行git vendor remove 。 - 重复性。 无需人工操作，因此每个人在初始供应商或后续更新时都将获得相同的结果。
- 运输性。 所有更改都作为特殊标签存储在git历史记录中，因此它们完全推/拉友好。 它们非常适合分支和任意历史记录签出。
- govenrance。 所有供应商代码都存储在您的存储库中。
- 修补性。 是的（您将看到与更改明显的合并冲突），但这是git供应商最薄弱的一面。 我更希望有“补丁队列”（例如debian软件包的debian / pathes中），但是尽管如此，对它的支持却很少。
它对东西的供应有特定的政策：如果要克隆https://github.com/serverscom/dibctl它将进入vendor/github.com/serverscom/dibctl/ 。 您可以更改“ vendor/ ”部分，但其余部分是硬性策略。 但是，符号链接可以使此操作更容易。
那里有一些小错误：您不能在空的仓库中使用它，不能将本地gits用作源，只有在git repo中才能看到帮助。 在使用真正的仓库进行正常工作期间，它们都不会引起问题。
结论
git-vendor是将一个git仓库供应到另一个仓库的理想工具。 它提供了最佳销售实践所需的所有功能：保留来源，提供可见性和可更新性。