Создание публичного репо с подмодулями

Question

Я хочу создать публичное репо (голый репо), который содержит несколько подмодулей. Я хочу, чтобы разные люди клонировали это голое репо, делали изменения в любых подмодулях. Обновите публичное репо. Однако я понял, что это довольно болезненно. Я хочу, чтобы мое репо выглядело следующим образом:

У меня есть четыре независимых репозитория. a.kernel b.rootfs c.apps d.modules. Я объединять их в один суперэпо, называемый «build». Из этого суперэпо я делаю голый репо build.git, который делится между людьми.

Теперь, если кто-то клонирует голый репо и вносит изменения в «ядро», подмодуль, то он должен делать следующие вещи, чтобы внести изменения в публичное обнаженное репо.

1. передать его «ядру», репо в местном клоне.
2. обязуется «построить», суперэпо в местном клоне.
3. передать его «ядру», подмодулю в публичном репо.
4. обязуется «строить», общественный суперэпо.
5. вытащите изменения в build.git, публичное обнаженное репо.

Выполнение всего этого является болезненным. Это своего рода поражение моей цели связывания 4 репо в 1 суперэпо. Есть ли лучший способ сделать это. (Я предполагаю, что пользователям, которые будут делать это, доверяют, и им разрешено что-то испортить.)

Answer 1

Мне интересно видеть другие ответы на это, но я боюсь, что вы немного смущаете.

Другие разработчики не должны клонировать build, чтобы внести изменения в другие независимые репозитории. Их рабочий процесс должен выглядеть примерно так:

• Клон apps.
• Внесите изменения в apps.
• Push обязуется подключиться к серверу.

Затем вы (или лучше, периодическая или CI процесс) просто сделать git submodule update на build репо, а затем построить.

Обратите внимание, что разработчикам ничего не нужно совершать (или даже прикоснуться) к репозиторию build.

В этом примере каждый подмодуль должен быть полностью автономным репозиторием. Если это не так (если вам нужно изменить build, чтобы применить какие-либо изменения в подмодулях), то они не должны быть подмодулями, а скорее подкаталогами build.

Если разработчики должны строить на месте, они должны сделать следующий раз:

• Clone build
• Редактировать .gitmodules указать каждый подмодуль в местном репо
• Run git submodule sync, чтобы применить изменения к.gitmodules

Их местная копия build теперь указывает на их локальные копии подмодулей, а не на «благословенную» копию сервера. Это означает, что они могут использовать build для тестирования построения всего проекта, включая их локальные изменения, не влияя на стабильный код на сервере. Но не нужно (или рекомендуется) пользователям вносить эти изменения в build до сервера. С GitHub вы можете предотвратить несчастные случаи, не добавляя открытые ключи других разработчиков в репозиторий build.