Git

git last updated in 2.43.0

NOMBRE

git - el estúpido rastreador de contenido

SINOPSIS

git [-v | --version] [-h | --help] [-C <ruta>] [-c <nombre>=<valor>]
    [--exec-path[=<ruta>]] [--html-path] [--man-path] [--info-path]
    [-p|--paginate|-P|--no-pager] [--no-replace-objects] [--bare]
    [--git-dir=<ruta>] [--work-tree=<ruta>] [--namespace=<nombre>]
    [--config-env=<nombre>=<var-ambiente>] <comando> [<args>]

DESCRIPCIÓN

Git es un sistema de control de revisiones distribuido, rápido y escalable con un conjunto de comandos inusualmente rico que permite tanto operaciones de alto nivel como acceso completo a componentes internos.

Ver gittutorial[7] para comenzar, luego ver giteveryday[7] para un útil conjunto de comandos mínimo. El Manual de Usuario de Git tiene una introducción mas a fondo.

Después que domines los conceptos básicos, puedes regresar a ésta página para aprender qué comandos ofrece Git. Puedes aprender mas sobre comandos Git individuales con el comando "git help comando". La página del manual gitcli[7] te da una vistazo de la sintáxis de comandos en la línea de comandos.

Una copia formateada e hipervinculada de la mas reciente documentación de Git puede verse en https://git.github.io/htmldocs/git.html o https://git-scm.com/docs.

OPCIONES

-v

--version

Imprime la versión de la suite Git de la cual proviene el programa git.

Esta opción es internamente convertida a git version ... y acepta las mismas opciones que el comando git-version[1]. Si también se da --help toma precedencia sobre --version.

-h

--help

Imprime la sinopsis y una lista de los comandos más usados comúnmente. Si se da la opción --all o -a entonces todos los comandos disponibles se imprimen. Si un comando Git es nombrado, esta opción traerá la página del manual para ese comando.

Hay otras opciones disponibles para controlar cómo se muestra la página del manual. Ver git-help[1] para mayor información, porque git-help ... es convertido internamente en git help ....

-C <ruta>

Corre como si git hubiera iniciado en <ruta> en lugar del directorio de trabajo actual. Cuando se dan múltiples opciones -C, cada -C <ruta> no-absoluta subsecuente se interpreta como relativa al -C <ruta> precedente. Si <ruta> esta presente pero vacía, ej. -C "", entonces el directorio de trabajo actual queda sin modificaciones.

Esta opción afecta opciones que esperan una ruta (como --git-dir y --work-tree), en donde sus interpretaciones de los nombres de ruta se harían relativos al directorio de trabajo a causa de la opción -C. Por ejemplo, las invocaciones siguientes 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 <nombre>=<valor>

Pasa un parámetro de configuración al comando. El valor dado sobreescribirá valores de ficheros de configuración. El <nombre> se espera en el mismo formato como se lista por git config (subclaves separadas por puntos).

Nota que es permitido omitir el = en git -c foo.bar ... y se asignará a foo.bar el valor booleano true (así como [foo]bar lo haría en un fichero de configuración). Incluir el igual pero con un valor vacío (como git -c foo.bar= ...) asigna a foo.bar la cadena vacía que git config --type=bool convertirá a false.

--config-env=<nombre>=<variable-de-ambiente>

Como -c <nombre>=<valor>, da a la variable de configuración <nombre> un valor, donde <variable-de-ambiente> es el nombre de una variable de ambiente de la cual se obtiene el valor. Al contrario que -c no hay un atajo para asignar directamente el valor a una cadena vacía, en cambio, a la variable de ambiente misma se le debe asignar la cadena vacía. Es un error si la <variable-de-ambiente> no existe en el ambiente. <variable-de-ambiente> no puede contener un signo de igual para evitar ambigüedad con <nombre> que contenga.

Esto es útil en casos donde quieres pasar a git opciones de configuración transitorias, pero se hacen tan en el sistema oprativo donde otros procesos pueden ser capaces de leer tu línea de comandos (ej. /proc/self/cmdline), pero no tu ambiente (ej. /proc/self/environ). Ese es el comportamiento predeterminado en Linux, pero pudiera no serlo en tu sistema.

Nota que esto puede agregar seguridad para variables como http.extraHeader donde la información sensible es parte del valor, pero no ej. url.<base>.insteadOf donde la información sensible puede ser parte de la clave.

--exec-path[=<ruta>]

Ruta a dondequiera que estén instalados tus programas del núcleo de Git. Esto también puede ser controlado asignando la variable de ambiente GIT_EXEC_PATH. Si no se proporciona ruta git imprimirá la configuración actual y saldrá.

--html-path

Imprime la ruta, sin la última diagonal, donde esta instalada la documentación HTML de Git y sale.

--man-path

Imprime la ruta del manual (ver man(1)) para las páginas del manual de esta versión de Git y sale.

--info-path

Imprime la ruta donde están instalados los ficheros de información documentando esta versión de Git y sale.

-p

--paginate

Entuba toda la salida hacia less (o si esta configurado, $PAGER) si la salida estándar es una terminal. Esto sobreescribe las opciones de configuración pager.<comando> (ver la sección "Mecanismo de Configuración" mas abajo).

-P

--no-pager

No entuba la salida de Git hacia el paginador.

--git-dir=<ruta>

Asigna la ruta al repositorio (directorio ".git"). Esto también puede ser controlado configurando la variable de ambiente GIT_DIR. Puede ser una ruta absoluta o relativa al directorio de trabajo actual.

Especificando la ubicación del directorio ".git" usando esta opción (o la variable de ambiente GIT_DIR) apaga el descubrimiento de repositorio que intenta encontrar un directorio con subdirectorio ".git" (que es como se descubren el repositorio y el nivel mas alto del árbol de trabajo), y le dice a Git que estás en el nivel mas alto del árbol de trabajo. Si no estas en el directorio de nivel mas alto del árbol de trabajo, deberías decirle a Git dónde esta el nivel más alto del árbol de trabajo con la opción --work-tree=<ruta> (o la variable de ambiente GIT_WORK_TREE)

Si sólo quieres correr git como si fuera arrancado en <ruta> entonces usa git -C <ruta>.

--work-tree=<ruta>

Asigna la ruta al árbol de trabajo. Puede ser una ruta absoluta o relativa al directorio de trabajo actual. Esto puede se controlado asignando la variable de ambiente GIT_WORK_TREE y la variable de configuración core.worktree (ver core.worktree en git-config[1] para una discusión mas detallada).

--namespace=<ruta>

Asigna el espacio de nombres de Git. Ver gitnamespaces[7] para mas detalles. Equivalente a asignar la variable de ambiente GIT_NAMESPACE.

--bare

Trata el repositorio como un repositorio básico. Si la variable de ambiente GIT_DIR no esta asignada, se asigna al directorio de trabajo actual.

--no-replace-objects

No usa remplazamiento de referencias para remplazar objetos Git. Ver git-replace[1] para mas información.

--literal-pathspecs

Trata las especificaciones de ruta literalmente (ej. sin interpretar glob, sin especificaciones de ruta mágicas). Es equivalente a asignar la variable de ambiente GIT_LITERAL_PATHSPECS con 1.

--glob-pathspecs

Agrega magia "glob" a todas las especificaciones de ruta. Es equivalente a asignar 1 a la variable de ambiente GIT_GLOB_PATHSPECS. Se puede deshabilitar interpretación de glob en especificaciones de ruta individuales usando la especificación de ruta mágica ":(literal)"

--noglob-pathspecs

Agrega magia "literal" a todas las especificaciones de ruta. Es equivalente a asignar 1 a la variable de ambiente GIT_NOGLOB_PATHSPECS. Se puede habilitar interpretación de glob en especificaciones de ruta individuales usando la especificación de ruta mágica ":(glob)"

--icase-pathspecs

Agrega magia "icase" a todas las especificaciones de ruta. Es equivalente a asignar 1 a la variable de ambiente GIT_ICASE_PATHSPECS.

--no-optional-locks

No realiza operaciones opcionales que requieran bloqueos. Es equivalente a asignar 0 a GIT_OPTIONAL_LOCKS.

--list-cmds=grupo[,grupo…]

Lista comandos por grupo. Es una opción interna/experimental y puede cambiar o ser removida en el futuro. Los grupos soportados son: builtins, parseopt (comandos interconstruidos que usan opciones de parseo), main (todos los comandos en el directorio libexec), others (todos los otros comandos en $PATH que tienen el prefijo git-), list-<categoría> (ver categorías en command-list.txt), nohelpers (excluye comandos auxiliares), alias y config (obtiene la lista de comandos de la variable de configuración completion.commands)

--attr-source=<árbol-ismo>

Lee atributos git de <árbol-ismo> en lugar del árbol de trabajo. Ver gitattributes[5]. Equivale a asignar la variable de ambiente GIT_ATTR_SOURCE.

COMANDOS GIT

Dividimos Git en comandos de alto nivel ("porcelana") y comandos de bajo nivel ("plomería").

Comandos de alto nivel (porcelana)

Separamos los comandos porcelana en comandos principales y algunas utilidades de usuario auxiliares.

Comandos porcelana principales

git-add[1]: Agrega el contenido de ficheros al índice.
git-am[1]: Aplicar una serie de parches desde una carpeta de correo electrónico.
git-archive[1]: Crear un archivo de ficheros desde un árbol con nombre.
git-bisect[1]: Usar la búsqueda binaria para encontrar la confirmación que introdujo el bug.
git-branch[1]: Listar, crear, o borrar ramas.
git-bundle[1]: Mover objetos y referencias por archivo.
git-checkout[1]: Cambia de ramas o restaura los ficheros del árbol de trabajo.
git-cherry-pick[1]: Aplica los cambios introducidos por algunas confirmaciones existentes.
git-citool[1]: Alternativa gráfica a git-commit.
git-clean[1]: Elimina ficheros sin seguimiento del árbol de trabajo.
git-clone[1]: Clona un repositorio en un directorio nuevo.
git-commit[1]: Graba los cambios en el repositorio.
git-describe[1]: Dar a un objeto un nombre legible por personas basado en una referencia disponible.
git-diff[1]: Muestra cambios entre confirmaciones, confirmación y árbol de trabajo, etc.
git-fetch[1]: Descarga objetos y referencias desde otro repositorio.
git-format-patch[1]: Prepara parches para ser enviados por correo electrónico.
git-gc[1]: Limpia ficheros innecesarios y optimiza el repositorio local.
git-grep[1]: Imprime las líneas que concuerdan con un patrón.
git-gui[1]: Una interfaz gráfica portable para Git.
git-init[1]: Crea un repositorio de Git vacío o reinicializa uno ya existente.
git-log[1]: Muestra los registros de las confirmaciones.
git-maintenance[1]: Ejecuta tareas para optimizar los datos de un repositorio Git.
git-merge[1]: Une dos o más historiales de desarrollo juntos.
git-mv[1]: Mueve o cambia el nombre a un fichero, un directorio o un enlace simbólico.
git-notes[1]: Agrega o inspecciona notas de objetos.
git-pull[1]: Obtiene desde e integra con otro repositorio o una rama local.
git-push[1]: Actualiza referencias remotas junto con sus objetos asociados.
git-range-diff[1]: Compara dos rangos de confirmaciones (por ejemplo: dos versions de una rama).
git-rebase[1]: Vuelve a aplicar confirmaciones en la punta de otra rama.
git-reset[1]: Restablece el HEAD actual al estado especificado.
git-restore[1]: Restaura ficheros del árbol de trabajo.
git-revert[1]: Revierte algunas confirmaciones existentes.
git-rm[1]: Elimina ficheros del árbol de trabajo y del índice.
git-shortlog[1]: Resumir el resultado de git log.
git-show[1]: Muestra varios tipos de objetos.
git-sparse-checkout[1]: Reducir el árbol de trabajo a un subconjunto de ficheros rastreados.
git-stash[1]: Poner en una reserva los cambios de un directorio de trabajo con cambios.
git-status[1]: Muestra el estado del árbol de trabajo.
git-submodule[1]: Inicializa, actualiza o inspecciona submódulos.
git-switch[1]: Cambiar de rama.
git-tag[1]: Crea, lista, elimina o verifica un objeto de etiqueta firmado con GPG.
git-worktree[1]: Gestiona múltiples árboles de trabajo.
gitk[1]: El navegador de repositorio Git.
scalar[1]: Una herramienta para administrar repositorios Git grandes.

Comandos Auxiliares

Manipuladores:

git-config[1]: Obtener o establecer opciones de repositorio o globales.
git-fast-export[1]: Exportador de datos de Git.
git-fast-import[1]: Soporte para importadores rápidos de datos de Git.
git-filter-branch[1]: Reescribir ramas.
git-mergetool[1]: Ejecuta las herramientas de resolución de conflictos de fusión para resolver conflictos de fusión.
git-pack-refs[1]: Empaqueta heads y etiquetas para un acceso eficiente al repositorio.
git-prune[1]: Limpia todos los objetos no alcanzables de la base de datos de objetos.
git-reflog[1]: Gestionar información de reflog.
git-remote[1]: Gestiona un conjunto de repositorios con seguimiento.
git-repack[1]: Empaquetar objetos no empaquetados en un repositorio.
git-replace[1]: Crear, listar, eliminar referencias para reemplazar objetos.

Interrogadores:

git-annotate[1]: Anotar líneas de fichero con información de confirmación.
git-blame[1]: Muestra qué revisión y autor modificaron por última vez cada línea de un fichero.
git-bugreport[1]: Recolectar información para el usuario para generar un reporte de bug.
git-count-objects[1]: Contar el número de objetos no empaquetados y su consumo de espacio en disco.
git-diagnose[1]: Genera un archivo zip de información de diagnóstico.
git-difftool[1]: Mostrar cambios usando herramientas de diferencias habituales.
git-fsck[1]: Verifica la conectividad y validez de los objetos en la base de datos.
git-help[1]: Mostrar información de ayuda sobre Git.
git-instaweb[1]: Navegar instantáneamente a tu repositorio de trabajo en gitweb.
git-merge-tree[1]: Realiza fusión sin tocar el índice o el árbol de trabajo.
git-rerere[1]: Reutilizar la resolución guardada de fusiones con conflictos.
git-show-branch[1]: Mostrar ramas y sus confirmaciones.
git-verify-commit[1]: Verificar firma GPG de confirmaciones.
git-verify-tag[1]: Verificar la firma GPG de etiquetas.
git-version[1]: Mostrar información de la versión de Git.
git-whatchanged[1]: Mostrar logs con las diferencias que cada confirmación introduce.
gitweb[1]: Interfaz web de Git (interfaz web para repositorios Git).

Interactuando con Otros

Estos comandos son para interactuar con otros SCM y con otra gente vía parche sobre correo electrónico.

git-archimport[1]: Importar un repositorio GNU Arch en Git.
git-cvsexportcommit[1]: Exporta una confirmación única a un CVS checkout.
git-cvsimport[1]: Salvaguarda tus datos de otro SCM que la gente adora odiar.
git-cvsserver[1]: Un emulador de servidor CVS para Git.
git-imap-send[1]: Enviar una colección de parches desde stdin a una carpeta IMAP.
git-p4[1]: Importar desde y enviar a repositorios Perforce.
git-quiltimport[1]: Aplica un conjunto de parches de quilt en 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]: Interacción bidireccional entre un repositorio Subversion y otro Git.

Resetear, restaurar y revertir

Hay tres comandos con nombres similares: git reset, git restore y git revert.

git-revert[1] es acerca de hacer un nuevo commit que revierta los cambios hechos por otros commits.
git-restore[1] es acerca de restaurar ficheros en el árbol de trabajo de ya sea el índice u otro commit. Este comando no actualiza tu rama. El comando también puede usarse para restaurar ficheros en el índice de otro commit.
git-reset[1] es acerca de actualizar tu rama, moviendo la punta con el fin de agregar o eliminar commits de la rama. Esta operación cambia el historial de commits.

git reset también puede usarse para restaurar el índice, traslapando con git restore.

Comandos de bajo nivel (plomería)

Aunque Git incluye su propia capa de porcelana, sus comandos de bajo nivel son suficientes para soportar desarrollo de porcelanas alternativas. Desarrolladores de tales porcelanas podrían comenzar leyendo acerca de git-update-index[1] y git-read-tree[1].

La interfase (entrada, salida, conjunto de opciones y la semántica) a esos comandos de bajo nivel tienen la intención de ser mucho mas estables que comandos a nivel porcelana, porque esos comandos son primordialmente para ser usados por scripts. Por otro lado, la interface a comandos porcelana esta sujeta a cambios con el fin de mejorar la experiencia de usuario final.

La descripción siguiente divide los comandos de bajo nivel en comandos que manipulan objetos (en el repositorio, índice y á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]: Aplicar un parche a ficheros y/o al índice.
git-checkout-index[1]: Copiar ficheros del índice al árbol de trabajo.
git-commit-graph[1]: Escribe y verifica los ficheros de confirmación-grafo Git.
git-commit-tree[1]: Crea un nuevo objeto commit.
git-hash-object[1]: Computa ID de objeto y opcionalmente crea un blob de un fichero.
git-index-pack[1]: Construye un fichero de índice de paquete para un archivo empaquetado existente.
git-merge-file[1]: Ejecuta una fusión de tres vías en un fichero.
git-merge-index[1]: Ejecuta una fusión para ficheros que la necesitan.
git-mktag[1]: Crea un objeto tag con validación adicional.
git-mktree[1]: Construir un objeto árbol a partir de un texto en formato ls-tree.
git-multi-pack-index[1]: Escribe y verifica índices-multi-paquete.
git-pack-objects[1]: Crea un archivo empaquetado de objetos.
git-prune-packed[1]: Remover objetos extra que ya están en ficheros empaquetados.
git-read-tree[1]: Lee información del árbol en el índice.
git-symbolic-ref[1]: Lee, modifica y borra referencias simbólicas.
git-unpack-objects[1]: Desempaqueta objetos de un archivo empaquetado.
git-update-index[1]: Registra contenidos de ficheros en el árbol de trabajo al índice.
git-update-ref[1]: Actualiza el nombre del objeto almacenado en una referencia de forma segura.
git-write-tree[1]: Crea un objeto árbol del índice actual.

Comandos de interrogación

git-cat-file[1]: Proporciona contenido o tipo y tamaño de información para objetos del repositorio.
git-cherry[1]: Encuentre los commits que aún no han sido aplicados al upstream.
git-diff-files[1]: Compara ficheros del árbol de trabajo y del índice.
git-diff-index[1]: Compara un árbol con el árbol de trabajo o índice.
git-diff-tree[1]: Compara el contenido y el modo de blobs encontrados a través de dos objetos del árbol.
git-for-each-ref[1]: Extrae información de cada referencia.
git-for-each-repo[1]: Ejecutar un comando de Git en una lista de repositorios.
git-get-tar-commit-id[1]: Extrae el ID de confirmación de un archivo creado usando git-archive.
git-ls-files[1]: Muestra información sobre ficheros en el índice y el árbol de trabajo.
git-ls-remote[1]: Lista las referencias de un repositorio remoto.
git-ls-tree[1]: Lista los contenidos de un objeto árbol.
git-merge-base[1]: Encuentra los mejores ancestros comunes posibles para una fusión.
git-name-rev[1]: Encontrar nombres simbólicos para revs dados.
git-pack-redundant[1]: Encuentra ficheros empaquetados redundantes.
git-rev-list[1]: Lista objetos commit en orden cronológico inverso.
git-rev-parse[1]: Seleccionar y masajear los parámetros.
git-show-index[1]: Mostrar el índice de archivo empaquetado.
git-show-ref[1]: Listar referencias en un repositorio local.
git-unpack-file[1]: Crea un fichero temporal con el contenido de un blob.
git-var[1]: Mostrar una variable lógica de Git.
git-verify-pack[1]: Valida archivos Git empaquetados.

En general, los comandos de interrogación no tocan los ficheros en el árbol de trabajo.

Sincronizando repositorios

git-daemon[1]: Un servidor realmente simple para repositorios Git.
git-fetch-pack[1]: Descarga objetos faltantes de otro repositorio.
git-http-backend[1]: Implementación de lado de servidor de Git por HTTP.
git-send-pack[1]: Empujar objetos por protocolo Git a otro repositorio.
git-update-server-info[1]: Actualiza el fichero de información auxiliar para ayudar a los servidores tontos.

Los siguientes son comandos auxiliares usados por los anteriores; usuarios finales típicamente no los usan directamente.

git-http-fetch[1]: Descarga de un repositorio Git remoto vía HTTP.
git-http-push[1]: Empuja objetos por HTTP/DAV a otro repositorio.
git-receive-pack[1]: Recibir lo que es empujado en el respositorio.
git-shell[1]: Shell de inicio de sesión restringido para acceso SSH exclusivo de Git.
git-upload-archive[1]: Enviar archivo de vuelta a git-archive.
git-upload-pack[1]: Enviar objetos empaquetados de vuelta a git-fetch-pack.

Comandos auxiliares internos

Estos son comandos auxiliares internos usados por otros comandos; usuarios finales típicamente no los usan directamente.

git-check-attr[1]: Mostrar información de gitattributes.
git-check-ignore[1]: Depurar gitignore / exclude files.
git-check-mailmap[1]: Mostrar nombres canónicos y direcciones de correo de contactos.
git-check-ref-format[1]: Asegura que un nombre de referencia esté bien formado.
git-column[1]: Mostrar data en columnas.
git-credential[1]: Obtener y guardar credenciales de usuario.
git-credential-cache[1]: Auxiliar para almacenar temporalmente contraseñas en memoria.
git-credential-store[1]: Auxiliar para guardar credenciales en disco.
git-fmt-merge-msg[1]: Produce un mensaje de commit para fusión.
git-hook[1]: Ejecutar hooks de git.
git-interpret-trailers[1]: Agregar o analizar información estructurada en mensajes de commit.
git-mailinfo[1]: Extraer parche y autoría de un único mensaje de e-mail.
git-mailsplit[1]: Programa simple de UNIX divisor de mbox.
git-merge-one-file[1]: El programa de ayuda estándar para usar con git-merge-index.
git-patch-id[1]: Calcular ID único para un parche.
git-sh-i18n[1]: El código de configuración i18n de Git para scripts de shell.
git-sh-setup[1]: Código de configuración de script de shell común de Git.
git-stripspace[1]: Eliminar espacio en blanco innecesario.

Guías

Las páginas de documentación siguientes son guías acerca de conceptos de Git.

gitcore-tutorial[7]: Un tutorial de Git esencial para desarrolladores.
gitcredentials[7]: Proporcionar nombres de usuario y contraseñas a Git.
gitcvs-migration[7]: Git para usuarios de CVS.
gitdiffcore[7]: Afinar la salida de diff.
giteveryday[7]: Un conjunto mínimo útil de comandos cotidianos de Git.
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]: Un tutorial de introducción a Git.
gittutorial-2[7]: Un tutorial de introducción a Git: parte dos.
gitworkflows[7]: Una visión general de flujos de trabajo recomendados con Git.

Interfases de repositorio, comando y fichero

Esta documentación discute interfases de repositorio y comando con las cuales se espera que los usuarios interactúen directamente. Ver --user-formats en git-help[1] para mas detalles sobre los criterios.

Warning

Missing es/cmds-userinterfaces.txt

See original version for this content.

Formatos de fichero, protocolos y otras interfaces para el desarrollador

Esta documentación discute los formatos de fichero, protocolos sobre-el-cable y otras interfases de desarrollador git. Ver --developer-interfaces en git-help[1].

Warning

Missing es/cmds-developerinterfaces.txt

See original version for this content.

Mecanismo de Configuración

Git usa un formato de texto simple para almacenar personalizaciones que son por repositorio y por usuario. Tal fichero de configuración puede parecerse a éste:

#
# Un caracter '#' o ';' indica un comentario.
#

; variables esenciales
[core]
	; No confiar modos de fichero
	filemode = false

; identidad del usuario
[user]
	name = "Junio C Hamano"
	email = "gitster@pobox.com"

Varios comandos leen del fichero de configuración y ajustan su operación respectivamente. Ver git-config[1] para una lista y mas detalles acerca del mecanismo de configuración.

Terminología Identificadora

<objeto>: Indica el nombre del objeto para cualquier tipo de objeto.
<blob>: Indica un nombre de objeto blob.
<árbol>: Indica un nombre de objeto árbol.
<confirmación>: Indica un nombre de objeto commit.
<árbol-ismo>: Indica un nombre de objeto árbol, commit o etiqueta. Un comando que toma un argumento <arbol-ismo> quiere operar en última instancia sobre un objeto <árbol> pero automáticamente desreferencia objetos <commit> y <etiqueta> que apuntan a un <árbol>.
<confirmacion-ismo>: Indica un nombre de objeto commit o etiqueta. Un comando que toma un argumento <commit-ish> de último quiere operar sobre un objeto <commit> pero automáticamente desreferencia objetos <etiqueta> que apunten a un <commit>.
<tipo>: Indica que un tipo de objeto es requerido. Actualmente uno de: blob, tree, commit, o tag.
<fichero>: Indica un nombre de fichero - casi siempre relativo a la raíz de la estructura del árbol que describe GIT_INDEX_FILE.

Identificadores Simbólicos

Cualquier comando Git que acepte cualquier <objeto> también puede usar la notación simbólica siguiente:

HEAD: indica la cabeza de la rama actual.
<etiqueta>: un nombre valido de etiqueta (ej. una referencia refs/tags/<etiqueta>).
<head>: un nombre valido de cabeza (ej. una referencia refs/heads/<cabeza>).

Para una lista completa de las maneras de deletrear nombres de objetos ver la sección "ESPECIFICANDO REVISIONES" en gitrevisions[7].

Estructura de Ficheros/Directorios

Por favor ver el documento gitrepository-layout[5].

Leer githooks[5] para mas detalles sobre cada gancho.

Gestores de Código Fuente de alto nivel pueden proveer y manejar información adicional en el $GIT_DIR.

Terminología

Favor de ver gitglossary[7].

Variables de Ambiente

Varios comandos de Git prestan atención a variables de ambiente y alteran su funcionamiento. Las variables de ambiente marcadas como "Booleanas" toman sus valores de la misma manera que variables de configuración booleanas, ej. "true", "yes", "on" y números positivos se consideran como "yes".

Aquí las variables:

El Repositorio Git

Esas variables de ambiente aplican a todos los comandos de núcleo de Git. Nótese bien: cabe notar que pueden ser usadas/sobremontadas por Gestores de Código Fuente asentados sobre Git, entonces tener cuidado si se usa un front-end foráneo.

GIT_INDEX_FILE: Esta variable de ambiente especifica un fichero de índice alterno. Si no se especifica, se usa el valor predeterminado en $GIT_DIR/index.
GIT_INDEX_VERSION: Esta variable de ambiente especifica qué versión de índice se usa al escribir el fichero de índice. No afectará ficheros de índice existentes. De manera predeterminada se usa la versión 2 o 3 del fichero de índice. Ver git-update-index[1] para mas información.
GIT_OBJECT_DIRECTORY: Si el directorio de almacenamiento de objetos se especifica por medio de esta variable de ambiente, entonces los directorios sha1 se crean debajo - de lo contrario se usa el directorio predeterminado $GIT_DIR/objects.
GIT_ALTERNATE_OBJECT_DIRECTORIES: Debido a la naturaleza inmutable de los objetos Git, objetos antiguos pueden ser archivados en directorios compartidos de sólo lectura. Esta variable especifica una lista separada por ":" (en Windows separada por ";") de directorios de objetos Git que pueden ser usados para buscar objetos Git. Objetos nuevos no serán escritos en esos directorios.

Entradas que comienzan con " (comilla doble) serán interpretadas como rutas entrecomilladas estilo C, quitando la comillas dobles iniciales y finales y respetando escapes de diagonal invertida. Ej. el valor "ruta-con-\"-y-:-en-ella":ruta-vainilla tiene dos rutas: ruta-con-"-y-:-en-ella y ruta-vainilla.
GIT_DIR: Si la variable de ambiente GIT_DIR esta asignada entonces especifica una ruta para usarse en lugar de la predeterminada .git para la base del repositorio. La opción de línea de comando --git-dir también asigna éste valor.
GIT_WORK_TREE: Asigna la ruta de la raíz del árbol de trabajo. También puede controlarse con la opción de línea de comando --work-tree y la variable de configuración core.worktree.
GIT_NAMESPACE: Asigna el espacio de nombres de Git; ver gitnamespaces[7] para detalles. La opción de línea de comandos --namespace también asigna éste valor.
GIT_CEILING_DIRECTORIES: Esta debe ser una lista separada por dos puntos de rutas absolutas. Si se asigna, es una lista de directorios en los que Git no debería hacer chdir al buscar un directorio de repositorio (útil para excluir directorios de red de carga lenta). No excluirá el directorio de trabajo actual o un GIT_DIR configurado en línea de comandos o en el ambiente. Normalmente, Git tiene que leer las entradas en esta lista y resolver cualquier enlace simbólico que pueda estar presente con el fin de compararlos con el directorio actual. Sin embargo, si incluso éste acceso es lento, puedes agregar a la lista una entrada vacía para indicarle a Git que las entradas subsecuentes no son enlaces simbólicos y que por lo tanto no necesitan resolverse; ej. GIT_CEILING_DIRECTORIES=/posible/enlace::/no/enlace/muy/lento.
GIT_DISCOVERY_ACROSS_FILESYSTEM: Cuando se ejecuta en un directorio que no tiene directorio de repositorio ".git", Git intenta encontrarlo en los directorios padres para encontrar el tope del directorio de trabajo, pero predeterminadamente no cruza los límites del sistema de ficheros. A esta variable de ambiente booleana se le puede asignar true para indicarle a Git que no pare en los límites del sistema operativo. Así como GIT_CEILING_DIRECTORIES, no afectará un directorio de repositorio explícito configurado en GIT_DIR o en la línea de comandos.
GIT_COMMON_DIR: Si a esta variable se le asigna una ruta, los ficheros que no son del árbol de trabajo que normalmente están en $GIT_DIR serán tomados en cambio de esta ruta. Ficheros específicos del árbol de trabajo como HEAD y index se toman de $GIT_DIR. Ver gitrepository-layout[5] y git-worktree[1] para detalles. Esta variable tiene precedencia mas baja que otras variables de ruta como GIT_INDEX_FILE, GIT_OBJECT_DITECTORY…
GIT_DEFAULT_HASH: Si se configura esta variable, el algoritmo predeterminado de hash para repositorios nuevos será asignado con éste valor. Al clonar se ignora este valor y siempre se usa la configuración del repositorio remoto. El predeterminado es "sha1". Ver --object-format en git-init[1].

Confirmaciones de Git

GIT_AUTHOR_NAME: El nombre legible al humano usado en la identidad del autor cuando se crean objetos confirmación o etiqueta, o cuando se escriben reflogs. Anula las configuraciones user.name y author.name.
GIT_AUTHOR_EMAIL: La dirección de correo electrónico usada en la identidad del autor cuando se crean objetos confirmación o etiqueta, o cuando se escriben reflogs. Anula las configuraciones user.email y author.email.
GIT_AUTHOR_DATE: La fecha usada para la identidad del autor cuando se crean objetos confirmación o etiqueta, o cuando se escriben reflogs. Ver git-commit[1] para formatos válidos.
GIT_COMMITTER_NAME: El nombre legible al humano usado en la identidad del confirmante cuando se crean objetos confirmación o etiqueta, o cuando se escriben referencias de bitácora. Anula las configuraciones de user.name y committer.name.
GIT_COMMITTER_EMAIL: La dirección de correo electrónico usada en la identidad del autor cuando se crean objetos confirmación o etiqueta, o cuando se escriben referencias de bitácora. Anula las configuraciones de user.email y committer.email.
GIT_COMMITTER_DATE: La fecha usada para la identidad del confirmante cuando se crean objetos confirmación o etiqueta, o cuando se escriben referencias de bitácora. Ver git-commit[1] para formatos válidos.
EMAIL: La dirección de correo electrónico usada en las identidades de autor y confirmante si no se ha asignado alguna otra variable de ambiente o configuración relevante.

Diffs de Git

GIT_DIFF_OPTS

La única configuración válida es "--unified=??" o "-u??" para asignar el número de líneas de contexto a mostrarse cuando se crea un diff unificado. Toma precedencia sobre cualquier valor de opción "-U" o "--unified" pasada en la línea de comandos del diff Git.

GIT_EXTERNAL_DIFF

Cuando se asigna la variable de ambiente GIT_EXTERNAL_DIFF, se llama al programa nombrado en ella para generar diffs, y Git no usa su maquinaria de diff interconstruida. Para una ruta que es agregada, removida, o modificada, se llama a GIT_EXTERNAL_DIFF con 7 parámetros:

ruta fichero-anterior hex-anterior modo-anterior fichero-nuevo hex-nuevo modo-nuevo

donde:

fichero-<anterior|nuevo>

son los ficheros que GIT_EXTERNAL_DIFF puede usar para leer el contenido de <anterior|nuevo>,

hex-<anterior|nuevo>

son los hash SHA1 de 40 dígitos hexadecimal,

modo-<anterior|nuevo>

son la representación octal de los modos del fichero.

Los parámetros fichero pueden apuntar al fichero de trabajo del usuario (ej. fichero-nuevo en "git-diff-files"), /dev/null(ej. fichero-anterior cuando se agrega un fichero nuevo), o un fichero temporal (ej. fichero-anterior en el índice). GIT_EXTERNAL_DIFF no debería preocuparse por desenlazar el fichero temporal — es eliminado cuando GIT_EXTERNAL_DIFF sale.

Para una ruta no-fusionada, se llama a GIT_EXTERNAL_DIFF con 1 parámetro, <ruta>.

Para cada ruta se llama a GIT_EXTERNAL_DIFF, dos variables de ambiente se asignan, GIT_DIFF_PATH_COUNTER y GIT_DIFF_PATH_TOTAL.

GIT_DIFF_PATH_COUNTER

Un contador base 1 incrementado por uno por cada ruta.

GIT_DIFF_PATH_TOTAL

El número total de rutas.

otras

GIT_MERGE_VERBOSITY: Un número controlando la cantidad de salida mostrada por la estrategia de fusión recursiva. Anula merge.verbosity. Ver git-merge[1]
GIT_PAGER: Esta variable de ambiente anula $PAGER. Si se le asigna una cadena vacía o el valor "cat", Git no lanzará un paginador. Ver también la opción core.pager en git-config[1].
GIT_PROGRESS_DELAY: Un número controlando cuántos segundos retardar antes de mostrar indicadores opcionales de progreso. Predeterminado a 2.
GIT_EDITOR: Esta variable de ambiente anula $EDITOR y $VISUAL. Es usada por varios comandos Git cuando en modo interactivo se va a lanzar un editor. Ver también git-var[1] y la opción core.editor en git-config[1].
GIT_SEQUENCE_EDITOR: Esta variable de ambiente anula el editor de Git configurado cuando se edita la lista de pendientes en un rebase interactivo. Ver también git-rebase[1] y la opción sequence.editor en git-config[1].
GIT_SSH
GIT_SSH_COMMAND: Si cualquiera de estas variables de ambiente se asigna entonces git fetch y git push usarán el comando especificado en lugar de ssh cuando se necesite conectar a un sistema remoto. Los parámetros de línea de comandos pasados al comando configurado los determina la variante de ssh. Ver la opción ssh.variant en git-config[1] para detalles.

$GIT_SSH_COMMAND toma precedencia sobre $GIT_SSH, y es interpretado por el shell, el cual permite argumentos adicionales a incluirse. Por otro lado, $GIT_SSH debe ser sólo la ruta al programa (el cual puede ser un script de shell envolvente, si se necesitan argumentos adicionales).

Usualmente es mas fácil configurar cualquier opción deseada por medio de tu fichero personal .ssh/config. Por favor consulta tu documentación de ssh para mayores detalles.
GIT_SSH_VARIANT: Si se asigna ésta variable de ambiente, anula que Git autodetecte si GIT_SSH/GIT_SSH_COMMAND/core.sshCommand se refiere a OpenSSH, link o tortoiseplink. Esta variable anula la configuración ssh.variant que sirve para el mismo propósito.
GIT_SSL_NO_VERIFY: Asignando y exportando ésta variable de ambiente a cualquier valor le dice a Git que no verifique el certificado SSL cuando haga fetch o push sobre HTTPS.
GIT_ATTR_SOURCE: Asigna el árbol-ismo de donde se leerán gitattributes.
GIT_ASKPASS: Si se asigna esta variable de ambiente, entonces los comandos Git que necesiten recibir contraseñas o frases de acceso (ej. para autenticación HTTP o IMAP) llamarán a éste programa con una línea de entrada apropiada como argumento de línea de comandos y leer la contraseña de su STDOUT. Ver también la opción core.askPass en git-config[1].
GIT_TERMINAL_PROMPT: Si se asigna ésta variable de ambiente booleana, git no usará una línea de entrada en la terminal (ej. cuando se solicite una autenticación HTTP).
GIT_CONFIG_GLOBAL
GIT_CONFIG_SYSTEM: Toma la configuración de los ficheros dados en lugar de los ficheros de configuración global o a nivel sistema. Si GIT_CONFIG_SYSTEM es asignado, el fichero de configuración de sistema definido en tiempo de construcción (usualmente /etc/gitconfig) no será leído. En el mismo sentido, si GIT_CONFIG_GLOBAL es asignado, ninguno de $HOME/.gitconfig o $XDG_CONFIG_HOME/git/config será leído. Se le puede asignar /dev/null para saltar la lectura de ficheros de configuración del nivel respectivo.
GIT_CONFIG_NOSYSTEM: Si saltar la lectura de ajustes del fichero de ámbito de sistema $(prefijo)/etc/gitconfig. Esta variable de ambiente booleana puede ser usada junto con $HOME y $XDG_CONFIG_HOME para crear un ambiente predecible para un script quisquilloso, o puedes asignarle verdadero para evitar temporalmente usar un fichero defectuoso /etc/gitconfig mientras se espera a alguien con premisos suficientes para arreglarlo.
GIT_FLUSH: Si a esta variable de ambiente se le asigna "1", entonces comandos como git-blame (en modo incremental), git rev-list, git log, git check-attar y git check-ignore forzarán un desalojo del flujo de salida después de que cada registro sea desalojado. Si a esta variable se le asigna "0", la salida de esos comandos se hará usando búfer de E/S por completo. Si no se asigna esta variable de ambiente, Git elegirá desalojo por búfer u orientada a registro con base en si la salida estándar parece ser redirigida a un fichero o no.
GIT_TRACE: Habilita mensajes de rastreo general, ej. expansión de alias, ejecución de comando interconstruido y ejecución de comando externo.

Si a esta variable se le asigna "1", "2" o "true" (comparación sensible a mayúsculas), mensajes de rastreo se imprimirán en stderr.

Si a esta variable se le asigna un valor entero mayor a 2 y menor a 10 (estrictamente) entonces Git interpretará éste valor como un descriptor de fichero abierto e intentará escribir mensajes de rastro en éste descriptor de fichero.

Alternativamente, si a la variable se le asigna un ruta absoluta (iniciando con un caracter /), Git interpretará esta como una ruta de fichero e intentará adicionar mensajes de rastreo en él.

Desasignando la variable, o asignándole vacío, "0" o "false" (sensible a mayúsculas) deshabilita mensajes de rastreo.
GIT_TRACE_FSMONITOR: Habilita mensajes de rastreo para la extensión de monitoreo de sistema de ficheros. Ver GIT_TRACE para las opciones de salida de rastreo disponibles.
GIT_TRACE_PACK_ACCESS: Habilita mensajes de rastreo para todos los accesos a cualquier paquete. Para cada acceso, se registra el nombre de fichero de paquete y un corrimiento. Esto puede ser de ayuda para diagnosticar algunos problemas de desempeño relacionados con paquetes. Ver GIT_TRACE para opciones de rastreo disponibles.
GIT_TRACE_PACKET: Habilita mensajes de rastreo para todos los paquetes que vienen de o van hacia un programa dado. Esto puede ayudar con depuración de negociación de objetos u otros problemas de protocolo. El rastreo esta apagado en un paquete que comienza con "PACK" (pero ver GIT_TRACE_PACKFILE mas abajo). Ver GIT_TRACE para opciones de salida de rastreo disponibles.
GIT_TRACE_PACKFILE: Habilita el rastreo de fichero de paquete enviados o recibidos por un programa dado. Contrario a otras salidas de rastreo, este rastreo es verboso: sin encabezados, y sin entrecomillar datos binarios. Seguramente querrás dirigirla a un fichero (ej. GIT_TRACE_PACKFILE=/tmp/mi.paquete) mas que desplegarla en la terminal o mezclarla con otra salida de rastreo.

Note que esto esta actualmente implementado sólo para el lado del cliente de clonaciones y fetchs.
GIT_TRACE_PERFORMANCE: Habilita mensajes de rastreo relacionados con desempeño, ej. tiempo total de ejecución de cada comando Git. Ver GIT_TRACE para opciones de salida de rastreo disponibles.
GIT_TRACE_REFS: Habilita mensajes de rastreo para operaciones en la base de datos de referencias. Ver GIT_TRACE para opciones de salida de rastreo disponibles.
GIT_TRACE_SETUP: Habilita mensajes de rastreo imprimiendo el .git, el árbol de trabajo y el directorio de trabajo actual después que Git haya terminado su fase de configuración. Ver GIT_TRACE para opciones de salida de rastreo disponibles.
GIT_TRACE_SHALLOW: Habilita mensajes de rastreo que pueden ayudar a depurar fetch / clonación de repositorios superficiales. Ver GIT_TRACE para opciones de salida de rastreo disponibles.
GIT_TRACE_CURL: Habilita un volcado de rastreo completo de curl de todos los datos entrantes y salientes, incluyendo información descriptiva, del protocolo de transporte git. Es similar a hacer curl con --trace-ascii desde la línea de comandos. Ver GIT_TRACE para opciones de salida de rastreo disponibles.
GIT_TRACE_CURL_NO_DATA: Cuando se habilita un rastreo curl (ver GIT_TRACE_CURL arriba), no vuelca los datos (esto es, sólo vuelca líneas de información y cabeceras).
GIT_TRACE2: Habilita mensajes de rastreo mas detallados desde la librería "trace2". La salida de GIT_TRACE2 es un formato simple basado en texto para legibilidad humana.

Si a esta variable se le asigna "1", "2" o "true" (comparación sensible a mayúsculas), mensajes de rastreo se imprimirán en stderr.

Si a esta variable se le asigna un valor entero mayor a 2 y menor a 10 (estrictamente) entonces Git interpretará éste valor como un descriptor de fichero abierto e intentará escribir mensajes de rastro en éste descriptor de fichero.

Alternativamente, si a la variable se le asigna una ruta absoluta (que comience con el caracter /), Git la interpretará como una ruta de fichero e intentará añadir mensajes de rastreo en él. Si la ruta ya existe y es un directorio, los mensajes de rastreo serán escritos en ficheros (uno por proceso) en ese directorio, nombrados de acuerdo al último componente del SID y un contador opcional (para evitar colisiones de nombre de fichero).

Además, si a la variable se le asigna af_unix:[<tipo-de-socket>:]<nombre-de-ruta-absoluta>, Git intentará abrir la ruta como un Socket de Dominio de Unix. El tipo de socket puede ser stream o dgram.

Desasignando la variable, o asignándole vacío, "0" o "false" (sensible a mayúsculas) deshabilita mensajes de rastreo.

Ver documentación de Trace2 para detalles completos.
GIT_TRACE2_EVENT: Este ajuste escribe un formato basado en JSON que es adecuado para interpretación por máquina. Ver GIT_TRACE2 para opciones disponibles de salida de rastreo y documentación de Trace2 para detalles completos.
GIT_TRACE2_PERF: Además de los mensajes basados en texto disponibles en GIT_TRACE2, este ajuste escribe un formato basado en columnas para entender regiones anidadas. Ver GIT_TRACE para opciones de salida de rastreo disponibles y documentación de Trace2 para detalles completos.
GIT_TRACE_REDACT: Predeterminadamente, cuando se activa rastreo, Git redacta los valores de cookies, el encabezado "Authorization", el encabezado "Proxy-Authorization:" y fichero empaquetado de URIs. Asigne false a esta variable de ambiente booleana para prevenir esta redacción.
GIT_LITERAL_PATHSPECS: Asignando verdadero a esta variable de ambiente booleana causará que Git trate a todas las especificaciones de ruta literalmente, mas que como patrones glob. Por ejemplo, corriendo GIT_LITERAL_PATHSPECS=1 git log -- '*.c' buscará confirmaciones que toquen la ruta *.c, no cualquier ruta que coincida con el glob *.c. Querrías esto si proporcionas rutas literales a Git (ej., rutas que te hayan resultado previamente de git ls-tree, --raw salida de diff, etc.).
GIT_GLOB_PATHSPECS: Asignando verdadero a esta variable de ambiente booleana causará que Git trate todas las especificaciones de ruta como patrones glob (también conocido como magia "glob").
GIT_NOGLOB_PATHSPECS: Asignando verdadero a esta variable de ambiente booleana causará que Git trate a todas la especificaciones de ruta como literales (también conocido como magia "literal").
GIT_ICASE_PATHSPECS: Asignando verdadero a esta variable de ambiente booleana causará que Git trate a todas las especificaciones de ruta como insensibles a mayúsculas.
GIT_REFLOG_ACTION: Cuando se actualiza una referencia, se crean entradas de reflog para dar seguimiento a la razón por la cual la referencia fue actualizada (la cual es típicamente el nombre de un comando de alto nivel que actualizó la referencia), además de los valores anterior y nuevo de la referencia. Un comando porcelana en un script puede usar la función auxiliar set_reflog_action en git-sh-setup para asignar su nombre a esta variable cuando es invocada por el usuario final como el comando de máximo nivel, para ser registrado en el cuerpo del reflog.
GIT_REF_PARANOIA: Si se asigna falso a esta variable de ambiente booleana, ignora referencias rotas o mal nombradas cuando se itera por la lista de referencias. Normalmente Git intentará incluir cualquiera de tales referencias, lo cual puede provocar que algunas operaciones fallen. Esto es usualmente preferible, ya que es mejor abortar operaciones potencialmente destructivas (ej. git-prune[1]) en vez de ignorar referencias rotas (y por lo tanto considerar que no vale guardar el historial al que apuntan). El valor predeterminado es 1 (ej. ser paranoico en la detección y abortar todas las operaciones). Normalmente no deberías asignarle 0, pero puede ser útil cuando se intenta salvar datos de un repositorio corrupto.
GIT_ALLOW_PROTOCOL: Si se le asigna una lista de protocolos separada por dos puntos, se comporta como si a protocolo.allow se le asigna never, y cada uno de los protocolos listados protocol.<nombre>.allow tuviera asignado always (anulando cualquier configuración existente). Ver la descripción de protocol.allow en git-config[1] para mas detalles.
GIT_PROTOCOL_FROM_USER: Asigne falso a esta variable de ambiente booleana para prevenir el uso de protocolos por fetch/push/clone los cuales están configurados en el estado user. Esto es útil para restringir inicialización recursiva de submodulos desde un repositorio no confiable o para programas que alimenten URLs potencialmente no confiables a comandos git. Ver git-config[1] para mas detalles.
GIT_PROTOCOL: Sólo para uso interno. Usado en el protocolo de estrechamiento de manos de conexión. Contiene una lista de claves separadas por dos puntos : con valores opcionales clave[=valor]. La presencia de claves y valores desconocidos debe ser ignorada.

Note que servidores pueden necesitar ser configurados para permitir que esta variable sobrepase algunos transportes. Será propagada automáticamente cuando se accesen repositorios locales (ej. file:// o una ruta del sistema de ficheros), así como sobre el protocolo git://. Para git-sobre-http, debería funcionar automáticamente en la mayoría de las configuraciones, pero ver la discusión en git-http-backend[1]. Para git-sobre-ssh, el servidor ssh puede necesitar ser configurado para permitir a los clientes pasar esta variable (ej. usando AcceptEnv GIT_PROTOCOL con OpenSSH).

Esta configuración es opcional. Si la variable no es propagada, entonces los clientes caerán de vuelta a protocolo "v0" original (pero pueden perder algunas mejoras de desempeño o características). Esta variable afecta actualmente únicamente a clonados y fetchs; aún no es usada para empujes (pero podría serlo en el futuro).
GIT_OPTIONAL_LOCKS: Si se le asigna falso a esta variable de ambiente, Git completará cualquier petición solicitada sin hacer cualquier sub-operación opcional que requiera un bloqueo. Por ejemplo, prevendrá que git status refresque el índice como efecto colateral. Esto es útil para procesos corriendo en segundo plano que no quieran provocar contención de bloqueos con otras operaciones en el repositorio. Es predeterminada a 1.
GIT_REDIRECT_STDIN
GIT_REDIRECT_STDOUT
GIT_REDIRECT_STDERR: Sólo Windows: permite redirigir la entrada/salida/error estándar a las rutas especificadas por la variables de ambiente. Esto es particularmente útil en aplicaciones multi-hilo donde no es opción la forma canónica para pasar manejadores estándar mediante CreateProcess() ya que requeriría que los manejadores sean marcados como heredables (y consecuentemente todos los procesos derivados los heredarán, posiblemente bloqueando operaciones regulares de Git). El caso de uso primordial es usar pipes nombradas para comunicación (ej. \\.\pipe\mi-stdin-git-123).

Dos valores especiales son soportados: off simplemente cerrará el manejador estándar correspondiente, y si GIT_REDIRECT_STDERR es 2>&1, error estándar será redireccionado al mismo manejador que la salida estándar.
GIT_PRINT_SHA1_ELLIPSIS (obsoleto): Si se le asigna yes, imprime una elipsis después de una valor (abreviado) SHA-1. Esto afecta indicaciones de HEADs separadas (git-checkout[1]) y la salida bruta de diff (git-diff[1]). Ya no se considera adecuado imprimir una elipsis en los casos mencionados y es probable que su soporte sea removido en el futuro previsible (junto con la variable).

Discusión

Mas detalle de lo siguiente esta disponible en el capítulo de Conceptos de Git del Manual de usuario y gitcore-tutorial[7].

Un proyecto Git consiste normalmente de un directorio de trabajo con un subdirectorio ".git" en su nivel mas alto. El directorio .git contiene, entre otras cosas, una base de datos de objetos comprimida representando el historial completo del proyecto, un fichero "índice" el cual enlaza ese historial con el contenido actual del directorio de trabajo, y apuntadores nombrados hacia ese historial como etiquetas y cabezas de rama.

La base de datos de objetos contiene objetos de tres tipos principales: blobs, que contienen datos de fichero; árboles, los cuales apuntan a blobs y otros árboles para formar jerarquías de directorio; y confirmaciones, las que -cada una- referencían a un solo árbol y algún número de confirmaciones padre.

La confirmación, equivalente a lo que otros sistemas llaman "conjunto de cambios" o "versión", representa un paso en el historial del proyecto, y cada padre representa un paso inmediato anterior. Confirmaciones con mas de un padre representan fusiones de líneas independientes de desarrollo.

Todos los objetos se nombran con un hash SHA-1 de su contenido, normalmente escrito como una cadena de 40 dígitos hexadecimales. Dichos nombres son globalmente únicos. El historial completo hasta una confirmación puede ser garantizada firmando sólo esa confirmación. Para éste propósito, se proporciona un cuarto tipo de objeto, la etiqueta.

Recién creados, los objetos se almacenan en ficheros individuales, pero por eficiencia, posteriormente pueden ser comprimidos en conjunto en "paquetes de ficheros".

Apuntadores nombrados llamados referencias marcan puntos interesantes en el historial. Una referencia puede contener el nombre SHA-1 de un objeto o el nombre de otra referencia. Referencias con nombres que comienzan con ref/head/ contienen el nombre SHA-1 de la confirmación más reciente (o "head") de una rama bajo desarrollo. Los nombres SHA-1 de etiquetas de interés se almacenan bajo ref/tags/. Una referencia especial llamada HEAD contiene el nombre de la rama actualmente en revisión.

El fichero í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 fichero como en la cabeza de la rama actual. Los atributos (última hora de modificación, tamaño, etc.) se toman del fichero correspondiente en el árbol de trabajo. Cambios subsecuentes al árbol de trabajo se pueden encontrar al comparar esos atributos. El índice puede ser actualizado con contenido nuevo, y nuevas confirmaciones pueden ser creadas a partir del contenido almacenado en el índice.

El índice también es capaz de almacenar entradas múltiples (llamadas "etapas") para cada nombre de ruta dado. Esas etapas se usan para mantener las varias versiones sin fusionar de un fichero cuando una fusión está en progreso.

MAS DOCUMENTACIÓN

Ver las referencias en la sección "descripción" para comenzar a usar Git. Lo siguiente es probablemente mas detalle del necesario para un usuario primerizo.

El capítulo de conceptos de Git del manual de usuario y gitcore-tutorial[7] ambos dan introducciones a la arquitectura subyacente de Git.

Ver gitworkflows[7] para un vistazo a los flujos de trabajo recomendados.

Ver también los documentos Cómo hacer para algunos ejemplos útiles.

Lo interno se documenta en la Documentación de la API de Git.

Usuarios migrando de CVS querrían leer gitcvs-migration[7].

Autores

Git lo comenzó Linus Torvalds, y actualmente es mantenido por Junio C Hamano. Numerosas contribuciones han venido de la lista de correos de Git <git@vger.kernel.org>. http://www.openhub.net/p/git/contributors/summary tiene una lista mas completa de contribuyentes.

Si tienes un clon mismo de git.git, la salida de git-shortlog[1] y git-blame[1] puede mostrarte los autores de partes específicas del proyecto.

Reportando Errores

Reporta errores en la lista de correo de Git <git@vger.kernel.org> donde se hace principalmente el desarrollo y mantenimiento. No tienes que estar suscrito en la lista para enviar un mensaje ahí. Ver el archivo de la lista en https://lore.kernel.org/git para reportes de error anteriores y otras discusiones.

Asuntos relevantes para la seguridad deben ser revelados en privado a la lista de correos de seguridad de Git <git-security@googlegroups.com>.

VER TAMBIÉN

gittutorial[7], gittutorial-2[7], giteveryday[7], gitcvs-migration[7], gitglossary[7], gitcore-tutorial[7], gitcli[7], El Manual de Usuario de Git, gitworkflows[7]

Parte de la suite de git[1]

Setup and Config

Getting and Creating Projects

Basic Snapshotting

Branching and Merging

Sharing and Updating Projects

Inspection and Comparison

Patching

Debugging

Email

External Systems

Server Admin

Guides

Administration

Plumbing Commands