¿Alternativas a los submódulos de Git?

Siento que usar submódulos de Git es de alguna manera problemático para mi flujo de trabajo de desarrollo. He oído hablar de Git subtree y Gitslave.

• ¿Existen más herramientas para múltiples proyectos de repositorios y cómo se comparan?
• ¿Se pueden ejecutar estas herramientas en Windows?

Lo que es mejor para usted depende de sus necesidades, deseos y flujo de trabajo. En algunos sentidos son semi-isomorfos, es solo que algunos son mucho más fáciles de usar que otros para tareas específicas.

• gitslave es útil cuando controlas y desarrollas en los subproyectos más o menos al mismo tiempo que el superproyecto, y además cuando normalmente quieres etiquetar, bifurcar, empujar, extraer, etc. todos los repositorios al mismo tiempo. gitslave nunca se ha probado en Windows que yo sepa. Requiere perl.

• git-submodule es mejor cuando no controla los subproyectos o más específicamente desea arreglar el subproyecto en una revisión específica incluso cuando el subproyecto cambia. git-submodule es una parte estándar de git y, por lo tanto, funcionaría en Windows.

• git-subtree proporciona una interfaz para la estrategia de fusión de subárboles incorporada de git. Es mejor cuando prefiere tener un historial de git "unificado" de un solo repositorio. A diferencia de la estrategia de fusión de subárboles, es más fácil exportar los cambios a los diferentes árboles (directorio) al proyecto original, pero no es tan automático como lo es con gitslave o incluso con git-submodule.

• repo es en teoría similar a gitslave, pero no tan bien documentado para operaciones que no son de Android que he encontrado. Está bastante dedicado al modelo de desarrollo de Google Android y solo admite de forma nativa un puñado de comandos git (aunque puede ejecutar comandos arbitrarios) y el soporte nativo limitado no admite, por ejemplo, un repositorio centralizado para enviar y verificar un rama parece bastante difícil.

• mr de kitenet es lo que le gustaría usar si tiene múltiples sistemas de control de versiones en uso, pero está mayormente limitado para superproyectos solo de git debido a su enfoque de mínimo común denominador. Hay formas de ejecutar comandos arbitrarios, pero no están tan bien integrados.

Actualmente uso submódulos para el desarrollo y no solo para relacionar bibliotecas de terceros. Hay algunas formas en las que puede hacer la vida más fácil con submódulos, especialmente cuando son la fuente de conflictos de fusión o rebase. Mire a ls-tree para obtener las 2 confirmaciones involucradas en un conflicto en el submódulo. Esta es probablemente la parte más difícil de manejar de los submódulos para las personas. Por ahora, las secuencias de comandos harán que sea mucho más fácil trabajar con esto. Las versiones futuras de Git deberían tener un mejor soporte nativo para lidiar con ellos.

Espero que esto ayude.

Encontramos un problema similar al usar submódulos de Git en proyectos donde teníamos dependencias en una variedad de lenguajes. Para lidiar con ellos, creamos y abrimos una herramienta llamada MDLR ("Modular") que le brinda dependencias de Git controladas por versiones declarativas con una funcionalidad similar a los submódulos de Git, pero sin el molesto flujo de trabajo. Puede instalarlo y administrar sus dependencias con las instrucciones / descargas en el repositorio de GitHub

Para algunos casos de uso, me han gustado cada uno de los siguientes dos enfoques simples:

• Repositorios anidados. Si su proyecto de software tiene un mecanismo de complemento, con cada complemento en su propio subdirectorio, puede tener sentido ignorar estos directorios de complementos y, en su sistema de archivos local, convertir cada uno de ellos en su propio repositorio de git. De esta manera, todos sus archivos forman un solo árbol de directorios, pero se administran en diferentes repositorios de git. No confundirá a git.

• Repositorios por paquete. Para proyectos de software en los que utiliza algún tipo de sistema de gestión de paquetes de código fuente (gem / bundler, npm, pear o similar), puede tener sentido colocar su código reutilizado en repositorios git separados y luego crear paquetes fuente a partir de ellos. y luego instalarlos con la herramienta de administración de paquetes en el proyecto principal. El repositorio de git de su proyecto principal solo contendría una referencia a los paquetes requeridos y sus versiones, mientras que el código real de estos paquetes se ignorará como se hace con todos los demás paquetes y bibliotecas externas también. En comparación con los repositorios anidados propuestos anteriormente, este es un enfoque más elaborado, ya que permite especificar qué versión del paquete se instalará.