Как эффективно использовать репозитории / подмодули git для продукта C ++, который имеет много зависимостей?

Я новичок в 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). Хуже того, разве меня не заставят перекомпилировать каждый подмодуль, даже если никто не менял этот подмодуль в течение нескольких месяцев? (Похоже, что какая-то схема локальной "хеш-таблицы" на каждом компьютере разработчика, которая связывает идентификатор набора изменений с набором скомпилированных двоичных файлов, была бы удобна ...)

(Предыдущий магазин, в котором я работал несколько лет назад, использовал Mercurial - объем, но весь код - внутренние проекты и т. Д. Были объединены в один большой гигантский репозиторий, и вам пришлось собрать все в большом толстом монолитном скрипте сборки, когда клонирование вновь созданной ветки с сервера.Когда мы закончили с функцией fix / new и снова объединились с восходящей веткой, мы удалили локальный репозиторий для этой конкретной ветки.)

Мы занимаемся разработкой для Windows, но со временем перейдем к другим платформам, отличным от Microsoft, поэтому переносимость важна.