我有一个为多个操作系统（现在是Linux和Windows，可能是OS X）和处理器而构建的项目。对于这个项目，我有一些库依赖项，它们是男性外部的，但我有几个内部的，以源代码形式，我为我的上下文中可能的每个OS处理器组合编译（交叉编译）。
大多数外部库不会经常更改，只是在本地错误修复或某些功能\ bugfix在较新版本中实现的情况下，我认为它可能会使项目受益。内部库经常更改（1个月周期）并由我公司的另一个团队以二进制形式提供，虽然我也可以访问源代码，如果我需要修复错误，我可以这样做并生成新的二进制文件我的使用直到下一个发布周期。我现在的设置如下（仅限文件系统）：
-- dependencies
|
-- library_A_v1.0
|
--include
|
--lib
|
-- library_A_v1.2
|
--include
|
--lib
|
-- library_B
|
--include
|
--lib
| ...
这些库保存在服务器上，每次进行更新时，我都必须在服务器上复制任何新的二进制文件和头文件。客户端上的同步使用文件同步实用程序完成。当然，库的任何更新都需要向其他开发人员公布，每个人都必须记住同步他们的“依赖”文件夹。
毋庸置疑，我不太喜欢这个计划。所以我想把我的库放在版本控制（GIT）下。构建它们，将它们打包成tgz \ zip并将它们推送到repo上。每个库都有自己的git存储库，这样我就可以轻松地标记\ branch已经使用过的版本和测试驱动器的新版本。每个库的“数据流”，我可以轻松获取，组合，更新。我想拥有以下内容：
摆脱这种保存库的正常文件系统方式;现在，为每个操作系统和每个版本保存和管理完整的单独文件夹，有时它们不同步导致混乱
对它的更多控制，能够清楚地了解我们用于哪个版本的项目的库的版本;很像我们可以从git（VCS）获得的源代码
能够标记\ branch我正在使用的依赖项的版本（对于它们中的每一个）;我有我的v2.0.0标签/分支用于library_A我通常把它用于我的项目，但我想测试驱动2.1.0版本，所以我只是构建它，在不同分支上的服务器上推送它并调用我的构建脚本，该特定依赖项指向新分支
有更简单的构建脚本 - 只需从服务器中提取源，拉出依赖项并构建;这也允许同一个库的不同版本用于不同的处理器-OSO组合（我们通常需要更多）
我试图找到基于git的直接解决方案的一些替代方案，但没有取得多大成功 - 比如git-annex这对于我正在尝试做的事情似乎过于复杂。
我现在面临的事实是，似乎非常强烈反对将二进制文件放在git或任何VCS下（虽然从技术上讲我也会有头文件;我也可以推送我描述的文件夹结构直接给git没有tgz \ zip，但我仍然会有库二进制文件）而且我的一些同事，在共同的强烈意见的推动下，反对这种方案。我完全理解 git跟踪内容而不是文件，但在某种程度上我会跟踪内容，我相信它肯定会比我们现在的方案有所改进。
对于这种情况，什么是更好的解决方案？你知道基于git（VCS）的方案的任何替代品吗？将我的计划置于git :)下会是一件多么可怕的事吗？请分享您的意见，特别是您在处理这些情况时的经验。
由于