c++ - 如何有效地将 git 存储库/子模块用于具有许多依赖项的 C++ 产品？

Question

我是 Git 的新手，还在摸索中……我想我终于理解了整个分支/merge 方面。但我仍然不确定处理项目依赖项的最佳解决方案是什么。什么是最佳实践？这一定是一个常见问题，但我找不到关于这样做的好的教程或最佳实践。

假设我有一个 C++ 产品依赖于其他几个 C++ 库，最终构成了一个复杂的依赖关系图。库如:其他内部开发的C++库、公共(public)开源库、现成的闭源库

最终的 C++ 产品的源代码依赖于其依赖项的输出才能编译。这些输出包括:

• 一系列C++头文件(注意没有C++实现文件)
• 一组已编译的二进制文件(LIB 文件、DLL 文件、EXE 文件等)

我的理解是我应该将每个库放在自己的存储库中。那么听起来 Git 的子模块大多是我们要找的。 http://chrisjean.com/2009/04/20/git-submodules-adding-using-removing-and-updating/ 的文章特别是似乎是一个很好的介绍，我几乎可以理解。例如，我可以让我的主项目存储库引用特定的外部 Git 存储库作为子模块/依赖项。 C++ 代码可以在适当的子模块目录中“#include”头文件。可以想象，主产品/存储库中包含的构建脚本可以继续递归编译所有子模块。

现在问题:

您通常如何为每个存储库缓存二进制文件？我们的一些依赖项需要数小时才能编译，并且不会经常更新。使用上述方案，我可能会从服务器克隆/ checkout 一个高级项目来修复一个小错误。现在据我了解，我还被迫克隆构成这些开源依赖项的所有数千个文件——我担心这可能需要一些时间(尤其是在 Windows 上)。更糟糕的是，我不会被迫重新编译每个子模块，即使几个月来没有人更改过该子模块吗？ (似乎每台开发人员计算机上的某种本地“哈希表”方案将变更集 ID 链接到一组已编译的二进制文件会很方便......)

(我几年前工作的前一家商店使用 Mercurial - 的范围，但是所有代码 - 内部项目等都被整合到一个巨大的存储库中，你必须从服务器克隆一个新创建的分支时，在一个庞大的整体构建脚本中构建一切。当我们完成修复/新功能并与上游 merge 时，我们删除了本地存储库那个特定的分支。)

我们在 Windows 上进行开发，但最终会扩展到其他非 Microsoft 平台 - 因此可移植性很重要。

Answer 1

通常这是个坏主意，但为什么不将二进制文件以及不经常更改的子模块的编译代码检入子模块中呢？这样，fetch 将 pull 下 bin，当您使用更改的二进制文件编译新版本的依赖项时，您将看到二进制文件显示在 git status 输出中。