ejemplo de clon de git

Nombre

git-clone: ​​clona un repositorio en un nuevo directorio

Sinopsis

git clone [--template=<template_directory>]
          [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
          [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>]
          [--dissociate] [--separate-git-dir <git dir>]
          [--depth <depth>] [--[no-]single-branch] [--no-tags]
          [--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules]
          [--[no-]remote-submodules] [--jobs <n>] [--sparse]
          [--filter=<filter>] [--] <repository>
          [<directory>]

Descripción

Clona un repositorio en un directorio recién creado, crea ramas de seguimiento remoto para cada rama en el repositorio clonado (visible usando git branch --remotes), y crea y desprotege una rama inicial que se bifurca desde la rama activa actualmente del repositorio clonado.

Después del clon, una llanura git fetch sin argumentos actualizará todas las ramas de seguimiento remoto, y un git pull sin argumentos, además, fusionará la rama maestra remota con la rama maestra actual, si la hubiera (esto no es cierto cuando se da “–single-branch”; ver más abajo).

Esta configuración predeterminada se logra mediante la creación de referencias a los cabezales de rama remotos en refs/remotes/origin y al inicializar remote.origin.url y remote.origin.fetch variables de configuración.

Opciones

-l

–local

Cuando el repositorio desde el que se va a clonar está en una máquina local, esta bandera pasa por alto el mecanismo de transporte normal “consciente de Git” y clona el repositorio haciendo una copia de HEAD y todo lo que se encuentra debajo de los directorios de objetos y referencias. Los archivos debajo .git/objects/ Los directorios están vinculados para ahorrar espacio cuando sea posible.

Si el repositorio se especifica como una ruta local (p. Ej., /path/to/repo), este es el predeterminado, y –local es esencialmente una operación no operativa. Si el repositorio se especifica como una URL, entonces esta bandera se ignora (y nunca usamos las optimizaciones locales). Especificando --no-local anulará el valor predeterminado cuando /path/to/repo se proporciona, utilizando el transporte Git regular en su lugar.

NOTA: esta operación puede competir con la modificación simultánea del repositorio de origen, similar a ejecutar cp -r src dst mientras modifica src.

–no enlaces duros

Forzar el proceso de clonación de un repositorio en un sistema de archivos local para copiar los archivos bajo el .git/objects directorio en lugar de utilizar enlaces duros. Esto puede ser conveniente si está intentando hacer una copia de seguridad de su repositorio.

-s

–compartido

Cuando el repositorio para clonar está en la máquina local, en lugar de usar enlaces físicos, configura automáticamente .git/objects/info/alternates para compartir los objetos con el repositorio de origen. El repositorio resultante comienza sin ningún objeto propio.

NOTA: esta es una operación posiblemente peligrosa; hacer no utilícelo a menos que sepa lo que hace. Si clona su repositorio usando esta opción y luego borra ramas (o usa cualquier otro comando de Git que haga que cualquier confirmación existente no esté referenciada) en el repositorio de origen, algunos objetos pueden dejar de tener referencias (o colgar). Estos objetos pueden eliminarse mediante operaciones normales de Git (como git commit) que llaman automáticamente git maintenance run --auto. (Ver mantenimiento de git[1].) Si estos objetos se eliminan y el repositorio clonado hace referencia a ellos, el repositorio clonado se dañará.

Tenga en cuenta que correr git repack sin el --local opción en un repositorio clonado con --shared copiará objetos del repositorio de origen en un paquete en el repositorio clonado, eliminando el ahorro de espacio en disco de clone --shared. Sin embargo, es seguro correr git gc, que usa el --local opción por defecto.

Si desea romper la dependencia de un repositorio clonado con --shared en su repositorio de origen, simplemente puede ejecutar git repack -a para copiar todos los objetos del repositorio de origen en un paquete en el repositorio clonado.

–referencia[-if-able]

Si el repositorio de referencia está en la máquina local, configure automáticamente .git/objects/info/alternates para obtener objetos del repositorio de referencia. El uso de un repositorio ya existente como alternativa requerirá que se copien menos objetos del repositorio que se está clonando, lo que reducirá los costos de almacenamiento local y de red. Al usar el --reference-if-able, un directorio no existente se omite con una advertencia en lugar de abortar el clon.

NOTA: consulte la NOTA para --shared opción, y también la --dissociate opción.

–disociar

Pedir prestados los objetos de los repositorios de referencia especificados con el --reference opciones solo para reducir la transferencia de red y dejar de tomar prestado de ellas después de realizar un clon mediante la realización de las copias locales necesarias de los objetos prestados. Esta opción también se puede usar cuando se clona localmente desde un repositorio que ya toma prestados objetos de otro repositorio; el nuevo repositorio tomará prestados objetos del mismo repositorio, y esta opción se puede usar para detener el préstamo.

-q

–tranquilo

Opere silenciosamente. El progreso no se informa al flujo de errores estándar.

-v

–verboso

Ejecutar prolijamente. No afecta el informe del estado de progreso al flujo de errores estándar.

–Progreso

El estado de progreso se informa en el flujo de error estándar de forma predeterminada cuando está conectado a un terminal, a menos que --quiet está especificado. Esta bandera fuerza el estado de progreso incluso si el flujo de error estándar no se dirige a un terminal.

–server-option =

Transmita la cadena dada al servidor cuando se comunique usando el protocolo versión 2. La cadena dada no debe contener un carácter NUL o LF. El manejo del servidor de las opciones del servidor, incluidas las desconocidas, es específico del servidor. Cuando varios --server-option=<option> se dan, todos se envían al otro lado en el orden indicado en la línea de comando.

-norte

–no pago

No se realiza ninguna comprobación de HEAD después de que se completa el clon.

–desnudo

Hacer una bare Repositorio de Git. Es decir, en lugar de crear <directory> y colocar los archivos administrativos en <directory>/.git, hacer el <directory> en sí mismo el $GIT_DIR. Esto obviamente implica la --no-checkout porque no hay ningún lugar para consultar el árbol de trabajo. Además, los cabezales de rama en el control remoto se copian directamente a los cabezales de rama locales correspondientes, sin mapearlos a refs/remotes/origin/. Cuando se utiliza esta opción, no se crean ramas de seguimiento remoto ni las variables de configuración relacionadas.

–escaso

Inicialice el archivo de pago disperso para que el directorio de trabajo comience solo con los archivos en la raíz del repositorio. El archivo de pago disperso se puede modificar para hacer crecer el directorio de trabajo según sea necesario.

–filter =

Utilice la función de clonación parcial y solicite que el servidor envíe un subconjunto de objetos alcanzables de acuerdo con un filtro de objeto determinado. Cuando usas --filter, el suministrado <filter-spec> se utiliza para el filtro de clonación parcial. Por ejemplo, --filter=blob:none filtrará todos los blobs (contenido del archivo) hasta que Git los necesite. También, --filter=blob:limit=<size> filtrará todas las manchas de tamaño al menos <size>. Para obtener más detalles sobre las especificaciones de los filtros, consulte la --filter opción en git-rev-list[1].

–espejo

Configure un espejo del repositorio de origen. Esto implica --bare. En comparación con --bare, --mirror no solo asigna las ramas locales de la fuente a las ramas locales del objetivo, sino que asigna todas las referencias (incluidas las ramas de seguimiento remoto, notas, etc.) y establece una configuración de especificación de referencia de modo que todas estas referencias se sobrescriban con un git remote update en el repositorio de destino.

-o

–origen

En lugar de usar el nombre remoto origin para realizar un seguimiento del repositorio ascendente, utilice <name>. Anulaciones clone.defaultRemoteName de la configuración.

-B

–rama

En lugar de apuntar el HEAD recién creado a la rama apuntada por el HEAD del repositorio clonado, apunte a <name> rama en su lugar. En un repositorio no desnudo, esta es la rama que se desprotegerá. --branch también puede tomar etiquetas y separar el HEAD en esa confirmación en el repositorio resultante.

-u

–upload-pack

Cuando se proporciona, y se accede al repositorio desde el que se clona a través de ssh, esto especifica una ruta no predeterminada para el comando que se ejecuta en el otro extremo.

–template =

Especifique el directorio desde el que se utilizarán las plantillas; (Consulte la sección “DIRECTORIO DE PLANTILLAS” de git-init[1].)

-C =

–config =

Establezca una variable de configuración en el repositorio recién creado; esto entra en vigor inmediatamente después de que se inicializa el repositorio, pero antes de que se obtenga el historial remoto o se extraiga cualquier archivo. La clave tiene el mismo formato que el esperado por git-config[1] (p.ej, core.eol=true). Si se dan varios valores para la misma clave, cada valor se escribirá en el archivo de configuración. Esto hace que sea seguro, por ejemplo, agregar especificaciones de referencia de recuperación adicionales al control remoto de origen.

Debido a las limitaciones de la implementación actual, algunas variables de configuración no entran en vigor hasta después de la obtención y el pago iniciales. Las variables de configuración que se sabe que no tienen efecto son: remote.<name>.mirror y remote.<name>.tagOpt. Utilice el correspondiente --mirror y --no-tags opciones en su lugar.

–profundidad

Crear un shallow clonar con un historial truncado al número especificado de confirmaciones. Implica --single-branch a no ser que --no-single-branch Se da para buscar las historias cerca de las puntas de todas las ramas. Si desea clonar submódulos superficialmente, también pase --shallow-submodules.

–shallow-since =

Crea un clon superficial con un historial después del tiempo especificado.

–shallow-exclude =

Cree un clon superficial con un historial, excluyendo las confirmaciones accesibles desde una rama o etiqueta remota especificada. Esta opción se puede especificar varias veces.

-[no-]rama única

Clone solo el historial que conduce a la punta de una sola rama, ya sea especificado por el --branch opción o el control remoto de la sucursal principal HEAD apunta a. Las búsquedas adicionales en el repositorio resultante solo actualizarán la rama de seguimiento remoto para la rama que se utilizó esta opción para la clonación inicial. Si el HEAD en el control remoto no apuntó a ninguna rama cuando --single-branch clon, no se crea ninguna rama de seguimiento remoto.

–No etiquetas

No clone ninguna etiqueta y configure remote.<remote>.tagOpt=--no-tags en la configuración, asegurando que el futuro git pull y git fetch las operaciones no seguirán ninguna etiqueta. Las recuperaciones de etiquetas explícitas posteriores seguirán funcionando (consulte git-fetch[1]).

Puede utilizarse junto con --single-branch para clonar y mantener una rama sin más referencias que una sola rama clonada. Esto es útil, por ejemplo, para mantener clones mínimos de la rama predeterminada de algún repositorio para la indexación de búsqueda.

–recurse-submodules[=<pathspec>]

Una vez creado el clon, inicialice y clone los submódulos dentro de la especificación de ruta proporcionada. Si no se proporciona la especificación de ruta, todos los submódulos se inicializan y clonan. Esta opción se puede dar varias veces para las especificaciones de ruta que constan de varias entradas. El clon resultante tiene submodule.active establecido en la especificación de ruta proporcionada, o “.” (es decir, todos los submódulos) si no se proporciona una especificación de ruta.

Los submódulos se inicializan y clonan usando su configuración predeterminada. Esto es equivalente a correr git submodule update --init --recursive <pathspec> inmediatamente después de que finalice el clon. Esta opción se ignora si el repositorio clonado no tiene un árbol de trabajo / pago (es decir, si alguno de --no-checkout/-n, --bare, o --mirror es dado)

-[no-]submódulos poco profundos

Todos los submódulos que se clonan serán poco profundos con una profundidad de 1.

-[no-]submódulos remotos

Todos los submódulos que se clonan usarán el estado de la rama de seguimiento remoto del submódulo para actualizar el submódulo, en lugar del SHA-1 registrado del superproyecto. Equivalente a pasar --remote para git submodule update.

–separate-git-dir =

En lugar de colocar el repositorio clonado donde se supone que debe estar, coloque el repositorio clonado en el directorio especificado, luego cree un enlace simbólico Git independiente del sistema de archivos allí. El resultado es que el repositorio de Git se puede separar del árbol de trabajo.

-j

–trabajos

El número de submódulos obtenidos al mismo tiempo. Por defecto es submodule.fetchJobs opción.

El repositorio (posiblemente remoto) desde el que clonar. Consulte la sección URL de GIT a continuación para obtener más información sobre cómo especificar repositorios.

El nombre de un nuevo directorio para clonar. La parte “humanista” del repositorio de origen se utiliza si no se proporciona un directorio explícitamente (repo por /path/to/repo.git y foo por host.xz:foo/.git). La clonación en un directorio existente solo se permite si el directorio está vacío.

URL de Git

En general, las URL contienen información sobre el protocolo de transporte, la dirección del servidor remoto y la ruta al repositorio. Dependiendo del protocolo de transporte, parte de esta información puede estar ausente.

Git es compatible con los protocolos ssh, git, http y https (además, se pueden usar ftp y ftps para la búsqueda, pero esto es ineficiente y obsoleto; no lo use).

El transporte nativo (es decir, git: // URL) no realiza autenticación y debe usarse con precaución en redes no seguras.

Se pueden usar las siguientes sintaxis con ellos:

• ssh: //[[email protected]]host.xz[:port]/ruta/a/repo.git/

• git: //host.xz[:port]/ruta/a/repo.git/

• http[s]: //host.xz[:port]/ruta/a/repo.git/

• ftp[s]: //host.xz[:port]/ruta/a/repo.git/

También se puede utilizar una sintaxis alternativa similar a scp con el protocolo ssh:

• [[email protected]]host.xz: ruta / a / repo.git /

Esta sintaxis solo se reconoce si no hay barras inclinadas antes de los primeros dos puntos. Esto ayuda a diferenciar una ruta local que contiene dos puntos. Por ejemplo, la ruta local foo:bar podría especificarse como una ruta absoluta o ./foo:bar para evitar ser malinterpretado como una URL ssh.

Los protocolos ssh y git además admiten la expansión de ~ nombre de usuario:

• ssh: //[[email protected]]host.xz[:port]/ ~[user]/ruta/a/repo.git/

• git: //host.xz[:port]/ ~[user]/ruta/a/repo.git/

• [[email protected]]host.xz: / ~[user]/ruta/a/repo.git/

Para los repositorios locales, también compatibles con Git de forma nativa, se pueden utilizar las siguientes sintaxis:

• /ruta/a/repo.git/

• archivo: ///path/to/repo.git/

Estas dos sintaxis son en su mayoría equivalentes, excepto que la primera implica la opción –local.

git clone, git fetch y git pull, pero no git push, también aceptará un archivo de paquete adecuado. Ver git-bundle[1].

Cuando Git no sabe cómo manejar un determinado protocolo de transporte, intenta usar el remote-<transport> ayudante remoto, si existe. Para solicitar explícitamente un ayudante remoto, se puede utilizar la siguiente sintaxis:

• ::

dónde

        [url "<actual url base>"]
                insteadOf = <other url base>

        [url "git://git.host.xz/"]
                insteadOf = host.xz:/path/to/
                insteadOf = work:

        [url "<actual url base>"]
                pushInsteadOf = <other url base>

        [url "ssh://example.org/"]
                pushInsteadOf = git://example.org/