git-submodule: en línea en la nube

PROGRAMA:

NOMBRE

git-submodule: inicializa, actualiza o inspecciona submódulos

SINOPSIS

git submódulo [--quiet] añadir [-b ] [-f | --force] [--name ]
[--referencia ] [--profundidad ] [-] [ ]
git submódulo [--quiet] estado [--cached] [--recursive] [-] [ ...]
git submódulo [--quiet] init [-] [ ...]
git submódulo [--quiet] deinit [-f | --force] [-] ...
git submódulo [--quiet] actualización [--init] [--remote] [-N | --no-fetch]
[-f | --force] [--rebase | --merge] [--reference ]
[--profundidad ] [--recursivo] [-] [ ...]
git submódulo [--quiet] resumen [--cached | --files] [(-n | --summary-limit) ]
[cometer] [-] [ ...]
git submódulo [--quiet] foreach [--recursive]
git submódulo [- silencioso] sincronización [--recursivo] [-] [ ...]

DESCRIPCIÓN

Inspecciona, actualiza y gestiona submódulos.

Un submódulo le permite mantener otro repositorio de Git en un subdirectorio de su
repositorio. El otro repositorio tiene su propio historial, que no interfiere con el
historial del repositorio actual. Esto se puede utilizar para tener dependencias externas como
bibliotecas de terceros, por ejemplo.

Sin embargo, al clonar o extraer un repositorio que contiene submódulos, estos no serán
desprotegido por defecto; el init y actualización los subcomandos mantendrán los submódulos marcados
hacia fuera y en la revisión apropiada en su árbol de trabajo.

Los submódulos se componen de una entrada de árbol llamada gitlink en el repositorio principal que
se refiere a un objeto de confirmación particular dentro del repositorio interno que está completamente
separar. Un registro en .gitmodules (ver módulos de git(5)) archivo en la raíz de la fuente
árbol asigna un nombre lógico al submódulo y describe la URL predeterminada del submódulo
será clonado de. El nombre lógico se puede utilizar para anular esta URL dentro de su
configuración del repositorio local (ver submódulo init).

Los submódulos no deben confundirse con los controles remotos, que son otros repositorios del mismo
proyecto; Los submódulos están diseñados para diferentes proyectos que le gustaría hacer parte de su
árbol de origen, mientras que la historia de los dos proyectos sigue siendo completamente independiente y
no puede modificar el contenido del submódulo desde dentro del proyecto principal. Si quieres
para fusionar los historiales del proyecto y querer tratar el todo agregado como un solo proyecto
a partir de ese momento, es posible que desee agregar un control remoto para el otro proyecto y usar el subárbol unir
estrategia, en lugar de tratar el otro proyecto como un submódulo. Directorios que provienen de
Ambos proyectos se pueden clonar y verificar como un todo si decide seguir esa ruta.

COMANDOS

add
Agregue el repositorio dado como un submódulo en la ruta dada al conjunto de cambios a ser
comprometido junto al proyecto actual: el proyecto actual se denomina
"superproyecto".

Esto requiere al menos un argumento: . El argumento opcional es el
ubicación relativa para que exista el submódulo clonado en el superproyecto. Si es
no se proporciona, se utiliza la parte "humanish" del repositorio de origen ("repo" para
"/ruta/a/repo.git" y "foo" para "host.xz: foo / .git"). El también se utiliza como
el nombre lógico del submódulo en sus entradas de configuración a menos que se utilice --name para especificar
un nombre lógico.

es la URL del repositorio de origen del nuevo submódulo. Esto puede ser
una URL absoluta, o (si comienza con ./ o ../), la ubicación relativa a la
repositorio de origen del superproyecto (tenga en cuenta que para especificar un repositorio foo.git
que se encuentra justo al lado de un superproyecto bar.git, tendrás que usar ../foo.git
en lugar de ./foo.git - como cabría esperar al seguir las reglas para URL relativas
- porque la evaluación de las URL relativas en Git es idéntica a la de las relativas
directorios). Si el superproyecto no tiene un origen configurado, el superproyecto
es su propio upstream autorizado y en su lugar se utiliza el directorio de trabajo actual.

es la ubicación relativa para que exista el submódulo clonado en el superproyecto.
Si no existe, entonces el submódulo se crea clonando desde la URL nombrada.
Si existe y ya es un repositorio de Git válido, entonces esto se agrega al
conjunto de cambios sin clonación. Este segundo formulario se proporciona para facilitar la creación de un nuevo
submódulo desde cero, y supone que el usuario luego empujará el submódulo a la
URL dada.

En cualquier caso, la URL proporcionada se registra en .gitmodules para que la utilicen los usuarios posteriores.
clonando el superproyecto. Si la URL se proporciona en relación con el superproyecto
repositorio, la presunción es el superproyecto y los repositorios de submódulos serán
se mantienen juntos en la misma ubicación relativa, y solo la URL del superproyecto debe
ser proporcionado: git-submodule localizará correctamente el submódulo usando la URL relativa
en .gitmodules.

estado
Muestra el estado de los submódulos. Esto imprimirá el SHA-1 de la marca actualmente
out commit para cada submódulo, junto con la ruta del submódulo y la salida de git
describir para el SHA-1. Cada SHA-1 tendrá el prefijo - si el submódulo no es
inicializado, + si la confirmación del submódulo actualmente desprotegido no coincide con el SHA-1
que se encuentra en el índice del repositorio que lo contiene y U si el submódulo se ha fusionado
conflictos.

Si se especifica --recursive, este comando se repetirá en submódulos anidados y
mostrar su estado también.

Si solo está interesado en cambios de los submódulos actualmente inicializados con
con respecto al compromiso registrado en el índice o el HEAD, estado-git(1) y diferencia git(1)
también proporcionará esa información (y también puede informar cambios en el trabajo de un submódulo
árbol).

init
Inicialice los submódulos registrados en el índice (que se agregaron y confirmaron
en otro lugar) copiando los nombres de los submódulos y las URL de .gitmodules a .git / config.
Opcional los argumentos limitan qué submódulos se inicializarán. También
copie el valor del submódulo. $ name.update en .git / config. La clave utilizada en .git / config
es un submódulo. $ nombre.url. Este comando no altera la información existente en
.git / config. Luego puede personalizar las URL de clonación del submódulo en .git / config para su
configuración local y proceda a la actualización del submódulo git; también puedes usar el submódulo git
actualizar --init sin el explícito init paso si no tiene la intención de personalizar
ubicaciones de submódulos.

deinir
Anule el registro de los submódulos dados, es decir, elimine toda la sección del submódulo. $ Nombre de
.git / config junto con su árbol de trabajo. Más llamadas a la actualización del submódulo git, git
submodule foreach y git submodule sync omitirá cualquier submódulo no registrado hasta
se inicializan de nuevo, así que utilice este comando si no desea tener un local
la comprobación del submódulo en su árbol de trabajo ya. Si realmente desea eliminar un
submódulo del repositorio y confirme ese uso git-rm(1) en cambio.

Si se especifica --force, el árbol de trabajo del submódulo se eliminará incluso si contiene
modificaciones locales.

actualización
Actualice los submódulos registrados para que coincidan con lo que espera el superproyecto mediante la clonación
faltan submódulos y se actualiza el árbol de trabajo de los submódulos. La "actualización" puede
hacerse de varias formas dependiendo de las opciones de la línea de comando y el valor de
submódulo. .update variable de configuración. Los procedimientos de actualización admitidos son:

caja
la confirmación registrada en el superproyecto se comprobará en el submódulo en un
CABEZA separada. Esto se hace cuando se da la opción --checkout o no se ofrece ninguna opción.
dado y submódulo. .update no está configurado, o si está configurado en caja.

Si se especifica --force, el submódulo será verificado (usando git checkout
--force si es apropiado), incluso si el compromiso especificado en el índice de la
que contiene el repositorio ya coincide con la confirmación extraída en el submódulo.

rebase
la rama actual del submódulo se volverá a basar en la confirmación registrada en
el superproyecto. Esto se hace cuando se da la opción --rebase o no se ofrece ninguna opción.
dado y submódulo. .update está configurado en rebase.

unir
la confirmación registrada en el superproyecto se fusionará con la rama actual en
el submódulo. Esto se hace cuando se da la opción --merge, o no se da ninguna opción,
y submódulo. .update está configurado en unir.

comando personalizado
comando de shell arbitrario que toma un solo argumento (el sha1 de la confirmación
registrado en el superproyecto) se ejecuta. Esto se hace cuando no se ofrece ninguna opción,
y submódulo. .update tiene la forma de !mando.

Cuando no se da ninguna opción y submódulo. .update está configurado en ninguna, el submódulo es
no actualizado.

Si el submódulo aún no está inicializado y solo desea usar la configuración como
almacenado en .gitmodules, puede inicializar automáticamente el submódulo con --init
.

Si se especifica --recursive, este comando se repetirá en los submódulos registrados,
y actualice los submódulos anidados dentro.

resumen
Muestra el resumen de la confirmación entre la confirmación dada (por defecto es HEAD) y el trabajo
árbol / índice. Para un submódulo en cuestión, una serie de confirmaciones en el submódulo entre
el compromiso del superproyecto dado y el índice o árbol de trabajo (cambiado por --cached)
son exhibidos. Si se da la opción --files, muestra la serie de confirmaciones en el submódulo
entre el índice del superproyecto y el árbol de trabajo del submódulo (este
opción no permite usar la opción --cached o proporcionar una confirmación explícita).

Usando la opción --submodule = log con diferencia git(1) también proporcionará esa información.

foreach
Evalúa un comando de shell arbitrario en cada submódulo extraído. El comando tiene
acceso a las variables $ name, $ path, $ sha1 y $ toplevel: $ name es el nombre del
sección de submódulo relevante en .gitmodules, $ ruta es el nombre del submódulo
directorio relativo al superproyecto, $ sha1 es el compromiso registrado en el
superproyecto, y $ toplevel es la ruta absoluta al nivel superior del superproyecto.
Cualquier submódulo definido en el superproyecto pero no extraído es ignorado por este
mando. A menos que se indique --quiet, foreach imprime el nombre de cada submódulo antes
evaluando el comando. Si se da --recursive, los submódulos se recorren de forma recursiva
(es decir, el comando de shell dado también se evalúa en submódulos anidados). Un no cero
el retorno del comando en cualquier submódulo hace que el procesamiento termine. Esto puede
ser anulado agregando || : hasta el final del comando.

Como ejemplo, el submódulo git foreach 'echo $ path `git rev-parse HEAD`' mostrará el
ruta y actualmente comprobado el compromiso para cada submódulo.

sincronizar
Sincroniza la configuración de la URL remota de los submódulos con el valor especificado en
.gitmodules. Solo afectará a aquellos submódulos que ya tienen una entrada de URL en
.git / config (ese es el caso cuando se inicializan o se agregan recientemente). Esto es
útil cuando las URL de los submódulos cambian en sentido ascendente y necesita actualizar su
repositorios en consecuencia.

"git submodule sync" sincroniza todos los submódulos mientras que "git submodule sync - A"
sincroniza sólo el submódulo "A".

Si se especifica --recursive, este comando se repetirá en los submódulos registrados,
y sincronizar los submódulos anidados dentro.

OPCIONES

-q, - silencioso
Imprima solo mensajes de error.

-b, - rama
Rama de repositorio para agregar como submódulo. El nombre de la sucursal se registra como
submódulo. .branch en .gitmodules para actualización --remote.

-f, --fuerza
Esta opción solo es válida para los comandos add, deinit y update. Al ejecutar agregar, permitir
agregando una ruta de submódulo que de otro modo se ignoraría. Al ejecutar deinit, el submódulo funciona
los árboles se eliminarán incluso si contienen cambios locales. Al ejecutar la actualización (solo
efectivo con el procedimiento de pago), deseche los cambios locales en los submódulos cuando
cambiar a un compromiso diferente; y siempre ejecute una operación de pago en el submódulo,
incluso si la confirmación que figura en el índice del repositorio que lo contiene coincide con la confirmación
verificado en el submódulo.

- en caché
Esta opción solo es válida para comandos de estado y resumen. Estos comandos normalmente
use la confirmación que se encuentra en el submódulo HEAD, pero con esta opción, la confirmación almacenada en
en su lugar, se utiliza el índice.

--archivos
Esta opción solo es válida para el comando de resumen. Este comando compara la confirmación en
el índice con el del submódulo HEAD cuando se usa esta opción.

-n, --límite-resumen
Esta opción solo es válida para el comando de resumen. Limite el tamaño del resumen (número de
confirmaciones mostradas en total). Dar 0 desactivará el resumen; un número negativo significa
ilimitado (el predeterminado). Este límite solo se aplica a los submódulos modificados. El tamaño es
siempre limitado a 1 para submódulos agregados / eliminados / modificados.

--remoto
Esta opción solo es válida para el comando de actualización. En lugar de utilizar el superproyecto
registrado SHA-1 para actualizar el submódulo, use el estado del submódulo
sucursal de seguimiento remoto. El control remoto utilizado es el control remoto de la sucursal (branch. .remoto),
por defecto al origen. La rama remota utilizó los valores predeterminados como maestra, pero el nombre de la rama
se puede anular configurando el submódulo. Opción .branch en .gitmodules
o .git / config (con .git / config teniendo prioridad).

Esto funciona para cualquiera de los procedimientos de actualización admitidos (--checkout, --rebase, etc.).
El único cambio es el origen del SHA-1 de destino. Por ejemplo, actualización de submódulo
--remote --merge fusionará los cambios de los submódulos ascendentes en los submódulos, mientras que
submodule update --merge fusionará los cambios de superproyecto gitlink en los submódulos.

Para garantizar un estado de rama de seguimiento actual, update --remote recupera el
repositorio remoto del submódulo antes de calcular el SHA-1. Si no quieres
fetch, debe usar la actualización del submódulo --remote --no-fetch.

Utilice esta opción para integrar los cambios del subproyecto anterior con su
HEAD actual del submódulo. Alternativamente, puede ejecutar git pull desde el submódulo,
que es equivalente excepto por el nombre de la rama remota: update --remote usa el
repositorio y submódulo ascendentes predeterminados. .branch, mientras que git pull usa el
rama del submódulo. .unir. Preferir submódulo. .rama si quieres
distribuya la rama ascendente predeterminada con el superproyecto y la rama. .unir
si desea una sensación más nativa mientras trabaja en el submódulo en sí.

-N, --no-buscar
Esta opción solo es válida para el comando de actualización. No recupere nuevos objetos del
sitio remoto.

--verificar
Esta opción solo es válida para el comando de actualización. Verifique el compromiso registrado en el
superproyecto en un HEAD separado en el submódulo. Este es el comportamiento predeterminado, el
El uso principal de esta opción es anular el submódulo. $ name.update cuando se establece en un valor
que no sea el pago. Si el submódulo clave. $ Name.update no está establecido explícitamente o
configurada para finalizar la compra, esta opción está implícita.

--unir
Esta opción solo es válida para el comando de actualización. Fusionar la confirmación registrada en el
superproyecto en la rama actual del submódulo. Si se da esta opción, el
HEAD del submódulo no se separará. Si un error de fusión impide este proceso,
tendrá que resolver los conflictos resultantes dentro del submódulo con el habitual
herramientas de resolución de conflictos. Si el submódulo clave. $ Name.update está configurado para fusionarse, esto
La opción está implícita.

--rebase
Esta opción solo es válida para el comando de actualización. Vuelva a basar la rama actual en el
compromiso registrado en el superproyecto. Si se da esta opción, HEAD del submódulo
no se desprenderá. Si un error de fusión impide este proceso, tendrá que
resolver estos fallos con git-rebase(1). Si el submódulo clave. $ Name.update se establece en
rebase, esta opción está implícita.

--en eso
Esta opción solo es válida para el comando de actualización. Inicializar todos los submódulos para los que
"git submodule init" no se ha llamado hasta ahora antes de la actualización.

--nombre
Esta opción solo es válida para el comando agregar. Establece el nombre del submódulo en el
una cadena dada en lugar de tomar su ruta de forma predeterminada. El nombre debe ser válido como directorio.
nombre y no puede terminar con un /.

--referencia
Esta opción solo es válida para agregar y actualizar comandos. Estos comandos a veces necesitan
para clonar un repositorio remoto. En este caso, esta opción se pasará al git-
clonar(1) comando.

NOTA: Hacer No utilice esta opción a menos que haya leído la nota para git-clon(1)
--Referencia y - opciones compartidas con cuidado.

--recursivo
Esta opción solo es válida para los comandos foreach, update, status y sync. atravesar
submódulos de forma recursiva. La operación se realiza no solo en los submódulos del
repositorio actual, sino también en cualquier submódulo anidado dentro de esos submódulos (y así sucesivamente).

--profundidad
Esta opción es válida para agregar y actualizar comandos. Crear un superficial clonar con un
historial truncado al número especificado de revisiones. Ver git-clon(1)

...
Rutas a los submódulos. Cuando se especifica, esto restringirá el comando para que solo opere
en los submódulos que se encuentran en las rutas especificadas. (Este argumento se requiere con agregar).

Use git-submodule en línea usando los servicios de onworks.net