¿Cómo puedo "confirmar" cambios en un submódulo de git?

Question

He creado ingeniosamente un submódulo de git y lo he tratado como un Subversion externo, es decir, ahora está lleno de cambios que me acabo de dar cuenta de que no se han comprometido ni llevado a ninguna parte.

¿Hay alguna manera fácil de confirmar/presionar los cambios del submódulo de regreso al repositorio de subida? ¿Y cuál es la técnica recomendada en Git para hacer el desarrollo simultáneo en repositorios separados (pero vinculados) de esta manera?

Answer 1

El submódulo es su propio área de trabajo/repo, con su propio directorio .git.

Así, en primer commit/empujar los cambios de su submódulo:

$ cd path/to/submodule 
$ git add <stuff> 
$ git commit -m "comment" 
$ git push 

Entonces diga a su proyecto principal para realizar un seguimiento de la versión actualizada:

$ cd /main/project 
$ git add path/to/submodule 
$ git commit -m "updated my submodule" 
$ git push 

Answer 2

se puede tratar a un submódulo exactamente como un repositorio común. Para propagar los cambios en sentido ascendente, simplemente realice la confirmación y presione como lo haría normalmente dentro de ese directorio.

Answer 3

Antes de poder confirmar y enviar, necesita iniciar un árbol de repositorio en funcionamiento para un submódulo. estoy usando tortuga y qué cosas siguientes:

En primer lugar comprobar si existen archivos .git (no un directorio)

• si no existe el fichero que contiene el camino a SuperModule directorio Git
• eliminar este el archivo
• hacer git init
• hacer git add ruta remota la utilizada para submódulo
• siga las instrucciones a continuación

Si existía el archivo .git, no estaba el directorio .git que rastrea el árbol local. Aún necesita una rama (puede crear una) o cambiar a la maestra (que a veces no funciona). Lo mejor es - git fetch - git pull. No omitas buscar.

Ahora sus confirmaciones y tirones se sincronizarán con su origin/master

Answer 4

Tenga en cuenta que si ha cometido un montón de cambios en varios submódulos, puede (o será pronto capaz de) empujar todo en uno ir (es decir, uno empuje de la cesión temporal de los padres), con:

git push --recurse-submodules=on-demand 

git1.7.11 ([ANNOUNCE] Git 1.7.11.rc1) menciona:

"git push --recurse-submodules" aprendí a buscar opcionalmente en los historiales de los submódulos vinculados al superproyecto y sacarlos.

hecho probablemente después de this patch y la opción --on-demand:

--recurse-submodules=<check|on-demand|no>:: 

Asegúrese de que todos submódulo comete utilizado por las revisiones que ser empujado están disponibles en una rama de seguimiento remoto.

• Si se utiliza check, se comprobará que todos los envíos submódulo que cambiaron en las revisiones que ser empujados están disponibles en un mando a distancia.
  De lo contrario, la inserción se cancelará y saldrá con un estado distinto de cero.
• Si se usa on-demand, se presionarán todos los submódulos que cambiaron en las revisiones que se presionarán.
  Si a pedido no pudo enviar todas las revisiones necesarias, también se cancelará y saldrá con un estado distinto de cero.

Esta opción solo funciona para un nivel de anidamiento. No se presionarán los cambios en el submódulo dentro de otro submódulo.

Answer 5

$ git submodule status --recursive 

También es un salvavidas en esta situación. Puede usarlo y gitk --all para realizar un seguimiento de sus sha1 y verificar que sus submódulos estén apuntando a lo que usted cree que son.