Git submodule vs Git clone

Estoy trabajando en un proyecto de código abierto en GitHub.

Tiene un subdirectorio / proveedor en el que tiene una copia de varias bibliotecas externas. El responsable original del proyecto actualizó este directorio con una copia más reciente de la biblioteca externa de vez en cuando.

Un desarrollador me envió una solicitud de extracción con la idea de reemplazar esta copia por el submódulo git .

Y estoy considerando si es buena idea o no.

Submódulo Git Pros:

• Los submódulos fueron diseñados específicamente para escenarios similares
• Elimina la posibilidad de un compromiso accidental con el proveedor, que se sobrescribirá en la próxima actualización

Submódulo Git Contras:

• Parece que git submodules empuja la complejidad del encargado de mantenimiento a una persona que clonará / extraerá el proyecto (se requieren pasos adicionales después de clonar para comenzar a trabajar con el proyecto: "git submodule init", "git submodule update"

¿Cuál es tu opinión sobre esto?

Una cosa más. Este problema es una biblioteca de tamaño razonablemente pequeño con dependencias externas muy limitadas. Creo que cualquier herramienta de compilación sería exagerada por el momento.

Una alternativa a un submódulo es usar git subtree. Esto brinda los beneficios de, git submodulepero sin llevar la complejidad al usuario final. El repositorio de terceros se fusiona en el árbol principal del proyecto, pero hay metadatos almacenados de tal manera que puede:

• extraiga el repositorio de terceros más adelante, si se han realizado cambios interesantes
• fusionar en nuevas actualizaciones del repositorio de terceros (nota fusionar , no sobrescribir)

Para los usuarios de Git que no son lo suficientemente sofisticados como para comprender submódulos, el enfoque de subárbol hace que obtener un clon de su proyecto no sea más difícil que cualquier otro clon. Una breve reseña de la documentación:

Los subárboles permiten que los subproyectos se incluyan dentro de un subdirectorio del proyecto principal, incluyendo opcionalmente el historial completo del subproyecto.

Por ejemplo, podría incluir el código fuente de una biblioteca como subdirectorio de su aplicación.

Los subárboles no deben confundirse con submódulos, que están destinados a la misma tarea. A diferencia de los submódulos, los subárboles no necesitan construcciones especiales (como archivos .gitmodule o gitlinks) presentes en su repositorio, y no obligan a los usuarios finales de su repositorio a hacer nada especial o comprender cómo funcionan los subárboles. Un subárbol es solo un subdirectorio que puede comprometerse, ramificarse y fusionarse junto con su proyecto de la forma que desee.

Había configurado un proyecto en el trabajo usando submódulos, y los problemas para mantener los submódulos actualizados en los clones de todos era demasiado trabajo. Recientemente cambié a usar subárboles en todas partes y esos problemas desaparecieron.

Tenga en cuenta que git-subtree es parte del git/contribdirectorio y debe instalarse por separado.

Un inconveniente del uso de submódulos es que los archivos tarballs o zip-archives en Github (y muchos otros servicios) no incluyen las fuentes de submódulos. Es decir, los archivos no son independientes. Esto es un problema si el repositorio es pequeño y realmente no tiene un script de compilación, como un sitio HTML estático que depende de una biblioteca de JavaScript.

Este es un lugar ideal para usar submódulos. Reducen el tamaño y la complejidad de su repositorio y facilitan la actualización de las bibliotecas externas a una nueva versión.

No son difíciles de entender cómo usar, y se usan con bastante frecuencia en esta situación, así que solo tenga en cuenta en el archivo README del proyecto que hace uso de submódulos y qué hacer, y las personas deberían poder entender fuera. La primera vez que encontré un repositorio con un submódulo lo puse en funcionamiento en 10 a 15 minutos y nunca he tenido problemas para averiguar qué hacer desde entonces.

El uso de submódulos le impide realizar cambios locales en el código y crea una dependencia en el repositorio externo. Si está seguro de que nunca querrá personalizar una biblioteca o hacer correcciones de errores locales y puede estar seguro de que el servidor externo siempre estará disponible cuando desee clonar una nueva copia, es el camino a seguir.

En resumen: ¿desea simplemente usar las librerías o las considera parte de su base de código? Si no son "su" código, ¿por qué están en el control de versiones y no solo en algo que necesita tener instalado?