- SINOPSIS
- DESCRIPCIÓN
- OPCIONES
- COMANDOS DE GIT
- COMANDOS DE ALTO NIVEL (PORCELANA)
- COMANDOS DE BAJO NIVEL (PLUMBING)
- GUÍAS
- REPOSITORIO, INTERFACES DE COMANDOS Y ARCHIVOS
- FORMATOS DE ARCHIVOS, PROTOCOLOS Y OTRAS INTERFACES PARA DESARROLLADORES
- MECANISMO DE CONFIGURACIÓN
- TERMINOLOGÍA DE IDENTIFICADORES
- IDENTIFICADORES SIMBÓLICOS
- ESTRUCTURA DE ARCHIVOS/DIRECTORIOS
- TERMINOLOGÍA
- VARIABLES DE ENTORNO
- DISCUSIÓN
- SEGURIDAD
- DOCUMENTACIÓN ADICIONAL
- AUTORES
- INFORMES DE ERRORES
- VER TAMBIÉN
- GIT
- NOTAS
git - el rastreador de contenido estúpido
SINOPSIS
git [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>]
[--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
[-p | --paginate | -P | --no-pager] [--no-replace-objects] [--no-lazy-fetch]
[--no-optional-locks] [--no-advice] [--bare] [--git-dir=<path>]
[--work-tree=<path>] [--namespace=<name>] [--config-env=<name>=<envvar>]
<comando> [<argumentos>]
DESCRIPCIÓN
Git es un sistema de control de versiones distribuido, rápido y escalable con un conjunto de comandos inusualmente rico que proporciona operaciones de alto nivel y acceso completo a los internos.
Consulte gittutorial(7) para comenzar y luego consulte giteveryday(7) para un conjunto mínimo útil de comandos. El Manual del usuario de Git[1] tiene una introducción más detallada.
Después de que domine los conceptos básicos, puede volver a esta página para aprender qué comandos ofrece Git. Puede obtener más información sobre los comandos individuales de Git con "git help comando". La página de manual gitcli(7) le brinda una descripción general de la sintaxis del comando de línea de comandos.
Se puede ver una copia formateada e hipervinculada de la última documentación de Git en https://git.github.io/htmldocs/git.html o https://git-scm.com/docs.
OPCIONES
-v, --version
Imprime la versión del conjunto de herramientas Git de la que proviene el programa git.
Esta opción se convierte internamente en git version ... y acepta las mismas opciones que el comando git-version(1). Si también se proporciona --help, tiene prioridad sobre --version.
-h, --help
Imprime la sinopsis y una lista de los comandos más utilizados. Si se proporciona la opción --all o -a, se imprimen todos los comandos disponibles. Si se nombra un comando de Git, esta opción abrirá la página de manual para ese comando.
Hay otras opciones disponibles para controlar cómo se muestra la página de manual. Consulte git-help(1) para obtener más información, porque git --help ... se convierte internamente en git help ....
-C <path>
Ejecute como si git se hubiera iniciado en
Esta opción afecta las opciones que esperan un nombre de ruta, como --git-dir y --work-tree, de modo que sus interpretaciones de los nombres de ruta se realizarían en relación con el directorio de trabajo causado por la opción -C. Por ejemplo, las siguientes invocaciones son equivalentes:
git --git-dir=a.git --work-tree=b -C c status
git --git-dir=c/a.git --work-tree=c/b status
-c <name>=<value>
Pase un parámetro de configuración al comando. El valor dado anulará los valores de los archivos de configuración. Se espera que
Tenga en cuenta que omitir el = en git -c foo.bar ... está permitido y establece foo.bar en el valor booleano true (al igual que [foo]bar lo haría en un archivo de configuración). Incluir el signo igual pero con un valor vacío (como en git -c foo.bar= ...) establece foo.bar en una cadena vacía, lo que git config --type=bool convertirá en false.
^ -config-env=<nombre>=<variable_entorno>
Similar a -c <nombre>=<valor>, asigna un valor a la variable de configuración <nombre>, donde <variable_entorno> es el nombre de una variable de entorno de la que se obtendrá el valor. A diferencia de -c, no hay un atajo para establecer directamente el valor en una cadena vacía; en su lugar, la propia variable de entorno debe establecerse en una cadena vacía. Es un error si <variable_entorno> no existe en el entorno. <variable_entorno> no puede contener un signo igual para evitar la ambigüedad con <nombre> que lo contenga.
Esto es útil en casos en los que desea pasar opciones de configuración transitorias a git, pero lo está haciendo en sistemas operativos donde otros procesos pueden leer su línea de comandos (por ejemplo, /proc/self/cmdline), pero no su entorno (por ejemplo, /proc/self/environ). Este comportamiento es el predeterminado en Linux, pero puede no serlo en su sistema.
Tenga en cuenta que esto puede agregar seguridad para variables como http.extraHeader donde la información confidencial es parte del valor, pero no, por ejemplo, url.<base>.insteadOf donde la información confidencial puede ser parte de la clave.
^ -exec-path[=<ruta>]
Ruta a donde están instalados sus programas principales de Git. Esto también se puede controlar configurando la variable de entorno GIT_EXEC_PATH. Si no se proporciona ninguna ruta, git imprimirá la configuración actual y luego saldrá.
^ -html-path
Imprime la ruta, sin barra diagonal final, donde está instalada la documentación HTML de Git y sale.
^ -man-path
Imprime la ruta de búsqueda (manpath, consulte man(1)) para las páginas de manual de esta versión de Git y sale.
^ -info-path
Imprime la ruta donde están instalados los archivos de información que documentan esta versión de Git y sale.
^ p, --paginate
Canaliza toda la salida a less (o, si está configurado, $PAGER) si la salida estándar es una terminal. Esto anula las opciones de configuración pager.<cmd> (vea la sección "Mecanismo de configuración" a continuación).
^ P, --no-pager
No canalice la salida de Git a un paginador.
^ -git-dir=<ruta>
Establece la ruta al repositorio (directorio .git). Esto también se puede controlar configurando la variable de entorno GIT_DIR. Puede ser una ruta absoluta o una ruta relativa al directorio de trabajo actual.
Especificar la ubicación del directorio .git utilizando esta opción (o la variable de entorno GIT_DIR) desactiva el descubrimiento del repositorio que intenta encontrar un directorio con un subdirectorio .git (que es cómo se descubre el repositorio y el nivel superior del árbol de trabajo) y le dice a Git que se encuentra en el nivel superior del árbol de trabajo. Si no está en el directorio de nivel superior del árbol de trabajo, debe indicarle a Git dónde está el nivel superior del árbol de trabajo, con la opción --work-tree=<ruta> (o la variable de entorno GIT_WORK_TREE).
Si solo quieres ejecutar git como si se hubiera iniciado en
--work-tree=<path>
Establece la ruta al árbol de trabajo. Puede ser una ruta absoluta o una ruta relativa al directorio de trabajo actual. Esto también se puede controlar configurando la variable de entorno GIT_WORK_TREE y la variable de configuración core.worktree (consulta core.worktree en gitconfig(1) para obtener una discusión más detallada).
--namespace=<path>
Establece el espacio de nombres de Git. Consulta gitnamespaces(7) para obtener más detalles. Equivalente a establecer la variable de entorno GIT_NAMESPACE.
--bare
Trata el repositorio como un repositorio bare. Si la variable de entorno GIT_DIR no está establecida, se establece en el directorio de trabajo actual.
--no-replace-objects
No uses referencias de reemplazo para reemplazar los objetos de Git. Esto es equivalente a exportar la variable de entorno GIT_NO_REPLACE_OBJECTS con cualquier valor. Consulta git-replace(1) para obtener más información.
--no-lazy-fetch
No obtengas los objetos faltantes del repositorio promisor a pedido. Útil junto con git cat-file -e para ver si el objeto está disponible localmente. Esto es equivalente a establecer la variable de entorno GIT_NO_LAZY_FETCH en 1.
--no-optional-locks
No realices operaciones opcionales que requieran bloqueos. Esto es equivalente a establecer GIT_OPTIONAL_LOCKS en 0.
--no-advice
Desactiva la impresión de todos los consejos.
--literal-pathspecs
Trata las especificaciones de ruta literalmente (es decir, sin comodines, sin magia de especificación de ruta). Esto es equivalente a establecer la variable de entorno GIT_LITERAL_PATHSPECS en 1.
--glob-pathspecs
Agrega magia "glob" a todas las especificaciones de ruta. Esto es equivalente a establecer la variable de entorno GIT_GLOB_PATHSPECS en 1. Se puede desactivar el uso de comodines en especificaciones de ruta individuales mediante la magia de especificación de ruta ":(literal)".
--noglob-pathspecs
Agrega magia "literal" a todas las especificaciones de ruta. Esto es equivalente a establecer la variable de entorno GIT_NOGLOB_PATHSPECS en 1. Se puede habilitar el uso de comodines en especificaciones de ruta individuales mediante la magia de especificación de ruta ":(glob)".
--icase-pathspecs
Agrega magia "icase" a todas las especificaciones de ruta. Esto es equivalente a establecer la variable de entorno GIT_ICASE_PATHSPECS en 1.
--list-cmds=<group>[,<group>...]
Lista los comandos por grupo. Esta es una opción interna/experimental y puede cambiar o eliminarse
en el futuro. Los grupos admitidos son: builtins, parseopt (comandos integrados que usan
parse-options), main (todos los comandos en el directorio libexec), others (todos los demás comandos en $PATH
que tienen el prefijo git-), list-
--attr-source=<tree-ish>
Lee los atributos de Git desde
COMANDOS DE GIT
Dividimos Git en comandos de alto nivel ("porcelain") y comandos de bajo nivel ("plumbing").
COMANDOS DE ALTO NIVEL (PORCELANA)
Separamos los comandos de porcelana en los comandos principales y algunas utilidades de usuario auxiliares.
Comandos principales de porcelana
git-add(1)
Agrega el contenido de un archivo al índice.
git-am(1)
Aplica una serie de parches desde un buzón.
git-archive(1)
Crea un archivo de archivos desde un árbol con nombre.
git-backfill(1)
Descarga los objetos faltantes en un clon parcial.
git-bisect(1)
Usa la búsqueda binaria para encontrar el compromiso que introdujo un error.
git-branch(1)
Lista, crea o elimina ramas.
git-bundle(1)
Mueve objetos y referencias mediante un archivo.
git-checkout(1)
Cambia de rama o restaura archivos del árbol de trabajo.
git-cherry-pick(1)
Aplica los cambios introducidos por algunos compromisos existentes.
git-citool(1)
Alternativa gráfica a git-commit.
git-clean(1)
Elimina los archivos no rastreados del árbol de trabajo.
git-clone(1)
Clona un repositorio en un nuevo directorio.
git-commit(1)
Registra los cambios en el repositorio.
git-describe(1)
Asigna a un objeto un nombre legible por humanos basado en una referencia disponible.
git-diff(1)
Muestra los cambios entre compromisos, un compromiso y el árbol de trabajo, etc.
git-fetch(1)
Descarga objetos y referencias de otro repositorio.
git-format-patch(1)
Prepara parches para el envío por correo electrónico.
git-gc(1)
Limpia los archivos innecesarios y optimiza el repositorio local.
git-grep(1)
Imprime las líneas que coinciden con un patrón.
git-gui(1)
Una interfaz gráfica portátil para Git.
git-init(1)
Crea un repositorio Git vacío o reinicializa uno existente.
git-log(1)
Muestra los registros de confirmación.
git-maintenance(1)
Ejecuta tareas para optimizar los datos del repositorio Git.
git-merge(1)
Une dos o más historias de desarrollo.
git-mv(1)
Mueve o cambia el nombre de un archivo, un directorio o un enlace simbólico.
git-notes(1)
Agrega o inspecciona las notas de los objetos.
git-pull(1)
Obtiene de y se integra con otro repositorio o una rama local.
git-push(1)
Actualiza las referencias remotas junto con los objetos asociados.
git-range-diff(1)
Compara dos rangos de compromisos (por ejemplo, dos versiones de una rama).
git-rebase(1)
Vuelve a aplicar los compromisos sobre otra punta base.
git-reset(1)
Restablece el HEAD actual al estado especificado.
git-restore(1)
Restaura los archivos del árbol de trabajo.
git-revert(1)
Revierte algunos compromisos existentes.
git-rm(1)
Elimina archivos del árbol de trabajo y del índice.
git-shortlog(1)
Resume la salida de git log.
git-show(1)
Muestra varios tipos de objetos.
git-sparse-checkout(1)
Reduce tu árbol de trabajo a un subconjunto de archivos rastreados.
git-stash(1)
Guarda los cambios en un directorio de trabajo sucio.
git-status(1)
Muestra el estado del árbol de trabajo.
git-submodule(1)
Inicializa, actualiza o inspecciona los submódulos.
git-switch(1)
Cambia de rama.
git-tag(1)
Crea, lista, elimina o verifica un objeto de etiqueta firmado con GPG.
git-worktree(1)
Administra múltiples árboles de trabajo.
gitk(1)
El navegador del repositorio Git.
scalar(1)
Una herramienta para administrar grandes repositorios Git.
Comandos auxiliares
Manipuladores:
git-config(1)
Obtiene y establece las opciones del repositorio o globales.
git-fast-export(1)
Exportador de datos de Git.
git-fast-import(1)
Backend para importadores de datos Git rápidos.
git-filter-branch(1)
Reescribe ramas.
git-mergetool(1)
Ejecuta herramientas de resolución de conflictos de fusión para resolver conflictos de fusión.
git-pack-refs(1)
Empaqueta cabezales y etiquetas para un acceso eficiente al repositorio.
git-prune(1)
Elimina todos los objetos inalcanzables de la base de datos de objetos.
git-reflog(1)
Administra la información del reflog.
git-refs(1)
Acceso de bajo nivel a las referencias.
git-remote(1)
Administra el conjunto de repositorios rastreados.
git-repack(1)
Empaqueta objetos desempaquetados en un repositorio.
git-replace(1)
Crea, lista y elimina referencias para reemplazar objetos.
Interrogadores:
git-annotate(1)
Anota las líneas de archivo con información del commit.
git-blame(1)
Muestra qué revisión y autor modificaron por última vez cada línea de un archivo.
git-bugreport(1)
Recopila información para que el usuario presente un informe de errores.
git-count-objects(1)
Cuenta el número de objetos desempaquetados y su consumo de disco.
git-diagnose(1)
Genera un archivo zip de información de diagnóstico.
git-difftool(1)
Muestra los cambios utilizando herramientas de diferencias comunes.
git-fsck(1)
Verifica la conectividad y la validez de los objetos en la base de datos.
git-help(1)
Muestra información de ayuda sobre Git.
git-instaweb(1)
Navega instantáneamente por tu repositorio de trabajo en gitweb.
git-merge-tree(1)
Realiza la fusión sin tocar el índice ni el árbol de trabajo.
git-rerere(1)
Reutiliza la resolución registrada de fusiones conflictivas.
git-show-branch(1)
Muestra las ramas y sus commits.
git-verify-commit(1)
Verifica la firma GPG de los commits.
git-verify-tag(1)
Verifica la firma GPG de las etiquetas.
git-version(1)
Muestra la información de la versión de Git.
git-whatchanged(1)
Muestra los registros con las diferencias que introduce cada commit.
gitweb(1)
Interfaz web de Git (frontend web para repositorios Git).
Interacción con otros
Estos comandos sirven para interactuar con SCM externos y con otras personas a través de parches por correo electrónico.
git-archimport(1)
Importa un repositorio GNU Arch a Git.
git-cvsexportcommit(1)
Exporta un único commit a un checkout de CVS.
git-cvsimport(1)
Rescata tus datos de otro SCM que la gente adora odiar.
git-cvsserver(1)
Un emulador de servidor CVS para Git.
git-imap-send(1)
Envía una colección de parches desde stdin a una carpeta IMAP.
git-p4(1)
Importa y envía a repositorios Perforce.
git-quiltimport(1)
Aplica un conjunto de parches de quilt a la rama actual.
git-request-pull(1)
Genera un resumen de los cambios pendientes.
git-send-email(1)
Envía una colección de parches como correos electrónicos.
git-svn(1)
Operación bidireccional entre un repositorio Subversion y Git.
Restablecer, restaurar y revertir
Existen tres comandos con nombres similares: git reset, git restore y git revert.
git-revert(1) se utiliza para crear un nuevo commit que revierte los cambios realizados por otros commits.
git-restore(1) se utiliza para restaurar archivos en el árbol de trabajo desde el índice o desde otro commit. Este comando no actualiza tu rama. El comando también se puede utilizar para restaurar archivos en el índice desde otro commit.
git-reset(1) se utiliza para actualizar tu rama, moviendo la punta para agregar o eliminar commits de la rama. Esta operación cambia el historial de commits.
git reset también se puede usar para restaurar el índice, lo que se superpone a git restore.
COMANDOS DE BAJO NIVEL (PLUMBING)
Aunque Git incluye su propia capa de porcelana, sus comandos de bajo nivel son suficientes para admitir el desarrollo de porcelanas alternativas. Los desarrolladores de dichas porcelanas pueden comenzar leyendo sobre git-update-index(1) y git-read-tree(1).
La interfaz (entrada, salida, conjunto de opciones y la semántica) de estos comandos de bajo nivel está diseñada para ser mucho más estable que los comandos de nivel de porcelana, porque estos comandos están diseñados principalmente para uso en scripts. La interfaz de los comandos de porcelana, por otro lado, está sujeta a cambios para mejorar la experiencia del usuario final.
La siguiente descripción divide los comandos de bajo nivel en comandos que manipulan objetos (en el repositorio, el índice y el árbol de trabajo), comandos que interrogan y comparan objetos, y comandos que mueven objetos y referencias entre repositorios.
Comandos de manipulación
git-apply(1)
Aplica un parche a archivos y/o al índice.
git-checkout-index(1)
Copia archivos del índice al árbol de trabajo.
git-commit-graph(1)
Escribe y verifica los archivos git-graph.
git-commit-tree(1)
Crea un nuevo objeto de commit.
git-hash-object(1)
Calcula el ID del objeto y, opcionalmente, crea un objeto a partir de un archivo.
git-index-pack(1)
Crea un archivo de índice de paquete para un archivo de paquete existente.
git-merge-file(1)
Ejecuta una fusión de archivos de tres vías.
git-merge-index(1)
Ejecuta una fusión para los archivos que necesitan fusionarse.
git-mktag(1)
Crea un objeto de etiqueta con validación adicional.
git-mktree(1)
Crea un objeto de árbol a partir del texto con formato ls-tree.
git-multi-pack-index(1)
Escribe y verifica los índices de múltiples paquetes.
git-pack-objects(1)
Crea un archivo de paquete de objetos.
git-prune-packed(1)
Elimina objetos adicionales que ya están en los archivos de paquete.
git-read-tree(1)
Lee la información del árbol en el índice.
git-replay(1)
EXPERIMENTAL: Reorganiza los commits en una nueva base, también funciona con repositorios bare.
git-symbolic-ref(1)
Lee, modifica y elimina referencias simbólicas.
git-unpack-objects(1)
Desempaqueta objetos de un archivo de paquete.
git-update-index(1)
Registra el contenido del archivo en el árbol de trabajo en el índice.
git-update-ref(1)
Actualiza el nombre del objeto almacenado en una referencia de forma segura.
git-write-tree(1)
Crea un objeto de árbol a partir del índice actual.
Comandos de interrogación
git-cat-file(1)
Proporciona el contenido o los detalles de los objetos del repositorio.
git-cherry(1)
Encuentra commits que aún no se han aplicado a la rama principal.
git-diff-files(1)
Compara archivos en el árbol de trabajo y el índice.
git-diff-index(1)
Compara un árbol con el árbol de trabajo o el índice.
git-diff-pairs(1)
Compara el contenido y el modo de los pares de blobs proporcionados.
git-diff-tree(1)
Compara el contenido y el modo de los blobs que se encuentran a través de dos objetos de árbol.
git-for-each-ref(1)
Muestra información sobre cada referencia.
git-for-each-repo(1)
Ejecuta un comando Git en una lista de repositorios.
git-get-tar-commit-id(1)
Extrae el ID del commit de un archivo creado utilizando git-archive.
git-ls-files(1)
Muestra información sobre los archivos en el índice y el árbol de trabajo.
git-ls-remote(1)
Lista las referencias en un repositorio remoto.
git-ls-tree(1)
Lista el contenido de un objeto de árbol.
git-merge-base(1)
Encuentra los ancestros comunes más adecuados para una fusión.
git-name-rev(1)
Encuentra nombres simbólicos para las revisiones dadas.
git-pack-redundant(1)
Encuentra archivos de paquete redundantes.
git-rev-list(1)
Lista los objetos de confirmación en orden cronológico inverso.
git-rev-parse(1)
Selecciona y manipula los parámetros.
git-show-index(1)
Muestra el índice de archivo empaquetado.
git-show-ref(1)
Lista las referencias en un repositorio local.
git-unpack-file(1)
Crea un archivo temporal con el contenido de un blob.
git-var(1)
Muestra una variable lógica de Git.
git-verify-pack(1)
Valida los archivos de archivo de Git empaquetados.
En general, los comandos de interrogación no modifican los archivos en el árbol de trabajo.
Sincronización de repositorios
git-daemon(1)
Un servidor muy sencillo para repositorios Git.
git-fetch-pack(1)
Recibe los objetos faltantes de otro repositorio.
git-http-backend(1)
Implementación del lado del servidor de Git a través de HTTP.
git-send-pack(1)
Envía objetos a través del protocolo Git a otro repositorio.
git-update-server-info(1)
Actualiza el archivo de información auxiliar para ayudar a los servidores "tontos".
Los siguientes son comandos auxiliares utilizados por los anteriores; normalmente, los usuarios finales no los utilizan directamente.
git-http-fetch(1)
Descarga de un repositorio Git remoto a través de HTTP.
git-http-push(1)
Envía objetos a través de HTTP/DAV a otro repositorio.
git-receive-pack(1)
Recibe lo que se envía al repositorio.
git-shell(1)
Shell de inicio de sesión restringido para el acceso SSH solo para Git.
git-upload-archive(1)
Envía el archivo a git-archive.
git-upload-pack(1)
Envía objetos empaquetados de vuelta a git-fetch-pack.
Comandos auxiliares internos
Estos son comandos auxiliares internos utilizados por otros comandos; normalmente, los usuarios finales no los utilizan directamente.
git-check-attr(1)
Muestra la información de gitattributes.
git-check-ignore(1)
Depura los archivos gitignore / exclude.
git-check-mailmap(1)
Muestra los nombres y direcciones de correo electrónico canónicos de los contactos.
git-check-ref-format(1)
Asegura que el nombre de una referencia esté bien formado.
git-column(1)
Muestra los datos en columnas.
git-credential(1)
Recupera y almacena las credenciales del usuario.
git-credential-cache(1)
Auxiliar para almacenar temporalmente las contraseñas en la memoria.
git-credential-store(1)
Auxiliar para almacenar las credenciales en el disco.
git-fmt-merge-msg(1)
Produce un mensaje de confirmación de fusión.
git-hook(1)
Ejecuta los hooks de Git.
git-interpret-trailers(1)
Agrega o analiza información estructurada en los mensajes de confirmación.
git-mailinfo(1)
Extrae el parche y la autoría de un solo mensaje de correo electrónico.
git-mailsplit(1)
Programa simple de división de mbox de UNIX.
git-merge-one-file(1)
El programa auxiliar estándar para usar con git-merge-index.
git-patch-id(1)
Calcula un ID único para un parche.
git-sh-i18n(1)
Código de configuración de internacionalización de Git para scripts de shell.
git-sh-setup(1)
Código de configuración común de scripts de shell de Git.
git-stripspace(1)
Elimina los espacios en blanco innecesarios.
GUÍAS
Las siguientes páginas de documentación son guías sobre conceptos de Git.
gitcore-tutorial(7)
Un tutorial central de Git para desarrolladores.
gitcredentials(7)
Proporcionar nombres de usuario y contraseñas a Git.
gitcvs-migration(7)
Git para usuarios de CVS.
gitdiffcore(7)
Ajuste de la salida de diff.
giteveryday(7)
Un conjunto mínimo útil de comandos para el Git diario.
gitfaq(7)
Preguntas frecuentes sobre el uso de Git.
gitglossary(7)
Un glosario de Git.
gitnamespaces(7)
Espacios de nombres de Git.
gitremote-helpers(7)
Programas auxiliares para interactuar con repositorios remotos.
gitsubmodules(7)
Montar un repositorio dentro de otro.
gittutorial(7)
Una introducción tutorial a Git.
gittutorial-2(7)
Una introducción tutorial a Git: parte dos.
gitworkflows(7)
Una descripción general de los flujos de trabajo recomendados con Git.
REPOSITORIO, INTERFACES DE COMANDOS Y ARCHIVOS
Esta documentación analiza las interfaces de repositorio y comandos con las que se espera que los usuarios interactúen directamente. Consulte --user-formats en git-help(1) para obtener más detalles sobre los criterios.
gitattributes(5)
Definición de atributos por ruta.
gitcli(7)
Interfaz de línea de comandos de Git y convenciones.
githooks(5)
Hooks utilizados por Git.
gitignore(5)
Especifica los archivos que se deben rastrear intencionalmente e ignorar.
gitmailmap(5)
Mapeo de nombres y/o direcciones de correo electrónico de autor/confirmante.
gitmodules(5)
Definición de propiedades de submódulos.
gitrepository-layout(5)
Diseño del repositorio de Git.
gitrevisions(7)
Especificación de revisiones y rangos para Git.
FORMATOS DE ARCHIVOS, PROTOCOLOS Y OTRAS INTERFACES PARA DESARROLLADORES
Esta documentación analiza los formatos de archivo, los protocolos de comunicación y otras interfaces de Git para desarrolladores. Consulte --developer-interfaces en git-help(1).
gitformat-bundle(5)
El formato de archivo de paquete.
gitformat-chunk(5)
Formatos de archivo basados en fragmentos.
gitformat-commit-graph(5)
Formato de grafo de commits de Git.
gitformat-index(5)
Formato de índice de Git.
gitformat-pack(5)
Formato de paquete de Git.
gitformat-signature(5)
Formatos de firma criptográfica de Git.
gitprotocol-capabilities(5)
Capacidades de los protocolos v0 y v1.
gitprotocol-common(5)
Cosas comunes a varios protocolos.
gitprotocol-http(5)
Protocolos de Git basados en HTTP.
gitprotocol-pack(5)
Cómo se transfieren los paquetes a través de la red.
gitprotocol-v2(5)
Protocolo de comunicación de Git, versión 2.
MECANISMO DE CONFIGURACIÓN
Git utiliza un formato de texto simple para almacenar las personalizaciones que son por repositorio y por usuario. Un archivo de configuración puede tener este aspecto:
#
# Un carácter '#' o ';' indica un comentario.
#
; variables centrales
[core]
; No confiar en los modos de archivo
filemode = false
; identidad de usuario
[user]
name = "Junio C Hamano"
email = "_"
Varios comandos leen del archivo de configuración y ajustan su operación en consecuencia. Consulte git-config(1) para obtener una lista y más detalles sobre el mecanismo de configuración.
TERMINOLOGÍA DE IDENTIFICADORES
<object>
Indica el nombre del objeto para cualquier tipo de objeto.
<blob>
Indica un nombre de objeto blob.
<tree>
Indica un nombre de objeto de árbol.
<commit>
Indica un nombre de objeto de confirmación.
<tree-ish>
Indica un nombre de objeto de árbol, confirmación o etiqueta. Un comando que acepta un argumento
<commit-ish>
Indica el nombre de un objeto de confirmación o etiqueta. Un comando que acepta un argumento
<type>
Indica que se requiere un tipo de objeto. Actualmente, uno de: blob, tree, commit o tag.
<file>
Indica un nombre de archivo, casi siempre relativo a la raíz de la estructura de árbol que describe GIT_INDEX_FILE.
IDENTIFICADORES SIMBÓLICOS
Cualquier comando Git que acepte cualquier <object> también puede utilizar la siguiente notación simbólica:
HEAD
indica la cabeza de la rama actual.
<tag>
un nombre de etiqueta válido (es decir, una referencia refs/tags/<tag>).
<head>
un nombre de cabeza válido (es decir, una referencia refs/heads/<head>).
Para obtener una lista más completa de las formas de especificar nombres de objetos, consulte la sección "ESPECIFICANDO REVISIONES" en gitrevisions(7).
ESTRUCTURA DE ARCHIVOS/DIRECTORIOS
Consulte el documento gitrepository-layout(5).
Consulte githooks(5) para obtener más detalles sobre cada hook.
Los SCM de nivel superior pueden proporcionar y administrar información adicional en $GIT_DIR.
TERMINOLOGÍA
Consulte gitglossary(7).
VARIABLES DE ENTORNO
Varios comandos Git prestan atención a las variables de entorno y cambian su comportamiento. Las variables de entorno marcadas como "Booleanas" toman sus valores de la misma manera que las variables de configuración booleanas, es decir, "true", "yes", "on" y números positivos se toman como "sí", mientras que "false", "no", "off" y "0" se toman como "no".
Aquí están las variables:
Sistema
HOME
Especifica la ruta al directorio de inicio del usuario. En Windows, si no está configurada, Git establecerá una variable de entorno de proceso igual a: $HOMEDRIVE$HOMEPATH si tanto $HOMEDRIVE como $HOMEPATH existen; de lo contrario, $USERPROFILE si $USERPROFILE existe.
El repositorio Git
Estas variables de entorno se aplican a todos los comandos principales de Git. Nb: vale la pena señalar que pueden ser utilizadas/anuladas por los SCM que se encuentran por encima de Git, así que tenga cuidado si utiliza una interfaz frontal externa.
GIT_INDEX_FILE
Esta variable de entorno especifica un archivo de índice alternativo. Si no se especifica, se utiliza el valor predeterminado de $GIT_DIR/index.
GIT_INDEX_VERSION
Esta variable de entorno especifica qué versión de índice se utiliza al escribir el archivo de índice. No afectará a los archivos de índice existentes. De forma predeterminada, se utiliza la versión 2 o 3 del archivo de índice. Consulte git-update-index(1) para obtener más información.
GIT_OBJECT_DIRECTORY
Si el directorio de almacenamiento de objetos se especifica a través de esta variable de entorno, entonces los directorios sha1 se crean debajo; de lo contrario, se utiliza el directorio predeterminado $GIT_DIR/objects.
GIT_ALTERNATE_OBJECT_DIRECTORIES
Debido a la naturaleza inmutable de los objetos Git, los objetos antiguos se pueden archivar en directorios compartidos, de solo lectura. Esta variable especifica una lista separada por ":" (en Windows separada por ";") de directorios de objetos Git que se pueden utilizar para buscar objetos Git. Los nuevos objetos no se escribirán en estos directorios.
Las entradas que comienzan con " (comillas dobles) se interpretarán como rutas con comillas al estilo C, eliminando las comillas dobles iniciales y finales y respetando los caracteres de escape con barra invertida. Por ejemplo, el valor "ruta-con-\"-y-:-en-ella":ruta-normal tiene dos rutas: ruta-con-"-y-:-en-ella y ruta-normal.
GIT_DIR
Si la variable de entorno GIT_DIR está establecida, especifica una ruta que se utilizará en lugar de la ruta predeterminada .git para la base del repositorio. La opción de línea de comandos --git-dir también establece este valor.
GIT_WORK_TREE
Establece la ruta al directorio raíz del árbol de trabajo. Esto también se puede controlar mediante la opción de línea de comandos --work-tree y la variable de configuración core.worktree.
GIT_NAMESPACE
Establece el espacio de nombres de Git; consulte gitnamespaces(7) para obtener más detalles. La opción de línea de comandos --namespace también establece este valor.
GIT_CEILING_DIRECTORIES
Debería ser una lista separada por dos puntos de rutas absolutas. Si se establece, es una lista de directorios en los que Git no debe cambiar el directorio de trabajo al buscar un directorio de repositorio (útil para excluir directorios de red de carga lenta). No excluirá el directorio de trabajo actual ni un GIT_DIR establecido en la línea de comandos o en el entorno. Normalmente, Git tiene que leer las entradas de esta lista y resolver cualquier enlace simbólico que pueda estar presente para compararlos con el directorio actual. Sin embargo, si incluso este acceso es lento, puede agregar una entrada vacía a la lista para indicarle a Git que las entradas posteriores no son enlaces simbólicos y no es necesario resolverlas; por ejemplo, GIT_CEILING_DIRECTORIES=/quizás/enlace::/muy/lento/no/enlace.
GIT_DISCOVERY_ACROSS_FILESYSTEM
Cuando se ejecuta en un directorio que no tiene un directorio de repositorio ".git", Git intenta encontrar dicho directorio en los directorios principales para encontrar la parte superior del árbol de trabajo, pero por defecto no cruza los límites del sistema de archivos. Esta variable booleana se puede establecer en true para indicarle a Git que no se detenga en los límites del sistema de archivos. Al igual que GIT_CEILING_DIRECTORIES, esto no afectará a un directorio de repositorio explícito establecido mediante GIT_DIR o en la línea de comandos.
GIT_COMMON_DIR
Si esta variable está establecida en una ruta, los archivos que no son del árbol de trabajo y que normalmente se encuentran en $GIT_DIR se tomarán de esta ruta en su lugar. Los archivos específicos del árbol de trabajo, como HEAD o el índice, se toman de $GIT_DIR. Consulte gitrepository-layout(5) y git-worktree(1) para obtener más detalles. Esta variable tiene una prioridad más baja que otras variables de ruta, como GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY...
GIT_DEFAULT_HASH
Si esta variable está establecida, el algoritmo hash predeterminado para los nuevos repositorios se establecerá en este valor. Este valor se ignora al clonar y siempre se utiliza la configuración del repositorio remoto. El valor predeterminado es "sha1". Consulte --object-format en git-init(1).
GIT_DEFAULT_REF_FORMAT
Si esta variable está establecida, el formato predeterminado del backend de referencia para los nuevos repositorios se establecerá en este valor. El valor predeterminado es "files". Consulte --ref-format en git-init(1).
Commits de Git
GIT_AUTHOR_NAME
El nombre legible por humanos que se utiliza en la identidad del autor al crear objetos de commit o etiqueta, o al escribir reflogs. Anula la configuración de user.name y author.name.
GIT_AUTHOR_EMAIL
La dirección de correo electrónico utilizada en la identidad del autor al crear objetos de commit o tag, o al escribir reflogs. Anula la configuración de user.email y author.email.
GIT_AUTHOR_DATE
La fecha utilizada para la identidad del autor al crear objetos de commit o tag, o al escribir reflogs. Consulte git-commit(1) para ver los formatos válidos.
GIT_COMMITTER_NAME
El nombre legible por humanos utilizado en la identidad del committer al crear objetos de commit o tag, o al escribir reflogs. Anula la configuración de user.name y committer.name.
GIT_COMMITTER_EMAIL
La dirección de correo electrónico utilizada en la identidad del autor al crear objetos de commit o tag, o al escribir reflogs. Anula la configuración de user.email y committer.email.
GIT_COMMITTER_DATE
La fecha utilizada para la identidad del committer al crear objetos de commit o tag, o al escribir reflogs. Consulte git-commit(1) para ver los formatos válidos.
EMAIL
La dirección de correo electrónico utilizada en las identidades de autor y committer si no se ha establecido ninguna otra variable de entorno o configuración relevante.
Diferencias de Git
GIT_DIFF_OPTS
El único valor válido es "--unified=?" o "-u?" para establecer el número de líneas de contexto que se mostrarán al crear una diferencia unificada. Esto tiene prioridad sobre cualquier opción "-U" o "--unified" que se pase en la línea de comandos de git diff.
GIT_EXTERNAL_DIFF
Cuando la variable de entorno GIT_EXTERNAL_DIFF está configurada, se llama al programa especificado para generar diferencias y Git no utiliza su mecanismo de diferencias integrado. Para una ruta que se ha añadido, eliminado o modificado, GIT_EXTERNAL_DIFF se llama con 7 parámetros:
path old-file old-hex old-mode new-file new-hex new-mode
donde:
<old|new>-file
son archivos que `GIT_EXTERNAL_DIFF` puede usar para leer el contenido de <old|new>,
<old|new>-hex
son los hashes SHA-1 de 40 dígitos,
<old|new>-mode
son la representación octal de los modos de archivo.
Los archivos pueden apuntar al archivo de trabajo del usuario (por ejemplo, new-file en "git-diff-files"), /dev/null (por ejemplo, old-file cuando se añade un archivo nuevo) o un archivo temporal (por ejemplo, old-file en el índice). GIT_EXTERNAL_DIFF no debe preocuparse por eliminar el archivo temporal; se elimina cuando GIT_EXTERNAL_DIFF sale.
Para una ruta que no está fusionada, GIT_EXTERNAL_DIFF se llama con 1 parámetro,
Para cada ruta en la que se llama a GIT_EXTERNAL_DIFF, se establecen dos variables de entorno, GIT_DIFF_PATH_COUNTER y GIT_DIFF_PATH_TOTAL.
GIT_EXTERNAL_DIFF_TRUST_EXIT_CODE
Si esta variable de entorno booleana se establece en true, se espera que el comando GIT_EXTERNAL_DIFF devuelva el código de salida 0 si considera que los archivos de entrada son iguales o 1 si considera que son diferentes, como diff(1). Si se establece en false, que es el valor predeterminado, se espera que el comando devuelva el código de salida 0 independientemente de si son iguales o no. Cualquier otro código de salida hará que Git informe de un error fatal.
GIT_DIFF_PATH_COUNTER
Un contador basado en 1 que se incrementa en uno por cada ruta.
GIT_DIFF_PATH_TOTAL
El número total de rutas.
other
GIT_MERGE_VERBOSITY
Un número que controla la cantidad de salida que muestra la estrategia de fusión recursiva. Anula
merge.verbosity. Consulte git-merge(1).
GIT_PAGER
Esta variable de entorno anula $PAGER. Si se establece en una cadena vacía o en el valor
"cat", Git no iniciará un paginador. Consulte también la opción core.pager en git-config(1).
GIT_PROGRESS_DELAY
Un número que controla cuántos segundos de retraso debe haber antes de mostrar indicadores de progreso opcionales.
El valor predeterminado es 2.
GIT_EDITOR
Esta variable de entorno anula $EDITOR y $VISUAL. Se utiliza en varios comandos de Git
cuando, en modo interactivo, se debe iniciar un editor. Consulte también git-var(1) y la
opción core.editor en git-config(1).
GIT_SEQUENCE_EDITOR
Esta variable de entorno anula el editor de Git configurado al editar la lista de tareas pendientes de
una rebase interactiva. Consulte también git-rebase(1) y la opción sequence.editor en git-config(1).
GIT_SSH, GIT_SSH_COMMAND
Si alguna de estas variables de entorno está establecida, entonces git fetch y git push utilizarán el
comando especificado en lugar de ssh cuando necesiten conectarse a un sistema remoto. Los
parámetros de línea de comandos que se pasan al comando configurado están determinados por la variante ssh.
Consulte la opción ssh.variant en git-config(1) para obtener más detalles.
$GIT_SSH_COMMAND tiene prioridad sobre $GIT_SSH, y es interpretada por el shell, lo que permite incluir argumentos adicionales. $GIT_SSH, por otro lado, debe ser solo la ruta
a un programa (que puede ser un script shell envoltorio, si se necesitan argumentos adicionales).
Normalmente, es más fácil configurar cualquier opción deseada a través de su archivo .ssh/config personal.
Consulte la documentación de ssh para obtener más detalles.
GIT_SSH_VARIANT
Si esta variable de entorno está establecida, anula la detección automática de Git de si
GIT_SSH/GIT_SSH_COMMAND/core.sshCommand se refieren a OpenSSH, plink o tortoiseplink.
Esta variable anula la configuración ssh.variant que tiene el mismo propósito.
GIT_SSL_NO_VERIFY
Establecer y exportar esta variable de entorno a cualquier valor le indica a Git que no verifique el
certificado SSL cuando realice una extracción o una inserción a través de HTTPS.
GIT_ATTR_SOURCE
Establece el árbol desde el que gitattributes leerá.
GIT_ASKPASS
Si esta variable de entorno está establecida, entonces los comandos de Git que necesitan adquirir contraseñas o
frases de contraseña (por ejemplo, para la autenticación HTTP o IMAP) llamarán a este programa con una solicitud adecuada como argumento de línea de comandos y leerán la contraseña desde su STDOUT. Consulte también la
opción core.askPass en git-config(1).
GIT_TERMINAL_PROMPT
Si esta variable de entorno booleana está establecida en false, Git no solicitará información en la terminal
(por ejemplo, al solicitar la autenticación HTTP).
GIT_CONFIG_GLOBAL, GIT_CONFIG_SYSTEM
Toma la configuración de los archivos especificados en lugar de los archivos de configuración a nivel global o del sistema. Si GIT_CONFIG_SYSTEM está establecido, el archivo de configuración del sistema definido en tiempo de compilación (generalmente
/etc/gitconfig) no se leerá. De manera similar, si GIT_CONFIG_GLOBAL está establecido, ni $HOME/.gitconfig ni $XDG_CONFIG_HOME/git/config se leerán. Se puede establecer en /dev/null para
dejar de leer los archivos de configuración del nivel respectivo.
GIT_CONFIG_NOSYSTEM
Indica si se deben omitir la lectura de las configuraciones del archivo de configuración a nivel de sistema $(prefix)/etc/gitconfig. Esta variable de entorno booleana se puede usar junto con $HOME y $XDG_CONFIG_HOME para crear un entorno predecible para un script quisquilloso, o puede configurarla en verdadero para evitar temporalmente el uso de un archivo /etc/gitconfig defectuoso mientras se espera a que alguien con permisos suficientes lo arregle.
GIT_FLUSH
Si esta variable de entorno booleana se establece en verdadero, entonces comandos como git blame (en modo incremental), git rev-list, git log, git check-attr y git check-ignore forzarán un vaciado del flujo de salida después de que se haya vaciado cada registro. Si esta variable se establece en falso, la salida de estos comandos se realizará mediante E/S completamente almacenada en búfer. Si esta variable de entorno no está configurada, Git elegirá el vaciado en búfer o orientado a registros en función de si stdout parece estar redirigido a un archivo o no.
GIT_TRACE
Habilita mensajes de seguimiento generales, por ejemplo, la expansión de alias, la ejecución de comandos integrados y la ejecución de comandos externos.
Si esta variable está configurada en "1", "2" o "true" (la comparación no distingue entre mayúsculas y minúsculas), los mensajes de seguimiento se imprimirán en stderr.
Si la variable está configurada en un valor entero mayor que 2 y menor que 10 (estrictamente), Git interpretará este valor como un descriptor de archivo abierto e intentará escribir los mensajes de seguimiento en este descriptor de archivo.
Alternativamente, si la variable está configurada en una ruta absoluta (que comienza con un carácter /), Git la interpretará como una ruta de archivo e intentará agregar los mensajes de seguimiento a ella.
Anular la configuración de la variable, o establecerla en vacío, "0" o "false" (no distingue entre mayúsculas y minúsculas), desactiva los mensajes de seguimiento.
GIT_TRACE_FSMONITOR
Habilita mensajes de seguimiento para la extensión del monitor del sistema de archivos. Consulte GIT_TRACE para conocer las opciones de salida de seguimiento disponibles.
GIT_TRACE_PACK_ACCESS
Habilita mensajes de seguimiento para todos los accesos a cualquier paquete. Para cada acceso, se registra el nombre del archivo del paquete y un desplazamiento en el paquete. Esto puede ser útil para solucionar algunos problemas de rendimiento relacionados con los paquetes. Consulte GIT_TRACE para conocer las opciones de salida de seguimiento disponibles.
GIT_TRACE_PACKET
Habilita mensajes de seguimiento para todos los paquetes que entran o salen de un programa determinado. Esto puede ayudar a depurar problemas de negociación de objetos u otros problemas de protocolo. El seguimiento se desactiva en un paquete que comienza con "PACK" (pero consulte GIT_TRACE_PACKFILE a continuación). Consulte GIT_TRACE para conocer las opciones de salida de seguimiento disponibles.
GIT_TRACE_PACKFILE
Habilita el seguimiento de los archivos de paquete enviados o recibidos por un programa determinado. A diferencia de otras salidas de seguimiento, este seguimiento es textual: sin encabezados y sin comillas para los datos binarios. Casi con seguridad, querrá dirigirlo a un archivo (por ejemplo, GIT_TRACE_PACKFILE=/tmp/my.pack) en lugar de mostrarlo en la terminal o mezclarlo con otras salidas de seguimiento.
Tenga en cuenta que esto solo se implementa actualmente para el lado del cliente de clones y recuperaciones.
GIT_TRACE_PERFORMANCE
Habilita los mensajes de seguimiento relacionados con el rendimiento, por ejemplo, el tiempo total de ejecución de cada comando de Git. Consulte GIT_TRACE para conocer las opciones de salida de seguimiento disponibles.
GIT_TRACE_REFS
Habilita los mensajes de seguimiento para las operaciones en la base de datos de referencias. Consulte GIT_TRACE para conocer las opciones de salida de seguimiento disponibles.
GIT_TRACE_SETUP
Habilita los mensajes de seguimiento que imprimen el directorio .git, el árbol de trabajo y el directorio de trabajo actual después de que Git haya completado su fase de configuración. Consulte GIT_TRACE para conocer las opciones de salida de seguimiento disponibles.
GIT_TRACE_SHALLOW
Habilita los mensajes de seguimiento que pueden ayudar a depurar la recuperación/el clonado de repositorios poco profundos. Consulte GIT_TRACE para conocer las opciones de salida de seguimiento disponibles.
GIT_TRACE_CURL
Habilita un volcado completo de seguimiento de curl de todos los datos entrantes y salientes, incluida la información descriptiva, del protocolo de transporte de Git. Esto es similar a usar curl --trace-ascii en la línea de comandos. Consulte GIT_TRACE para conocer las opciones de salida de seguimiento disponibles.
GIT_TRACE_CURL_NO_DATA
Cuando se habilita un seguimiento de curl (consulte GIT_TRACE_CURL anterior), no se deben volcar los datos (es decir, solo se deben volcar las líneas y los encabezados de información).
GIT_TRACE2
Habilita mensajes de seguimiento más detallados de la biblioteca "trace2". La salida de GIT_TRACE2 es un formato de texto simple para facilitar la lectura.
Si esta variable se establece en "1", "2" o "true" (la comparación no distingue entre mayúsculas y minúsculas), los mensajes de seguimiento se imprimirán en stderr.
Si la variable se establece en un valor entero mayor que 2 y menor que 10 (estrictamente), Git interpretará este valor como un descriptor de archivo abierto e intentará escribir los mensajes de seguimiento en este descriptor de archivo.
Alternativamente, si la variable se establece en una ruta absoluta (que comienza con una /), Git interpretará esto como una ruta de archivo e intentará agregar los mensajes de seguimiento a ella. Si la ruta ya existe y es un directorio, los mensajes de seguimiento se escribirán en archivos (uno por proceso) en ese directorio, con el nombre del último componente del SID y un contador opcional (para evitar colisiones de nombres de archivo).
Además, si la variable se establece en af_unix:[
Además, si la variable se establece en af_unix:[
Anular la variable, o establecerla en vacío, "0" o "false" (sin distinguir entre mayúsculas y minúsculas) deshabilita los mensajes de seguimiento.
Consulte la documentación de Trace2[2] para obtener todos los detalles.
GIT_TRACE2_EVENT
Esta configuración escribe un formato basado en JSON que es adecuado para la interpretación de máquinas. Consulte GIT_TRACE2 para conocer las opciones de salida de seguimiento disponibles y la documentación de Trace2[2] para obtener todos los detalles.
GIT_TRACE2_PERF
Además de los mensajes basados en texto disponibles en GIT_TRACE2, esta configuración escribe un formato basado en columnas para comprender las regiones anidadas. Consulte GIT_TRACE2 para conocer las opciones de salida de seguimiento disponibles y la documentación de Trace2[2] para obtener todos los detalles.
GIT_TRACE_REDACT
Por defecto, cuando el rastreo está activado, Git redacta los valores de las cookies, la cabecera "Authorization:", la cabecera "Proxy-Authorization:" y las URI de los archivos de paquete. Establezca esta variable de entorno booleana en "false" para evitar esta redacción.
GIT_NO_REPLACE_OBJECTS
Establecer y exportar esta variable de entorno le indica a Git que ignore las referencias de reemplazo y que no reemplace los objetos de Git.
GIT_LITERAL_PATHSPECS
Establecer esta variable de entorno booleana en "true" hará que Git trate todas las especificaciones de ruta literalmente, en lugar de como patrones glob. Por ejemplo, ejecutar GIT_LITERAL_PATHSPECS=1 git log -- '.c' buscará los commits que toquen la ruta .c, y no cualquier ruta que el patrón glob *.c coincida. Es posible que desee esto si está proporcionando rutas literales a Git (por ejemplo, rutas que le fueron proporcionadas previamente por git ls-tree, la salida sin formato de diff, etc.).
GIT_GLOB_PATHSPECS
Establecer esta variable de entorno booleana en "true" hará que Git trate todas las especificaciones de ruta como patrones glob (también conocidos como "glob magic").
GIT_NOGLOB_PATHSPECS
Establecer esta variable de entorno booleana en "true" hará que Git trate todas las especificaciones de ruta como literales (también conocidos como "literal magic").
GIT_ICASE_PATHSPECS
Establecer esta variable de entorno booleana en "true" hará que Git trate todas las especificaciones de ruta como que no distinguen entre mayúsculas y minúsculas.
GIT_NO_LAZY_FETCH
Establecer esta variable de entorno booleana en "true" le indica a Git que no obtenga de forma diferida los objetos faltantes del repositorio promisor a pedido.
GIT_REFLOG_ACTION
Cuando se actualiza una referencia, se crean entradas de reflog para realizar un seguimiento del motivo por el cual se actualizó la referencia (que suele ser el nombre del comando de nivel superior que actualizó la referencia), además de los valores antiguos y nuevos de la referencia. Un comando de Porcelain con script puede usar la función de ayudante set_reflog_action en git-sh-setup para establecer su nombre en esta variable cuando se invoca como el comando de nivel superior por el usuario final, para que se registre en el cuerpo del reflog.
GIT_REF_PARANOIA
Si esta variable de entorno booleana se establece en "false", ignore las referencias rotas o con nombres incorrectos al iterar sobre las listas de referencias. Normalmente, Git intentará incluir cualquier referencia, lo que puede provocar que algunas operaciones fallen. Esto suele ser preferible, ya que las operaciones potencialmente destructivas (por ejemplo, git-prune(1)) es mejor que se interrumpan en lugar de ignorar las referencias rotas (y por lo tanto, considerar que el historial al que apuntan no vale la pena guardarlo). El valor predeterminado es 1 (es decir, sea paranoico al detectar y abortar todas las operaciones). Normalmente, no es necesario que lo establezca en 0, pero puede ser útil cuando intenta recuperar datos de un repositorio dañado.
GIT_COMMIT_GRAPH_PARANOIA
Cuando se carga un objeto de commit desde el grafo de commits, Git realiza una comprobación de existencia del objeto en la base de datos de objetos. Esto se hace para evitar problemas con los grafos de commits obsoletos que contienen referencias a commits ya eliminados, pero tiene un costo de rendimiento.
El valor predeterminado es "false", lo que desactiva el comportamiento mencionado anteriormente. Establecerlo en
"true" habilita la comprobación de existencia para que nunca se devuelvan commits obsoletos del grafo de commits a
expensas del rendimiento.
GIT_ALLOW_PROTOCOL
Si se establece en una lista separada por dos puntos de protocolos, se comporta como si protocol.allow se estableciera en never, y cada uno de los protocolos de la lista tiene protocol.<name>.allow establecido en always (anulando cualquier configuración existente). Consulte la descripción de protocol.allow en git-config(1) para obtener más detalles.
GIT_PROTOCOL_FROM_USER
Establezca esta variable de entorno booleana en false para evitar que los protocolos utilizados por fetch/push/clone que están configurados en el estado de usuario se utilicen. Esto es útil para restringir la inicialización recursiva de submódulos desde un repositorio no confiable o para programas que proporcionan URL potencialmente no confiables a los comandos de git. Consulte git-config(1) para obtener más detalles.
GIT_PROTOCOL
Solo para uso interno. Se utiliza para el protocolo de enlace. Contiene una lista separada por dos puntos de claves con valores opcionales <key>[=<value>]. La presencia de claves y valores desconocidos debe ignorarse.
Tenga en cuenta que es posible que sea necesario configurar los servidores para permitir que esta variable se transmita a través de algunos transportes. Se propagará automáticamente al acceder a los repositorios locales (es decir, file:// o una ruta del sistema de archivos), así como a través del protocolo git://. Para git-over-http, debería funcionar automáticamente en la mayoría de las configuraciones, pero consulte la discusión en git-httpbackend(1). Para git-over-ssh, es posible que el servidor ssh deba configurarse para permitir que los clientes pasen esta variable (por ejemplo, utilizando AcceptEnv GIT_PROTOCOL con OpenSSH).
Esta configuración es opcional. Si la variable no se propaga, los clientes volverán al protocolo original "v0" (pero pueden perderse algunas mejoras de rendimiento o características). Esta variable solo afecta actualmente a las clonaciones y las extracciones; aún no se utiliza para las subidas (pero podría hacerlo en el futuro).
GIT_OPTIONAL_LOCKS
Si esta variable de entorno booleana se establece en false, Git completará cualquier operación solicitada sin realizar ninguna operación secundaria opcional que requiera la adquisición de un bloqueo. Por ejemplo, esto evitará que git status actualice el índice como efecto secundario. Esto es útil para los procesos que se ejecutan en segundo plano y que no desean provocar conflictos de bloqueo con otras operaciones en el repositorio. El valor predeterminado es 1.
GIT_REDIRECT_STDIN, GIT_REDIRECT_STDOUT, GIT_REDIRECT_STDERR
Solo para Windows: permite redirigir los identificadores de entrada/salida/error estándar a las rutas especificadas por las variables de entorno. Esto es particularmente útil en aplicaciones multihilo donde la forma canónica de pasar los identificadores estándar a través de CreateProcess() no es una opción porque requeriría que los identificadores se marquen como heredables (y, por lo tanto, cada proceso generado heredaría, posiblemente bloqueando las operaciones de Git regulares). El caso de uso previsto es utilizar tuberías con nombre para la comunicación (por ejemplo, \\.\pipe\my-git-stdin-123).
Se admiten dos valores especiales: off simplemente cerrará el identificador de salida/entrada/error estándar correspondiente y, si GIT_REDIRECT_STDERR es 2>&1, la salida de error estándar se redirigirá al mismo identificador que la salida estándar.
GIT_PRINT_SHA1_ELLIPSIS (obsoleto)
Si se establece en sí, imprime una elipsis después de un valor SHA-1 (abreviado). Esto afecta a las indicaciones de HEADs desconectados (git-checkout(1)) y a la salida de diff sin formato (git-diff(1)). Imprimir una elipsis en los casos mencionados ya no se considera adecuado y es probable que el soporte para ello se elimine en un futuro próximo (junto con la variable).
GIT_ADVICE
Si se establece en 0, desactiva todos los mensajes de advertencia. Estos mensajes tienen como objetivo proporcionar sugerencias a los usuarios para que puedan salir de situaciones problemáticas o aprovechar las nuevas funciones. Los usuarios pueden deshabilitar mensajes individuales utilizando las claves de configuración advice.*. Estos mensajes pueden ser disruptivos para las herramientas que ejecutan procesos de Git, por lo que esta variable está disponible para desactivar los mensajes. (La opción global --no-advice también está disponible, pero las versiones antiguas de Git pueden fallar cuando esta opción no se entiende. La variable de entorno se ignorará en las versiones de Git que no la entienden).
DISCUSIÓN
Más detalles sobre lo siguiente están disponibles en el capítulo de conceptos de Git del manual del usuario[3] y gitcore-tutorial(7).
Un proyecto de Git normalmente consta de un directorio de trabajo con un subdirectorio ".git" en el nivel superior. El directorio .git contiene, entre otras cosas, una base de datos de objetos comprimida que representa
el historial completo del proyecto, un archivo "index" que vincula ese historial al contenido actual
del árbol de trabajo y punteros con nombre al historial, como etiquetas y cabezales de ramas.
La base de datos de objetos contiene objetos de tres tipos principales: blobs, que contienen datos de archivos; árboles, que apuntan a blobs y otros árboles para construir jerarquías de directorios; y commits, que cada uno hacen referencia a un único árbol y a un número de commits padre.
El commit, equivalente a lo que otros sistemas llaman un "conjunto de cambios" o "versión", representa un paso en el historial del proyecto, y cada padre representa un paso inmediatamente anterior. Los commits con más de un padre representan la fusión de líneas de desarrollo independientes.
Todos los objetos se nombran mediante el hash SHA-1 de su contenido, que normalmente se escribe como una cadena de 40 dígitos hexadecimales. Estos nombres son globalmente únicos. Todo el historial hasta un commit se puede verificar firmando solo ese commit. Se proporciona un cuarto tipo de objeto, la etiqueta, para este propósito.
Cuando se crean por primera vez, los objetos se almacenan en archivos individuales, pero para mejorar la eficiencia, más tarde se pueden comprimir en "archivos de paquete".
Los punteros con nombre llamados refs marcan puntos interesantes en el historial. Un ref puede contener el nombre SHA-1 de un objeto o el nombre de otro ref (esto último se llama "ref simbólico"). Los refs con nombres que comienzan con refs/head/ contienen el nombre SHA-1 del commit más reciente (o "cabezal") de una rama en desarrollo. Los nombres SHA-1 de las etiquetas de interés se almacenan en refs/tags/. Un ref simbólico llamado HEAD contiene el nombre de la rama que se está utilizando actualmente.
El archivo de índice se inicializa con una lista de todas las rutas y, para cada ruta, un objeto blob y un conjunto de atributos. El objeto blob representa el contenido del archivo tal como está en la cabeza de la rama actual. Los atributos (hora de la última modificación, tamaño, etc.) se toman del archivo correspondiente en el árbol de trabajo. Los cambios posteriores en el árbol de trabajo se pueden encontrar comparando estos atributos. El índice se puede actualizar con contenido nuevo y se pueden crear nuevos commits a partir del contenido almacenado en el índice.
El índice también es capaz de almacenar múltiples entradas (llamadas "etapas") para un nombre de ruta determinado. Estas etapas se utilizan para contener las diferentes versiones no fusionadas de un archivo cuando se está realizando una fusión.
SEGURIDAD
Algunas opciones de configuración y archivos de hook pueden hacer que Git ejecute comandos de shell arbitrarios. Dado que la configuración y los hooks no se copian mediante git clone, generalmente es seguro clonar repositorios remotos con contenido no confiable, inspeccionarlos con git log, etc.
Sin embargo, no es seguro ejecutar comandos de Git en un directorio .git (o en el árbol de trabajo que lo rodea) cuando ese directorio .git proviene de una fuente no confiable. Los comandos en su configuración y hooks se ejecutan de la manera habitual.
De forma predeterminada, Git se negará a ejecutarse cuando el repositorio pertenezca a alguien que no sea el usuario que ejecuta el comando. Consulte la entrada para safe.directory en git-config(1). Si bien esto puede ayudar a protegerlo en un entorno de múltiples usuarios, tenga en cuenta que también puede adquirir repositorios no confiables que son propiedad suya (por ejemplo, si extrae un archivo zip o tarball de una fuente no confiable). En tales casos, primero deberá "sanear" el repositorio no confiable.
Si tiene un directorio .git no confiable, primero debe clonarlo con git clone --no-local para obtener una copia limpia. Git restringe el conjunto de opciones y hooks que se ejecutarán mediante upload-pack, que maneja el lado del servidor de una clonación o extracción, pero tenga en cuenta que el área de superficie para el ataque contra upload-pack es grande, por lo que esto conlleva cierto riesgo. Lo más seguro es servir el repositorio como un usuario no privilegiado (ya sea a través de git-daemon(1), ssh o utilizando otras herramientas para cambiar los ID de usuario). Consulte la discusión en la sección SEGURIDAD de git-upload-pack(1).
DOCUMENTACIÓN ADICIONAL
Consulte las referencias en la sección "descripción" para comenzar a usar Git. Lo siguiente probablemente sea más detallado de lo necesario para un usuario que lo usa por primera vez.
El capítulo de conceptos de Git del manual de usuario[3] y gitcore-tutorial(7) proporcionan introducciones a la arquitectura subyacente de Git.
Consulte gitworkflows(7) para obtener una descripción general de los flujos de trabajo recomendados.
Consulte también los documentos de "cómo hacerlo" [4] para obtener algunos ejemplos útiles.
Los aspectos internos se documentan en la documentación de la API de Git[5].
Los usuarios que migran desde CVS también pueden querer leer gitcvs-migration(7).
AUTORES
Git fue iniciado por Linus Torvalds y actualmente lo mantiene Junio C Hamano. Numerosas contribuciones provienen de la lista de correo de Git <_[6]>. (https://openhub.net/p/git/contributors/summary) le brinda una lista más completa de los colaboradores.
Si tienes un clon del propio git.git, la salida de git-shortlog(1) y git-blame(1) puede mostrarte los autores de partes específicas del proyecto.
INFORMES DE ERRORES
Informa de los errores a la lista de correo de Git <_[6]> donde se realiza principalmente el desarrollo y el mantenimiento. No es necesario que estés suscrito a la lista para enviar un mensaje. Consulta el archivo de la lista en https://lore.kernel.org/git para ver informes de errores anteriores y otras discusiones.
Los problemas relacionados con la seguridad deben divulgarse de forma privada a la lista de correo de Seguridad de Git <_[7]>.
VER TAMBIÉN
gittutorial(7), gittutorial-2(7), giteveryday(7), gitcvs-migration(7), gitglossary(7), gitcoretutorial(7), gitcli(7), El Manual del Usuario de Git[1], gitworkflows(7)
GIT
Parte del conjunto de herramientas git(1)
NOTAS
Manual del Usuario de Git
file:///usr/share/doc/git/html/user-manual.html
Documentación de Trace2
file:///usr/share/doc/git/html/technical/api-trace2.html
Capítulo de conceptos de Git del manual del usuario
file:///usr/share/doc/git/html/user-manual.html#git-concepts
howto
file:///usr/share/doc/git/html/howto-index.html
Documentación de la API de Git
file:///usr/share/doc/git/html/technical/api-index.html
_
mailto:_
_
mailto:_