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

Question

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

У меня есть четыре независимых репо.a.kernel b.rootfs c.apps d.modules.Я объединяю их в одно суперэпо, называемое «построить».Из этого суперэпо я делаю голый репозиторий 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.

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

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

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