Можете ли вы разрабатывать непосредственно в подмодулях Git?

Question

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

Раньше я пытался заставить свою команду использовать подобные подмодули, но мы не могли заставить ее работать гладко. Мы разрабатывали общий код из самого подмодуля и фиксировали из подмодуля, но столкнулись с таким количеством проблем, что вернулись к тому, что все проекты были в одном каталоге (C: \ dev \ A, C: \ dev \ Common). 1003 *

Я почти уверен, что мы понятия не имеем, как предполагается использовать подмодули, но если вы не можете разработать общий код непосредственно в подмодуле, разве это не усложняет разработку? Может кто-нибудь объяснить, пожалуйста, правильное использование подмодулей?

Answer 1

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

Теперь у вас есть две подмодули организации:

• рекурсивный включает

A
  Common
    (Common could depend itself on other dependencies)
B
  Common
    ...

• или direct включает (только прямые зависимости)

ParentA
   A
   Common
   Other A dependencies
ParentB
   B
   Common
   Other B dependencies

(На самом деле, если бы Common имел свои собственные зависимости, A или B зависел бы от "ParentCommon", который будет ссылаться на Common и все его прямые зависимости)

Если у вас нет структурного императива, где Common должен быть подкаталогом A, я бы порекомендовал вторую организацию, которая ближе к вашей C:\dev\A, C:\dev\Common.

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

Это связано с тем, что с любым инструментом, пытающимся управлять зависимостями, вам все равно придется принимать решения по:

• конфликты зависимостей (A зависит от X, для которого требуется Z1, и Y, для которого требуется Z2: какую версию Z вы хотите использовать / скомпилировать в своем проекте?)
• переопределение зависимостей (когда A зависит от X, для которого требуется Z1, тогда как A также выбирает использование X2)
• цикл зависимостей (где A зависит от B, который опирается на C, который использует ... A!)

Answer 2

Субмодули - это не то, что работает особенно гладко, как вы намерены здесь. Как вы, наверное, заметили, чтобы зафиксировать изменение в проекте в подмодуле (начиная с Git v1.7, вероятно, навсегда), вам необходимо:

1. Внесите изменения в подмодуль.
2. Зафиксируйте подмодуль, получив новый хэш SHA.
3. Обновите файл .gitmodules внешнего проекта с новым хешем.
4. Обязательство по внешнему проекту.

Это громоздко, если вы разрабатываете подмодуль и внешний проект (ы) в режиме lockstep. Это «правильный путь», поскольку предпочтение стабильных конфигураций программного обеспечения простоте при смешивании кодовых баз, но последовательность команд в этом случае патологически длинна.

Тем не менее, появление стека «почему», разработка с использованием подмодулей *, возможно, указывает на одну из нескольких более крупных проблем:

• У вас нет четкого интерфейса между вашим подкомпонентом, и детали реализации просачиваются через границы.
• У вас нет продуманного интерфейса к вашему подкомпоненту, поэтому вам придется заново изобретать вещи, когда вы решаете более интересную проблему.
• Ваш интерфейс стабильный и высококачественный, но у вас нет хорошего процесса контроля качества кода подмодуля, поэтому вместо этого вы постоянно исправляете это, пытаясь выполнить другую работу.
• (Особенно, если A и B продолжают менять разные вещи) Ваш "общий" код на самом деле намного меньше, чем вы думаете, или должен быть разделен по-разному.

Ни один из этих случаев обязательно не относится к вам, но они относятся к числу проблем, которые вызывают ужасный рабочий процесс обновления субмодуля lockstep. Подмодули работают очень хорошо, когда вы можете почти полагаться на разделяемые библиотеки и заголовочные файлы, но есть несколько веских причин (например, странные флаги компиляции, которые должны быть согласованными) для компиляции из исходного кода. Мой подход заключается в том, чтобы исправить эти проблемы, если они действительно являются основными причинами.

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