Actualización de submódulo de Git

No tengo claro qué significa lo siguiente (de la documentación de actualización del submódulo Git ):

... hará que los submódulos HEAD se separen, a menos que --rebaseo --mergese especifique ...

¿Cómo --rebase/ --mergecambia las cosas?

Mi caso de uso principal es tener un montón de repositorios centrales, que incrustaré a través de submódulos en otros repositorios. Me gustaría poder mejorar estos repositorios centrales, ya sea directamente en su ubicación original o desde dentro de sus repositorios de incrustación (los que los usan a través de submódulos).

• Desde estos submódulos, ¿puedo crear ramas / modificaciones y usar push / pull como lo haría en repositorios regulares, o hay cosas de las que hay que tener cuidado?
• ¿Cómo avanzaría el commit de submódulo referenciado de say (etiquetado) 1.0 a 1.1 (aunque el jefe del repositorio original ya está en 2.0), o elegiría qué commit de ramificación se usa?

Esta página de GitPro resume muy bien la consecuencia de una actualización de submódulo 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 un commit, 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ódulos, confirme en ese directorio de submódulos sin crear una rama para trabajar y luego ejecute git submodule update nuevamente 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 menciona en " git submodule tracking latest ", 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

Ver " git submodule update --remotevsgit pull ".

La respuesta de 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 submódulos (el gitlink , una entrada especial en el índice de repositorio principal ), y deberá agregar, confirmar y enviar dichas referencias desde el repositorio principal.
La próxima vez que clone ese repositorio principal, rellenará los submódulos para reflejar esas nuevas referencias SHA1.

El resto de esta respuesta detalla la característica clásica de submódulo (referencia a una confirmación fija , que es el punto central 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, todavía revertirá su trabajo, pero al menos tiene un puntero al que volver.

Cambiar ramas con submódulos en ellas también puede ser complicado. Si crea una nueva rama, agrega un submódulo allí y luego vuelve a cambiar a una rama sin ese submódulo, aún tiene el directorio de submódulos como un directorio sin seguimiento:

Entonces, para responder a sus preguntas:

¿Puedo crear ramas / modificaciones y usar push / pull como lo haría en repositorios regulares, o hay cosas de las que tenga cuidado?

Puede crear una rama y hacer modificaciones.

ADVERTENCIA (del Tutorial de submódulos de Git ): siempre publique (empuje) el cambio de submódulo antes de publicar (empujar) el cambio en el superproyecto que hace referencia a él. Si olvida publicar el cambio de submódulo, otros no podrán clonar el repositorio.

¿Cómo avanzaría el commit de submódulo referenciado de say (etiquetado) 1.0 a 1.1 (aunque el jefe del repositorio original ya está en 2.0)

La página " Comprensión de submódulos " puede ayudar

Los submódulos de Git se implementan utilizando dos partes móviles:

• el .gitmodulesarchivo y
• Un tipo especial de objeto de árbol.

Estos juntos triangulan una revisión específica de un repositorio específico que se desprotege en una ubicación específica en su proyecto.

Desde la página del submódulo git

no puede modificar el contenido del submódulo desde el proyecto principal

100% correcto: no puede modificar un submódulo, solo consulte uno de sus commits.

Es por eso que, cuando modifica un submódulo desde el proyecto principal, usted:

• necesita comprometerse y empujar dentro del submódulo (al módulo ascendente), y
• luego suba en su proyecto principal y vuelva a confirmar (para que ese proyecto principal haga referencia al nuevo compromiso de submódulo que acaba de crear y empujar)

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 (commit) a otro repositorio de Git que no está vinculado por el ciclo principal de desarrollo del proyecto: él (el "otro" repositorio de Git) puede evolucionar independientemente.
Depende del proyecto principal elegir de ese otro repositorio cualquier 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 haciendo referencia a Una nueva versión de dicho submódulo.

Pero la idea principal sigue siendo: hacer referencia a 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 configuración (esto es de lo que se trata la Gestión de la Configuración , que abarca el mero Sistema de Control de Versiones )

Si un componente realmente pudiera desarrollarse al mismo tiempo que su proyecto principal (porque cualquier modificación en el proyecto principal implicaría modificar el subdirectorio, y viceversa), entonces ya no sería un "submódulo", sino un subtree merge (también presentado en la pregunta Transferencia de base de código heredado de cvs a repositorio distribuido ), vinculando la historia de los dos repositorios Git.

¿Ayuda eso a comprender la verdadera naturaleza de los submódulos de Git?

Para actualizar cada submódulo, puede invocar el siguiente comando (en la raíz del repositorio):

git submodule -q foreach git pull -q origin master

Puede eliminar la opción -q para seguir todo el proceso.

Para abordar la opción --rebasevs --merge.:

Supongamos que tiene el súper repositorio A y el submódulo B y desea trabajar en el submódulo B. Ha hecho su tarea y lo sabe después de llamar

git submodule update

está en un estado sin CABEZA, por lo que es difícil volver a realizar cualquier confirmación que haga 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, combina los cambios más recientes y actualiza sus submódulos.

<in A>
git merge develop
git submodule update

Oh no! Estás de nuevo en un estado sin cabeza nuevamente, probablemente porque B ahora está apuntando al SHA asociado con la nueva sugerencia de B, o algún otro commit. Si 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 ha sido basada en el nuevo commit, y lo más importante, ¡todavía estás en tu rama de desarrollo para B, no en un estado sin cabeza!

( --mergeCombinará los cambios de beforeUpdateSHA a afterUpdateSHA en su rama de trabajo, en lugar de cambiar los cambios en afterUpdateSHA).

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 la parte superior en cada submódulo, los cambiará de base y verificará la última revisión del submódulo. Como dice la documentación :

--remoto

Esta opción solo es válida para el comando de actualización. En lugar de usar 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 ejecutarse git pullen cada submódulo, que generalmente es exactamente lo que desea.

(Esto fue copiado de esta respuesta ).