Я очень новичок в 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 - степень, но весь код - внутренние проекты и т. д. был свернут в один большой гигантский репозиторий, и вам пришлось построить все в большом толстом монолитномСценарий сборки при клонировании вновь созданной ветви с сервера. Когда мы закончили с исправлением / новой функцией и объединились с апстримом, мы удалили локальный репозиторий для этой конкретной ветви.)
Мызанимаюсь разработкой под Windows, но в конечном итоге перейдем на другие платформы, не принадлежащие Microsoft, поэтому переносимость важна.