2012-06-04 2 views
1

Скажем, у меня есть 5 GIT проекты, которые являются взаимозависимыми друг на друга:Должен ли я группировать эти взаимозависимые проекты git?

  1. базы данных (переговоры на сервере ниже)
  2. Rendering сервера (переговоры на сервер ниже)
  3. Main App сервера (REST API)
  4. Пуск: скрипты и json для построения вышеуказанных Amazon 4 EC2 машин.
  5. Тесты: работать на App Server
  6. Javascript API (в зависимости от REST API)
  7. JS и REST API Documentation (в зависимости от REST API)

Я предполагаю, что разделение мерзавец проекта выше эволюционировали в практический подход к организации параллельного документооборота.

Проблема в том, что успех всей системы зависит от того, что вышеуказанные 7 проектов согласованы в согласованном состоянии друг с другом.

С одной стороны, легче представить изменение во всей системе, сравнив хэши SHA-1 одного проекта с тем же самым проектом_2 SHA-1.

С другой стороны, я прочитал эти SO answers, в которых упоминается стоимость сложности группировки слишком большого количества проектов. Кроме того, Linus также упоминает гибкость системы git, чтобы даже использовать филиалы для разных проектов, а также возможность переключать стратегию группировки на более позднюю дату (но мы не будем делать такой подход, так как мы не склонны к рискам новичков).

Настоятельно приветствуются любые рекомендации или рекомендации, которые учитывают предприятие с высоким операционным риском и низким профессиональным опытом.

ответ

1

Хотя немного более сложными, «группировка» стратегия имеет достоинства и стоит выстрел:
Это называется submodules и позволит определить одну уникальную ссылку на все ваших проектов, позволяя вам для управления этими проектами в качестве независимых репозиторий git.

Как я объясню в «true nature of submodules», вы по-прежнему можете вносить изменения в подмодуль, пока вы записываете это новое состояние подмодуля в родительском репо.

+0

Nice! Я никогда не был знаком с подмодулями ... после быстрого сглаживания это похоже на его. –

Смежные вопросы