Digamos que tengo un proyecto que tiene múltiples componentes: un componente de servidor, un componente de aplicación web, un componente de iOS, un componente de Android, etc. Estos componentes son todas bases de código separadas, pero también están unidas de forma flexible (por ejemplo, un cambio en el servidor el código también podría requerir un cambio en todos los demás componentes)
¿Cuál es la forma más eficiente en Git para organizar este proyecto? Si lo pones todo en un repositorio, siempre tendrías las últimas versiones, pero las cosas se vuelven bastante complicadas cuando comienzas a cambiar un componente y no los otros.
Por otro lado, si crea cada componente como un repositorio separado, ¿cómo podría "vincular" estos repositorios para saber que la versión 2.0 de la aplicación requiere la versión 1.5 del componente del servidor, etc.
¿Hay una característica en git fuera de mantener los léame actualizados (o alguna solución mejor que no veo) para administrar de manera más efectiva múltiples repositorios relacionados?
Respuestas:
Los subproyectos son el lugar donde los sistemas de control de versiones distribuidos (DVCS) comienzan, si no se deshacen, sin duda se vuelven un poco inestables.
Los submódulos de Git y los subrepositorios de Mercurial tienen como objetivo el soporte de subproyectos. Ambos han mejorado lanzamiento por lanzamiento (hasta el punto de que la antigua advertencia de "esta característica existe de Mercurial, pero probablemente no debería usarla" ya no es frontal y central).
Aún así, los repositorios de proyectos múltiples siguen siendo más un caso de uso especializado en lugar de una función de uso de todos. La documentación contiene numerosas advertencias y las instrucciones de "cómo usar esto" que dejan en claro que la gestión de "proyectos de proyectos" es una preocupación de dos niveles, con la metagestión leve pero genuinamente diferente de la gestión directa de proyectos de un solo nivel. Como resultado, hay mucha menos experiencia por ahí. Y no hay escasez de "¡no use submódulos git!" y "¡evite los subrepos mercuriales!" comentarios y publicaciones de blog.
Mi propia experiencia con subrepos fue mixta. Funcionó ... pero también fue molesto. Me encanta la idea de los subproyectos, pero en la práctica encuentro que las alternativas, ya sean grandes repositorios todo en uno o proyectos de hermanos acompañantes, son más fáciles de disputar (aunque menos elegantes). Espero con ansias el día en que los subrepos sean convencionales y no sean un dolor, pero aún no lo he experimentado.
Esto no quiere decir que administrar submódulos / subrepos no funcionará para usted, pero es algo que debe hacerse con cuidado y, definitivamente, algo de experimentación y planificación previa.
Dado que está centrado en Git, también debe explorar los subárboles de Git, que algunos consideran una mejor alternativa a los submódulos de git .
fuente
Si usa C #, puede usar NuGet.
Convierta cada componente en una biblioteca y manténgalos en su propio repositorio. Realice lanzamientos de los componentes básicos que versiona de acuerdo con las versiones semánticas.
Finalmente, haga que su servidor de compilación empaquete las bibliotecas en paquetes NuGet y consuma esos paquetes NuGet en los proyectos para los componentes front-end (iOS, Android).
El mismo enfoque básico (dependencias de versión y paquete) también se puede utilizar en otros idiomas, pero puede que no sea tan conveniente.
No recomendaría usar submódulos de Git. Si bien en teoría se puede usar para este tipo de problemas, creo que es una molestia mayor de lo que vale.
fuente
En mi opinión, esto dependería de cuánto estén realmente acoplados. Es realmente agradable poder ejecutar un automatizado
git bisectal rastrear una regresión, pero esto será difícil de hacer si cada confirmación depende de una versión diferente de sus otras dependencias para ejecutarse.Dos posibles opciones serían un repositorio con submódulos o múltiples repositorios con buenas prácticas de control de versiones.
Este suele ser el dominio de algún marco de administración de dependencias (por ejemplo, Gradle, Maven), no Git en sí.
fuente