Actualización del submódulo de Git

Question

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

...hará que los submódulos HEAD se separe, a menos que --rebase o --merge está especificado...

Cómo --rebase/--merge cambiar las cosas?

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

• Desde estos submódulos, ¿puedo crear ramas/modificaciones y usar push/pull como lo haría en los repositorios normales, o hay cosas con las que tener cuidado?
• ¿Cómo podría avanzar el compromiso al que se hace referencia en el submódulo de, por ejemplo, (etiquetado) 1.0 a 1.1 (aunque el encabezado del repositorio original ya está en 2.0), o elegir qué compromiso de rama se utiliza?

Answer 1

Esta href="http://git-scm.com/book/ch6-6.html" rel="noreferrer"> página hace resumir la consecuencia de una actualización submódulo git muy bien

  

Al ejecutar git submodule update, se comprueba la versión específica del proyecto, pero no dentro de una rama. Esto se llama tener una cabeza separada - significa que los puntos de archivos se dirijan directamente a una confirmación, no a una referencia simbólica
.    El problema es que por lo general no quiere trabajar en un entorno cabeza separada, porque es fácil de cambios lose .
  Si se realiza una actualización inicial submódulo, comprometerse en ese directorio submódulo sin crear una rama de trabajo, y luego ejecutar la actualización submódulo git nuevo desde el SuperProject sin comprometerse en el ínterin, Git se sobreponen a los cambios sin que le dice. Técnicamente no perderá el trabajo, pero que no tendrá una rama apuntando a la misma, por lo que será algo difícil de recuperar.

---

Nota de marzo de 2013:

Como se mencionó en " git submódulo seguimiento última ", un submódulo ahora (git1.8.2) puede realizar un seguimiento de 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 --remote vs git pull ".

MindTooth 's respuesta ilustran una actualización manual (sin configuración local):

git submodule -q foreach git pull -q origin master

En ambos casos, que va a cambiar las referencias submódulos (el gitlink , a < a href = "https://stackoverflow.com/a/19354410/6309"> entrada especial en el índice de recompra padres ), y usted tendrá que añadir, comprometerse y empujar dicho referencias desde el repositorio principal. < br> La próxima vez que va a clonar repo que los padres, rellenará los submódulos para reflejar esas nuevas referencias SHA1.

El resto de esta respuesta se detalla la función clásica submódulo (referencia a un fijo confirmación, que es el punto detrás de toda la noción de un submódulo).

---

  

Para evitar este problema, cree una rama cuando se trabaja en un directorio submódulo con git checkout -b trabajo o algo equivalente. Cuando lo haga la actualización submódulo un segundo tiempo, todavía se revertirá su trabajo, pero al menos usted tiene un puntero para volver a.

     

El cambio ramas de cartuchos en ellos también puede ser complicado. Si crea una nueva rama, añadir un submódulo allí, y luego volver a una rama sin que submódulo, todavía tiene el directorio submódulo como un directorio sin seguimiento:

---

Por lo tanto, para responder a sus preguntas:

  

puedo crear ramas / modificaciones y uso de empuje / tracción al igual que lo haría en repos regulares, o hay cosas que tener cuidado con?

Se puede crear una rama de empuje y modificaciones.

ADVERTENCIA (de Git submódulo Tutorial ): Siempre publicar (push) el cambio submódulo antes de publicar (push) el cambio en el SuperProject que hace referencia a ella. Si se olvida de publicar el cambio submódulo, otros no serán capaces de clonar el repositorio.

  

¿cómo iba a avanzar en el submódulo de referencia de confirmación desde digamos (tagged) de 1,0 a 1,1 (a pesar de que el jefe de la cesión temporal original, ya está a 2,0)

La página " Comprensión de cartuchos de " ayuda lata

  submódulos

Git se implementan utilizando dos partes móviles:

     

  
• el archivo .gitmodules y
  
• un tipo especial de objeto de árbol.
  

Estos, junto triangular una revisión específica de un repositorio específica que es de verificacióned cabo en una ubicación específica en el proyecto.

---

Desde la página git

  

que no puede modificar el contenido del sub-módulo de dentro del proyecto principal

100% correcto: no se puede modificar un submódulo, sólo se refieren a uno de sus confirmaciones.

Esto es por qué, cuando se hace modificar un submódulo dentro del proyecto principal, que:

• necesidad de cometer y empujar en el submódulo (hacia el módulo aguas arriba), y
• luego subir en su proyecto principal, y de renovar su compromiso (con el fin de que el principal proyecto para referirse a la nueva sub-módulo comprometerse acaba de crear y de difusión)

Un submódulo le permite tener una desarrollo, donde el proyecto principal sólo se refiere a commit específicas de otros componentes (aquí "otros repositorios Git declarado como sub-módulos").

Un submódulo es un marcador (commit) a otro repositorio Git que no esté obligada por el principal ciclo de desarrollo del proyecto:. Él (el "otro" Git repo) pueden evoluciona de forma independiente
Corresponde al proyecto principal para elegir el otro repo lo que necesita cometer.

Sin embargo, en caso de que desee, por conveniencia , modificar uno de los submódulos directamente desde su proyecto principal, Git le permite hacer eso, siempre y cuando primero publicar esas modificaciones submódulo a su cesión temporal original de Git, y después de comprometer su refering principal proyecto a un nueva versión de dicho submódulo.

Pero la idea principal sigue siendo: hacen referencia a componentes específicos que:

• tienen su propio ciclo de vida
• tiene su propio conjunto de etiquetas
• tienen su propio desarrollo

La lista de específica compromete usted se refiere en su proyecto principal define su configuración (esto es lo que configuración Administración es todo sobre, englobando mera Sistema de control de versiones )

Si realmente se podría desarrollar un componente al mismo tiempo como su proyecto principal (ya que cualquier modificación en el proyecto principal implicaría modificar el subdirectorio, y viceversa), entonces sería ser un "sub-módulo" no más, sino una combinación de subárbol (también presentado en la pregunta Transferencia de código base legado de CVS a distribuida repositorio), que unen la historia de las dos Git repo juntos.

¿Le ayuda la comprensión de la verdadera naturaleza de Git submódulos?

Answer 2

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

git submodule -q foreach git pull -q origin master

Se puede quitar el q para seguir todo el proceso.

Answer 3

Para hacer frente a la opción vs. --rebase --merge:

Digamos que usted tiene súper repositorio A y B submódulo y desea hacer algún trabajo en el submódulo B. Usted ha hecho su tarea y saber que después de llamar

git submodule update

se encuentra en un estado HEAD-menos, por lo que ningún commit que hacer en este momento son difíciles de conseguir de nuevo a. Por lo tanto, usted ha comenzado a trabajar en una nueva rama en el sub-módulo B

cd B
git checkout -b bestIdeaForBEver
<do work>

Mientras tanto, otra persona en el proyecto A ha decidido que la última y mejor versión de B es realmente lo que merece una. Usted, por costumbre, combinar los cambios más recientes abajo y actualizar sus submódulos.

<in A>
git merge develop
git submodule update

¡Oh no! Que está de vuelta en un estado sin cabeza de nuevo, probablemente porque B está ahora apuntando a la SHA asociada con la nueva punta de B, o algún otro cometido. Si sólo tuvieras:

git merge develop
git submodule update --rebase

Fast-forwarded bestIdeaForBEver to b798edfdsf1191f8b140ea325685c4da19a9d437.
Submodule path 'B': rebased into 'b798ecsdf71191f8b140ea325685c4da19a9d437'

Ahora que cada vez mejor idea para B ha sido sincronizado a la nueva comprometerse, y lo más importante, usted todavía está en su rama de desarrollo para el B, no en un estado sin cabeza!

(El --merge va a fusionar los cambios de beforeUpdateSHA a afterUpdateSHA en su rama de trabajo, en lugar de rebase los cambios Onto afterUpdateSHA.)

Answer 4

Git 1.8.2 presenta una nueva opción,--remote, eso permitirá exactamente este comportamiento.Correr

git submodule update --rebase --remote

recuperará los últimos cambios desde arriba en cada submódulo, los cambiará y comprobará la última revisión del submódulo.Como la documentación lo pone:

--remoto

Esta opción sólo es válida para el comando de actualización.En lugar de utilizar el SHA-1 grabado del superproyecto para actualizar el submódulo, utilice el estado de la rama de seguimiento remoto del submódulo.

Esto equivale a correr git pull en cada submódulo, que generalmente es exactamente lo que desea.

(Esto fue copiado de esta respuesta.)