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

ProgramBox

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

Post author:admin
Запись опубликована:8 февраля, 2023
Post category:Вопросы по программированию

#c #windows #git #version-control

#c #Windows #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 может «#включать» заголовочные файлы в соответствующие каталоги подмодулей. Сценарий сборки, включенный в основной продукт / репозиторий, может, по-видимому, приступить к рекурсивной компиляции всех подмодулей.

Хорошо, теперь вопрос:

Как вы обычно кэшируете двоичные файлы для каждого репозитория? Компиляция некоторых из наших зависимостей занимает несколько часов и обновляется не очень часто. С помощью приведенной выше схемы я мог бы клонировать / извлекать высокоуровневый проект с сервера, чтобы исправить небольшую ошибку. Теперь, насколько я понимаю, я также вынужден клонировать все тысячи файлов, составляющих каждую из этих зависимостей с открытым исходным кодом — я беспокоюсь, что это может занять некоторое время (особенно в Windows). Что еще хуже, разве я не был бы вынужден перекомпилировать каждый подмодуль, даже если никто не менял этот подмодуль месяцами? (Похоже, что какая-то локальная схема «хэш-таблицы» на каждом компьютере разработчика, которая связывает идентификатор набора изменений с набором скомпилированных двоичных файлов, была бы удобна …)

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

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

1. Вам нужно будет выполнить полное клонирование и сборку только один раз. Просто сохраните файлы клонирования / сборки на своем компьютере. Когда вам нужно внести быстрое изменение, просто внесите его локально, git commit и git push — все ваши файлы проекта и сборки останутся там.

2. Вы также можете добавлять записи .gitignore , чтобы заставить git игнорировать ваши файлы сборки, чтобы они не отображались в git status

3. Как я уже отмечал, в прошлом у меня была привычка клонировать репозиторий для ветки, работать с ним, а затем удалять весь репозиторий. Похоже, я должен работать по-другому и иметь только один рабочий каталог? Теперь с помощью Git я могу одновременно проверять только одну ветку / набор изменений… каков наилучший способ быстрого переключения передач между ветвями? (Например, переключитесь с разработки основных новых функций на ветку исправления мелких ошибок). Просто есть коллекция клонированных репозиториев со скомпилированными двоичными файлами в каждом?

4. О, теперь я вижу проблему. Лично ваше последнее предложение на самом деле именно так, как я бы это сделал — иметь несколько постоянных локальных клонов с соответствующими файлами сборки в каждом.

5. Однако может быть лучший способ. Я не претендую на звание эксперта по git.

Ответ №1:

Обычно это плохая идея, но почему бы вам не проверить двоичные файлы в подмодулях, а также скомпилированный код для подмодулей, которые меняются нечасто? Таким образом, выборка приведет к удалению ячеек, и когда вы скомпилируете новую версию зависимости с измененными двоичными файлами, вы увидите, что двоичные файлы отображаются в выводе состояния git.

1. В итоге мы сделали небольшое изменение этого: поместили скомпилированные сторонние двоичные файлы в подмодули. Исходный код хранится в отдельном репозитории, так что нашим приложениям, использующим двоичные подмодули, не нужно тратить время на клонирование исходного кода этого проекта. Например, «VTK-bin» — это подмодуль, используемый нашим продуктом, а «VTK-source» содержит исходный код, используемый для генерации «VTK-bin».