Управление зависимостями библиотек с помощью git

У меня есть проект, созданный для нескольких ОС (на данный момент Linux и Windows, возможно, OS X) и процессоров. Для этого проекта у меня есть несколько библиотечных зависимостей, которые в основном являются внешними, но у меня есть несколько внутренних, в исходной форме, которые я компилирую (кросс-компиляцию) для каждой комбинации ОС-процессор, возможной в моем контексте.

Большинство внешних библиотек меняются не очень часто, просто, возможно, в случае локального исправления ошибок или какой-либо функции \ bugfix, реализованной в более новой версии, я думаю, это может принести пользу проекту. Внутренние библиотеки меняются довольно часто (циклы 1 месяц) и предоставляются другой командой в моей компании в двоичной форме, хотя у меня также есть доступ к исходному коду, и если мне нужно исправить ошибку, я могу это сделать и сгенерировать новые двоичные файлы для моего использования до следующего цикла выпуска. У меня сейчас следующая установка (только файловая система):

-- dependencies
  |
   -- library_A_v1.0
     |
      --include
     |
      --lib
  |
   -- library_A_v1.2
     |
      --include
     |
      --lib
  |       
   -- library_B
     |
      --include
     |
      --lib
  | ...

Библиотеки хранятся на сервере, и каждый раз, когда я делаю обновление, мне приходится копировать все новые двоичные файлы и файлы заголовков на сервер. Синхронизация на стороне клиента выполняется с помощью утилиты синхронизации файлов. Конечно, обо всех обновлениях библиотек нужно сообщать другим разработчикам, и каждый должен помнить о синхронизации своей папки «dependencies».

Излишне говорить, что мне не очень нравится эта схема. Поэтому я подумывал поставить свои библиотеки под контроль версий (GIT). Соберите их, упакуйте в tgz \ zip и поместите в репо. Каждая библиотека будет иметь свой собственный репозиторий git, чтобы я мог легко пометить \ branch уже использованные версии и протестировать новые версии. «Поток» данных для каждой библиотеки, который я мог легко получать, комбинировать, обновлять. Я хотел бы иметь следующее:

• избавиться от этого обычного способа файловой системы хранить библиотеки; прямо сейчас целые отдельные папки хранятся и управляются для каждой ОС и каждой версии, и иногда они выходят из синхронизации, что приводит к беспорядку

• больший контроль над ним, чтобы иметь возможность иметь четкую историю того, какие версии библиотек мы использовали для какой версии нашего проекта; очень похоже на то, что мы можем получить из git (VCS) с нашим исходным кодом

• , у нас есть возможность помечать \ переходить к версиям зависимостей, которые я использую (для каждой из них); У меня есть тег / ветка v2.0.0 для library_A, из которого я обычно беру его для своего проекта, но я хотел бы протестировать версию 2.1.0, поэтому я просто создаю ее, нажимаю на сервер в другой ветке и вызываю мой сценарий сборки с этой конкретной зависимостью, указывающей на новую ветку

• , имеет более простые сценарии сборки - просто вытащите исходные коды с сервера, извлеките зависимости и выполните сборку; это позволило бы также использовать разные версии одной и той же библиотеки для разных комбинаций процессора и ОС (чаще, чем нам это нужно)

Я пытался найти некоторые альтернативы прямому решению на основе git, но без особого успеха - например, git-application , который кажется слишком сложным для того, что я пытаюсь сделать.

Сейчас я столкнулся с тем фактом, что, по-видимому, существует очень сильное мнение против помещения двоичных файлов в git или любой другой VCS (хотя технически у меня также были бы файлы заголовков; я также мог бы передать структуру папок, которую я описал напрямую, в git, чтобы не было tgz \ zip, но у меня все еще были бы двоичные файлы библиотек) и что некоторые из моих коллег, руководимые которые разделяют твердое мнение, выступают против такой схемы вещей.Я прекрасно понимаю , что git отслеживает контент, а не файлы , но в некоторой степени я буду отслеживать также и контент, и я верю, что это определенно будет улучшением по сравнению с текущей схемой вещей, которая у нас есть прямо сейчас.

Что было бы лучшим выходом из этой ситуации? Знаете ли вы какие-либо альтернативы схеме вещей, основанной на git (VCS)? Было бы так чудовищно иметь мою схему под git :)? Пожалуйста, поделитесь своим мнением и особенно своим опытом работы в подобных ситуациях.

Спасибо