如何有效地为一个有很多依赖的c++产品使用git存储库/子模块

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

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

最终的c++产品的源代码依赖于它的依赖项的输出来编译。这些输出包括:

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

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

现在的问题是:

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

(几年前我工作过的一个商店使用Mercurial，但是所有的代码-内部项目等都被卷进一个巨大的存储库中，当你从服务器克隆新创建的分支时，你必须在一个庞大的单片构建脚本中构建所有代码。当我们完成了修复/新特性并与上游合并时，我们删除了该特定分支的本地存储库。

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