tag - actualización de submódulos de git
git push tag (4)
No tengo claro qué significan los siguientes (de los documentos de actualización de submódulos de git ):
... hará que los submódulos HEAD se
--rebase, a menos que se especifique--rebaseo--merge...
¿Cómo --rebase / --rebase cambia las cosas?
Mi principal caso de uso es tener un montón de repositorios centrales, que incrustaré a través de submódulos en otros repos. Me gustaría poder mejorar estos repositorios centrales, ya sea directamente en su ubicación original o desde dentro de sus repositorios incrustados (los que los usan a través del submódulo).
- Desde dentro de estos submódulos, ¿puedo crear ramas / modificaciones y usar push / pull tal como lo haría en los repositorios regulares, o hay cosas de las que hay que tener cuidado?
- ¿Cómo podría avanzar el submódulo al que se hizo referencia desde digamos (etiquetados) 1.0 a 1.1 (aunque el jefe del repositorio original ya está en 2.0), o seleccionar qué compromiso de rama se usa?
Esta página de GitPro resume muy bien la consecuencia de una actualización de submódulo de git
Cuando ejecuta
git submodule update, verifica la versión específica del proyecto, pero no dentro de una rama. Esto se denomina tener una cabeza separada: significa que el archivo HEAD apunta directamente a una confirmación, no a una referencia simbólica.
El problema es que generalmente no desea trabajar en un entorno de cabeza separada, porque es fácil perder los cambios .
Si realiza una actualización inicial de submódulo, confírmese en ese directorio de submódulo sin crear una rama para trabajar, y luego ejecute git submodule update desde el superproyecto sin comprometerse mientras tanto, Git sobrescribirá sus cambios sin avisarle. Técnicamente no perderá el trabajo, pero no tendrá una rama que lo señale, por lo que será algo difícil de recuperar.
Nota de marzo de 2013:
Como se mencionó en " git submodule tracking ", un submódulo ahora (git1.8.2) puede rastrear una rama.
# add submodule to track master branch
git submodule add -b master [URL to Git repo];
# update your submodule
git submodule update --remote
# or (with rebase)
git submodule update --rebase --remote
Consulte " git submodule update --remote vs git pull ".
La answer MindTooth ilustra una actualización manual (sin configuración local):
git submodule -q foreach git pull -q origin master
En ambos casos, eso cambiará las referencias de los submódulos (el gitlink , una entrada especial en el índice del repositorio principal ), y deberá agregar, confirmar y enviar dichas referencias desde el repositorio principal.
La próxima vez que clone ese repositorio principal, llenará los submódulos para reflejar esas nuevas referencias SHA1.
El resto de esta respuesta detalla la característica de submódulo clásico (referencia a un compromiso fijo , que es el punto más importante detrás de la noción de un submódulo).
Para evitar este problema, cree una rama cuando trabaje en un directorio de submódulos con git checkout -b work o algo equivalente. Cuando realice la actualización del submódulo por segunda vez, aún revertirá su trabajo, pero al menos tendrá un puntero al que volver.
Cambiar ramas con submódulos en ellos también puede ser complicado. Si crea una nueva rama, agregue un submódulo allí y luego vuelva a una rama sin ese submódulo, todavía tiene el directorio de submódulo como un directorio sin seguimiento:
Por lo tanto, para responder a sus preguntas:
¿Puedo crear ramas / modificaciones y usar push / pull tal como lo haría en repositorios regulares, o hay cosas de las que hay que tener cuidado?
Puede crear una rama y empujar modificaciones.
ADVERTENCIA (de Git Submodule Tutorial ): Siempre publique (presione) el cambio de submódulo antes de publicar (presione) el cambio en el superproyecto que lo referencia. Si olvida publicar el cambio de submódulo, otros no podrán clonar el repositorio.
¿Cómo adelantaría el submódulo al que se hace referencia, desde digamos (etiquetados) 1.0 a 1.1 (aunque el jefe del repositorio original ya está en 2.0)?
La página " Comprender los submódulos " puede ayudar
Los submódulos Git se implementan utilizando dos partes móviles:
- el archivo
.gitmodulesy- un tipo especial de objeto de árbol.
Juntos, triangulan una revisión específica de un repositorio específico que se registra en una ubicación específica de su proyecto.
Desde la página del submódulo de git.
No puede modificar el contenido del submódulo desde el proyecto principal.
100% correcto: no puede modificar un submódulo, solo haga referencia a uno de sus confirmaciones.
Por esta razón, cuando modifica un submódulo desde dentro del proyecto principal, usted:
- Necesidad de comprometerse y empujar dentro del submódulo (al módulo ascendente), y
- luego suba en su proyecto principal y vuelva a comprometerse (para que ese proyecto principal se refiera al nuevo submódulo que acaba de crear y enviar)
Un submódulo le permite tener un desarrollo de enfoque basado en componentes , donde el proyecto principal solo se refiere a confirmaciones específicas de otros componentes (aquí "otros repositorios Git declarados como submódulos").
Un submódulo es un marcador (confirmación) para otro repositorio Git que no está vinculado por el ciclo principal de desarrollo del proyecto: (el "otro" repositorio Git) puede evolucionar de forma independiente.
Depende del proyecto principal elegir de ese otro repositorio el compromiso que necesite.
Sin embargo, si desea, por conveniencia , modificar uno de esos submódulos directamente desde su proyecto principal, Git le permite hacerlo, siempre que primero publique esas modificaciones de submódulos en su repositorio original de Git, y luego confirme su proyecto principal refiriéndose a Una nueva versión de dicho submódulo.
Pero la idea principal sigue siendo: referenciar componentes específicos que:
- tener su propio ciclo de vida
- tener su propio conjunto de etiquetas
- tener su propio desarrollo
La lista de confirmaciones específicas a las que se refiere en su proyecto principal define su configuration (de esto se trata la Gestión de la Configuración , englobando el mero Sistema de Control de Versiones )
Si realmente se pudiera desarrollar un componente al mismo tiempo que su proyecto principal (porque cualquier modificación en el proyecto principal implicaría modificar el subdirectorio, y viceversa), entonces no sería más un "submódulo", sino un fusión de subárbol (también presentada en la pregunta configuration ), que une la historia de los dos repositorios de Git.
¿Eso ayuda a entender la verdadera naturaleza de los submódulos Git?
Git 1.8.2 presenta una nueva opción: --remote que permitirá exactamente este comportamiento. Corriendo
git submodule update --rebase --remote
buscará los últimos cambios desde el nivel superior en cada submódulo, los volverá a introducir y revisará la última revisión del submódulo. Como dicen los documentos :
--remoto
Esta opción solo es válida para el comando de actualización. En lugar de utilizar el SHA-1 grabado del superproyecto para actualizar el submódulo, use el estado de la rama de seguimiento remoto del submódulo.
Esto es equivalente a ejecutar git pull en cada submódulo, que generalmente es exactamente lo que quieres.
(Copiado de esta respuesta )
Para abordar la opción --rebase vs --merge:
Digamos que tienes un super-repo A y un submódulo B y quieres hacer un poco de trabajo en el submódulo B. Has hecho tu tarea y sabes que después de llamar
git submodule update
estás en un estado sin CABEZA, por lo que es difícil volver a responder a cualquier compromiso que hagas en este momento. Entonces, has comenzado a trabajar en una nueva rama en el submódulo B
cd B
git checkout -b bestIdeaForBEver
<do work>
Mientras tanto, alguien más en el proyecto A ha decidido que la última y mejor versión de B es realmente lo que A merece. Usted, por costumbre, fusiona los cambios más recientes y actualiza sus submódulos.
<in A>
git merge develop
git submodule update
¡Oh no! Has vuelto a estar en un estado sin cabeza de nuevo, probablemente porque B ahora apunta a la SHA asociada con la nueva sugerencia de B, o algún otro compromiso. Si tan solo tuvieras:
git merge develop
git submodule update --rebase
Fast-forwarded bestIdeaForBEver to b798edfdsf1191f8b140ea325685c4da19a9d437.
Submodule path ''B'': rebased into ''b798ecsdf71191f8b140ea325685c4da19a9d437''
Ahora que la mejor idea para B se ha rebasado en el nuevo compromiso, y lo que es más importante, aún está en su rama de desarrollo para B, ¡no en un estado sin cabeza!
(la combinación fusionará los cambios anteriores a UpUpdateSHA a afterUpdateSHA en su rama de trabajo, en lugar de rebasar los cambios a afterUpdateSHA).
Para actualizar cada submódulo, puede invocar el siguiente comando. (En la raíz de repo.)
git submodule -q foreach git pull -q origin master
Puede eliminar la opción -q para seguir todo el proceso.