Кто-нибудь действительно использует git super / subprojects?

Question

Кто-нибудь использует новую функцию git super / subproject в реальных проектах? Насколько хорошо это работает? Например, я понимаю, что если я нажимаю на подпроект, я должен вручную вызывать хуки суперпроектов (возможно, используя хук подпроектов, но тем не менее)?

Answer 1

Используя подмодуль, вы определяете в своем рабочем пространстве Git (имеется в виду репозиторий Git «супер-проект») конфигурацию .
Под «конфигурацией» я подразумеваю «список тегов или узла SHA-1, необходимых для работы в вашем рабочем пространстве».
(под работой я подразумеваю все «усилия по разработке», которые вы делаете в своем рабочем пространстве: классическая компиляция, или исправление, или слияние, или развертывание, или ...).
Это тот случай, когда вы клонируете суперпроект и «git update» свои подмодули: вы извлекаете точные репозитории SHA1, которые были ранее зафиксированы в суперпроекте (записано как gitlink в указатель ).

Другой режим - когда вы работаете над своим суперпроектом и над одним или несколькими подмодулями.
Это означает, что для заданных подмодулей вы извлекли конкретную ветвь (вы больше не используете отдельную HEAD для содержимого этих подмодулей, а скорее указатель на верхушку ветки).
Затем «отправка подмодуля» означает обновление удаленного хранилища, содержащего этот подмодуль (и только этот).

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

Из учебника по подмодулям :

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

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

Answer 2

FWIW, мы пытаемся совершить скачок в git, и наш проект ( bitweaver , система управления контентом) является высокомодульной системой с почти 160 репозиториями ). «Сборка» обычно содержит два десятка или более вложенных репозиториев. Мы использовали «виртуальные модули» в CVS, и это сработало для нас фантастически, однако CVS имеет свои ограничения для постановки коммитов.

Подмодули Git имеют некоторые серьезные ограничения, и вам определенно следует оценить реализацию Mercurial, поскольку она, безусловно, более дружественная и гибкая для внешних / модульных проектов (то есть поддерживает другие системы VCS, даже HgGit).

Вот самые большие проблемы:

1. Каждый подмодуль жестко связан с конкретный коммит, когда вы "git submodule add" в супер-репозитории. Это по дизайн, и искал в качестве выгоды мерзавцы, так что я не ожидаю, что это изменится в ближайшее время. Это больно в система, как наша, где коммит всегда происходят в подмодули. Вы должны обновить супер проект, чтобы не отставать, или обновить ваши суб-репо, чтобы освоить после начальное обновление субмодуля. (увидеть Supergit ниже для нашего решения).

2. Вы не можете легко зафиксировать и подтолкнуть к все суб-репо из корня. Это тоже очень раздражает, видите Супергит ниже.

3. Различных ошибок , которые могут быть мучительными, особенно вещи, которые «молча перезаписывают изменения».

supergit

Мы написали сценарий вызова оболочки supergit , который обрабатывает некоторые проблемы. Он выполняет мастер клонирования, инициализации подмодуля, обновления и проверки одним махом. Он также будет выполнять команды git для всех каталогов супер-репо по отдельности (массовая обработка git).

HTH, удачи.

Answer 3

Если вы имеете в виду подмодули, то конечно.

Подмодули не знают и не должны знать, где они используются. Например, у меня есть один подмодуль, который используется в нескольких известных мне проектах (и, возможно, несколько, которых я не знаю).

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