El Blog de GitHub

eventualmente, cualquier proyecto de software interesante dependerá de otro proyecto, biblioteca o marco. Git proporciona submódulos para ayudar con esto. Los submódulos le permiten incluir o incrustar uno o más repositorios como una subcarpeta dentro de otro repositorio.

para muchos proyectos, los submódulos no son la mejor respuesta (más sobre esto a continuación), e incluso en su mejor momento, trabajar con submódulos puede ser complicado, pero comencemos mirando un ejemplo sencillo.,

añadiendo un submódulo

digamos que estás trabajando en un proyecto llamado Slingshot. Tienes el código de y-shaped stick y un rubber-band.

foto de flickr compartida por young@art bajo una licencia Creative Commons ( BY)

al mismo tiempo, en otro repositorio, tienes otro proyecto llamado Rock—es solo una Biblioteca genérica rock, pero crees que sería perfecta para Slingshot.

Usted puede agregar rock como un submódulo de slingshot., En el repositorio slingshot:

en este punto, tendrá una carpeta rock dentro de slingshot, pero si tuviera que mirar dentro de esa carpeta, dependiendo de su versión de Git, podrías ver nothing nada.,

Las versiones más recientes de Git harán esto automáticamente, pero las versiones anteriores requerirán que le digas explícitamente a Git que descargue el contenido de rock:

Si todo se ve bien, puedes confirmar este cambio y tendrás una carpeta rock div id=»eb90629a87″> repositorio con todo el contenido del repositoriorock.,

En GitHub, el rock icono de carpeta tendrá un pequeño indicador que demuestra que es un submódulo:

Y haciendo clic en el rock carpeta le llevará a la etiqueta rock repositorio.

Eso es todo! Has incrustado el repositorio rock dentro del repositorio slingshot. Puede interactuar con todo el contenido de rock como si fuera una carpeta dentro de slingshot (porque lo es).,

en la línea de comandos, los comandos de Git emitidos desde slingshot (o cualquiera de las otras carpetas, rubber-band y y-shaped-stick) operarán en el «repositorio padre», slingshot, pero los comandos que emitas desde la carpeta rock operarán solo en el repositorio rock:

unirse a un proyecto usando submódulos

ahora, digamos que eres un nuevo colaborador que se une al proyecto Slingshot., Empezarías ejecutando git clone para descargar el contenido del repositorio slingshot. En este punto, si echaras un vistazo dentro de la carpeta rock, verías nothing nada.

de nuevo, Git espera que le pidamos explícitamente que descargue el contenido del submódulo., También puede usar git submodule update --init --recursive aquí, pero si está clonando slingshot por primera vez, puede usar un comando modificado clone para asegurarse de descargar todo, incluidos los submódulos:

cambiar a submódulos

puede ser un poco complicado tomar una subcarpeta existente y convertirla en una dependencia externa. Veamos un ejemplo.

estás a punto de comenzar un nuevo proyecto, una lata de retroceso mágica, que también necesita un rubber-band., Tomemos el rubber-band que construiste para slingshot, dividiéndolo en un repositorio independiente y luego incrustándolo en ambos proyectos a través de submódulos.

Puede tomar todo de la carpeta rubber-band del proyecto Slingshot y extraerlo en un nuevo repositorio e incluso mantener el historial de confirmaciones.

comencemos extrayendo el contenido de la carpeta rubber-band de slingshot., Puedes usar git filter-branch para hacer esto, dejándote solo con las confirmaciones relacionadas con rubber-band. El comando git filter-branch reescribirá el historial de nuestro repositorio, haciendo que parezca que la carpeta rubber-band ha sido su propio repositorio todo el tiempo. Para obtener más información sobre git filter-branch, consulte este artículo.

el primer paso es hacer una copia de slingshot para trabajar—el objetivo final es que rubber-band se mantenga como su propio repositorio, así que deje slingshot como está., Usted puede usar cp -r de forma recursiva copiar todo el slingshot para una nueva carpeta rubber-band.,

parece rubber-band es sólo otro slingshot, pero ahora, desde el rubber-band repositorio, ejecutar git filter-branch:

En este punto, usted tendrá una carpeta rubber-band, que es un repositorio que se asemeja a una especie de Proyecto de Honda, pero que sólo tiene los archivos y cometer la historia de la etiqueta rubber-band carpeta.,

Desde que esta copia de slingshot, el nuevo repositorio todavía tiene alguna seguimiento remoto ramas de instalación cuando era slingshot. Usted no quiere empujar rubber-band de nuevo en slingshot. Desea enviar esto a un nuevo repositorio.

cree un nuevo repositorio pararubber-banden GitHub, luego actualice el control remoto pararubber-band., Suponiendo que estuviera llamando al control remoto origin, podría:

luego puede publicar el nuevo» módulo genérico de banda elástica»con git push.,

Ahora que se ha separado rubber-band en su propio repositorio, usted necesita para eliminar el antiguo rubber-band carpeta en el slingshot repositorio:

a Continuación, actualizar slingshot uso rubber-band como un submódulo:

Como vimos antes, cuando nos la adición de rock, ahora tenemos un repositorio en un repositorio., Tres repositorios, de hecho: el repositorio «padre» slingshot, más los dos repositorios «sub», rock y rubber-band.

Además, si nos sumergimos de nuevo en el historial de slingshot, veremos las confirmaciones que hicimos originalmente en rubber-band cuando era una carpeta—eliminar la carpeta no borró nada del historial., Esto a veces puede ser un poco confuso—ya que el repositorio rubber-band «hijo» tiene una versión copiada y modificada de esos cambios antiguos slingshot, a veces puede parecer que estás teniendo un déja vu.

desafortunadamente, cualquier colaborador que tire slingshot en este punto tendrá una carpeta vacía rubber-band., Es posible que desee recordar a sus colaboradores que ejecuten este comando para asegurarse de que tienen todo el contenido del submódulo:

también querrá agregar el rubber-band submódulo a magic roll-back can. Afortunadamente, todo lo que necesita hacer es seguir el mismo procedimiento que usó anteriormente cuando agregó rock a slingshot, en «Agregar un submódulo.»

consejos sobre el uso de submódulos (o no)

• Antes de agregar un repositorio como submódulo, primero verifique si tiene una mejor alternativa disponible., Los submódulos de Git funcionan lo suficientemente bien para casos simples, pero en estos días a menudo hay mejores herramientas disponibles para administrar dependencias que las que los submódulos de Git pueden ofrecer. Los lenguajes modernos como Go tienen sistemas de gestión de dependencias amigables y compatibles con Git integrados desde el principio. Otros, como RubyGems de Ruby, nodo.npm de js, o Cocoa CocoaPods y Carthage, han sido añadidos por la comunidad de programación. Incluso los desarrolladores front-end tienen herramientas como Bower para administrar bibliotecas y marcos para JavaScript y CSS del lado del cliente.
• Recuerda que Git no descarga contenido de submódulos de forma predeterminada., Si está agregando un submódulo a un proyecto existente, asegúrese de que cualquier persona que trabaje en el proyecto sepa que necesita ejecutar comandos como git submodule update y git clone --recursive para asegurarse de que lo obtenga todo, ¡esto incluye cualquier servicio de implementación o prueba automatizado que pueda estar involucrado en el proyecto! Le recomendamos que use algo como nuestros «Scripts para gobernarlos a todos» para asegurarse de que todos los colaboradores y servicios tengan acceso al mismo contenido del repositorio en todas partes.
• los submódulos requieren que usted equilibre cuidadosamente la consistencia y la conveniencia., La configuración utilizada aquí prefiere fuertemente la consistencia, a costa de un poco de comodidad. Generalmente es mejor tener los submódulos de un proyecto bloqueados a un SHA específico, para que todos los colaboradores reciban el mismo contenido. Pero esta configuración también hace que sea difícil para los desarrolladores en el repositorio «padre» contribuir con cambios al repositorio de submódulos.
• recuerde que los colaboradores no verán automáticamente las actualizaciones de los submódulos—si actualiza un submódulo, es posible que deba recordar a sus colegas que ejecuten git submodule update o es probable que vean un comportamiento extraño.,
• administrar repositorios dinámicos, en rápida evolución o muy dependientes con submódulos puede convertirse rápidamente en frustrante. Esta publicación se centró en relaciones de repositorio padre-hijo simples y relativamente estáticas. Una futura publicación de seguimiento detallará algunas estrategias para ayudar a administrar flujos de trabajo de submódulos más complejos.

más información