Лучшие практики для нескольких репозиториев git
У меня есть около 20 различных хранилищ. Многие являются независимыми и компилируются как библиотеки, но некоторые другие имеют зависимости между ними. Разрешение зависимости и ветвление сложны.
Предположим, что у меня естьсупер проект это только объединяет все другие репозитории. Он используется исключительно для запуска тестов - никаких реальных разработок здесь не происходит.
/superproject [master, HEAD]
/a [master, HEAD]
/b [master, HEAD]
/c [master, HEAD]
/...
Теперь, чтобы разработать конкретные функции или исправления для каждого из них (a
), особенно один из тех, которые требуют определенных версий проектов для компиляции или запуска (b v2.0
а такжеc 3.0
) Я должен создать новую ветку:
/superproject [branch-a, HEAD] <-- branch for 'a' project
/a [master] <-- new commits here
/b [v2.0]
/c [v3.0]
Заb
может потребоваться что-то еще, напримерa v0.9
а такжеc v3.1
:
/superproject [branch-b, HEAD] <-- branch for 'b' project
/a [v0.9] <-- older version than 'a'
/b [master] <-- new commits go here
/c [v3.1] <-- newer version than 'a'
Это становится еще более сложным и сложным при реализации общих рабочих процессов git, включающих ветви функций, ветви исправлений, ветки релиза и т. Д. Мне посоветовали (и не рекомендовали) использоватьgit-submodules
, git-subtree
Google'sgit-repo
, git-slave
, так далее.
Как я могу управлятьнепрерывная интеграция для такого сложного проекта?
РЕДАКТИРОВАТЬ
Реальный вопрос в том, как запустить тесты, не издеваясь над всеми другими зависимыми проектами? Особенно, когда все проекты могут использовать разные версии.Запускать тесты Jenkins после коммитов в подмодулях git