¿Se puede desarrollar directamente en los submódulos de Git?

Question

Tengo dos proyectos (A & B). Ambos usan el proyecto Común. Quiero incluir Common en A & B a través de submódulos porque entonces puedo vincular directamente cada confirmación en A & B a la que confían en Común.

En el pasado intenté que mi equipo utilizara submódulos como este, pero no pudimos hacerlo funcionar sin problemas. Estábamos desarrollando código común desde el propio submódulo & comprometiéndonos desde el submódulo, pero nos encontramos con tantos problemas que volvimos a tener todos los proyectos bajo el mismo directorio (C: \ dev \ A, C: \ dev \ Common).

Estoy bastante seguro de que no tenemos idea de cómo se supone que se usan los submódulos, pero si no puede desarrollar código común directamente en el submódulo, ¿no dificulta eso el desarrollo? ¿Alguien puede explicar el uso correcto de los submódulos?

Answer 1

Puede desarrollar directamente desde un submódulo (como expliqué en "true nature of submodules").
Pero cada vez que ingresa algo en el submódulo (y lo publica en alguna parte), debe asegurarse de comprometerse también en el repositorio principal.

Ahora usted tiene dos organizaciones submódulos:

• recursiva incluye

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

• o directa incluye (dependencias directas solamente)

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

(En realidad, si Common tenían dependencias de su propia, A o B dependería de "ParentCommon", que se referiría a Common y todas sus dependencias directas)

A menos que tenga un imperativo estructural donde Commonobligada sea un subdirectorio de A, recomendaría la segunda organización, que está más cerca de su C:\dev\A, C:\dev\Common.

En realidad, prefiero sólo uno dependencias de profundidad, donde por ParentA, la lista de I todas las dependencias, directa e indirecta, como submódulos.

Eso se debe a que, con cualquier herramienta de tratar de administrar dependencias, que todavía tendrá que tomar decisiones sobre: ​​

• dependencias conflictos (A depende de X que necesita Z1 y Y que necesita Z2: qué versión de Z ¿Quieres usar/compilar en tu proyecto?)
• dependencias de anulación (cuando A depende de X que necesita Z1, mientras que A también optar por utilizar X2) ciclo
• dependencias (donde A depende de B que se basa en C que utiliza ... A!)

Answer 2

Los submódulos no son algo que funcione particularmente sin problemas, de la forma en que lo intentas aquí. Como te habrás dado cuenta, de cometer un cambio en un proyecto en un submódulo (a partir de Git v1.7, probablemente, a perpetuidad), es necesario:

1. realizar el cambio en el submódulo.
2. Comprométase con el submódulo, obteniendo un nuevo hash SHA.
3. Actualice el archivo .gitmodules del proyecto externo con el nuevo hash.
4. Comprométete con el proyecto exterior.

Esto es engorroso si está desarrollando el submódulo y los proyectos externos en bloque. Es "la manera correcta", en cuanto a preferir configuraciones de software estables sobre simplicidad cuando se mezclan bases de código, pero la secuencia de comandos es patológicamente larga en este caso.

que hace estallar la razón por la pila, sin embargo, el desarrollo mismo paso de cartuchos indica probablemente uno de los varios problemas más grandes:

• Usted no tiene una clara interfaz entre el subcomponente, y los detalles de implementación se filtran a través de las fronteras.
• No tiene una interfaz bien pensada para su subcomponente, por lo que tiene que reinventar cosas a medida que resuelve un problema más interesante.
• Su interfaz es estable y de alta calidad, pero no tiene un buen proceso de control de calidad en el código del submódulo, por lo que en su lugar lo repara constantemente mientras intenta hacer otro trabajo.
• (Es decir, si A y B siguen cambiando cosas diferentes) Su código "común" es en realidad mucho más pequeño de lo que cree, o debe dividirse de manera diferente.

Ninguno de estos casos son necesariamente cierto de ti, pero estos son algunos de los problemas que causan el flujo de trabajo de actualización unísono submódulo terrible que está teniendo. Los submódulos funcionan bastante bien cuando se puede casi confiar en bibliotecas compartidas y archivos de encabezado, pero hay una razón de peso (por ejemplo, banderas de compilación raras que deben ser coherentes) para compilar desde el origen. Mi enfoque sería solucionar estos problemas, si son las causas reales.

Si estos problemas no están ahí, sin embargo, puede ser que git sea la herramienta incorrecta para usted. Me duele decirlo, pero esta es definitivamente una posibilidad.