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?