Mediante el mecanismo de alternos, un repositorio puede heredar parte de su base de datos de objetos de otra base de datos de objetos, la cual es llamada "alterna".

Normalmente, un repositorio básico es un directory apropiadamente nombrado con un sufijo .git`que no tiene una copia local en checkout de cualquiera de los ficheros bajo control de revisión. Esto es, todos los ficheros administrativos y de control de Git que normalmente estarían presentes en el sub-directorio oculto `.git están presentes en el directorio repository.git y no hay otros ficheros presentes y en checkout. Usualmente los publicadores de repositorios públicos hacen repositorios básicos disponibles.

object sin tipo, ej. el contenido de un fichero.

Una "rama" es una línea de desarrollo. El commit más reciente en una rama se refiere a la punta de dicha rama. La punta de la rama es referenced por la head de la rama, la cual se mueve hacia adelante conforme se haga desarrollo adicional en la rama. Un solo repository Git puede contener un número arbitrario de ramas, pero tú working_tree es asociado sólo con una de ellas (la rama "actual" o "en revisión"), y HEAD apunta a esa rama.

Obsoleto por: index.

Una lista de objetos, donde cada object en la lista contiene una referencia a su sucesor (por ejemplo, el sucesor de un commit podría ser uno de sus parents).

BitKeeper/cvsps habla de "commit. Ya que Git no almacena cambios, sino estados, realmente no tiene sentido usar el término "conjunto de cambios" con Git.

La acción de actualizar todo o parte del working tree con un tree object o blob de la object database, y actualizar index y HEAD si el árbol de trabajo completo ha sido apuntado a una branch nueva.

En la jerga de los SCM, "cherry pick" significa escoger un subconjunto de una serie de cambios (típicamente commits) y guardarlos como una nueva serie de cambios encima de una base de código diferente. En Git, esto se hace con el comando "git cherry-pick" para extraer el cambio introducido por un commit existente y guardarlo con base en la punta de la branch actual como un nuevo commit.

A árbol de trabajo esta limpio si corresponde a la revisión referenciada por head actual. Ver también "<<def_dirty,sucio>".

Como sustantivo: Un punto en específico en el historial de Git; el historial completo de un proyecto se representa como un conjunto de commits interrelacionados. La palabra "commit" en Git se usa al igual que en otros sistemas de control de versiones como "revisión" o "versión". También se usa como un atajo para commit object.

Un sinónimo para la estructura del GAD formada por las confirmaciones en la base de datos de objetos, referenciados por puntas de ramas, usando su cadena de confirmaciones ligadas. Esta estructura es el grafo de confirmaciones definitivo. El grafo puede ser representado de otras maneras, ej. el fichero de "confirmación-grafo".

El fichero "confirmación-grafo" (normalmente con guión medio) es un representación suplementaria del grafo de confirmaciones el cual acelera el recorrido del grafo de confirmaciones. El fichero "confirmación-grafo" es almacenado ya sea en el directorio .git/objects/info o en el directorio info de una base de datos alterna de objetos.

Un objeto que contiene la información de una revisión en particular, como ancestros, quien hizo commit, autor, fecha y el árbol de objetos que corresponde al directorio más arriba de la revisión almacenada.

Un objeto confirmación o un objeto que puede ser recursivamente de-referenciado a un objeto confirmación. Todos los siguientes son cuasi-confirmación: un objeto confirmación, un objeto etiqueta que apunta a un objeto confirmación, un objeto etiqueta que apunta a un objeto etiqueta que apunta a un objeto confirmación, etc.

Estructuras de datos y utilerías fundamentales de Git. Expone únicamente herramientas limitadas de gestión de código fuente.

Grafo acíclico dirigido. Los objetos confirmación forman un grafo acíclico dirigido, porque tienen antecesores (dirigido), y el grafo de objetos confirmación es acíclico (no hay cadena que comience y termine con el mismo objeto).

Un objeto inalcanzable el cual no es alcanzable incluso desde otros objetos inalcanzables; un objeto colgado no tiene referencias a él desde cualquier referencia u objeto en el repositorio.

Normalmente HEAD almacena el nombre de una rama, y los comandos que figuran en el historial de HEAD representan operaciones en el historial hacia la punta de la rama a la que apunta HEAD. Sin embargo, Git también te permite hacer checkout de un commit arbitrario que no es necesariamente la punta de una rama en particular. Un HEAD en tal estado se le denomina "separado".

El listado que obtienes con "ls" :-)

Se dice que un árbol de trabajo está "sucio" si contiene modificaciones que no se le han hecho commit en la rama actual.

Una fusión malvada es una fusión que introduce cambios que no aparecen en ningún antecesor.

Un avance-rápido es un tipo especial de fusión donde tienes una revisión y estás "fusionando" los cambios de otra rama que resulta ser descendiente de lo que tienes. En tal caso, no haces una nueva fusión confirmación sino que sólamente actualizas tu rama para apuntar a la misma revisión de la rama que estás fusionando. Esto ocurrirá frecuentemente en una rama de seguimiento-remoto de un repositorio remoto.

Hacer fetch a una rama significa obtener la referencia a HEAD de dicha rama desde un repositorio remoto, para encontrar -y obtener- los objetos faltantes en la base de datos de objetos local. Ver también git-fetch[1].

Linus Torvalds originalmente diseñó Git para ser un sistema de ficheros de espacio de usuario, ej. la infraestructura para contener ficheros y directorios. Eso aseguró la eficiencia y velocidad de Git.

Sinónimo de repository (para gente familiarizada con arch).

Un simple fichero .git en la raíz de un árbol de trabajo que apunta al directorio que es el repositorio real.

Injertos permiten juntar dos lineas distintas de desarrollo al guardar información falsa de antecesor para confirmaciones. De esta manera se puede hacer que Git asuma que el conjunto de padres de una confirmación sea diferente de lo que realmente fue guardado cuando la confirmación fue creada. Configurar mediante el fichero .git/info/grafts.

En el contexto de Git, sinónimo de nombre de objeto.

Una referencia nombrada a la confirmación en la punta de una rama. Los head se almacenan en un fichero en el directorio $GIT_DIR/refs/heads/, excepto cuando se usan referencias empaquetadas (Ver git-pack-refs[1]).

La rama actual. En mas detalle: Tu árbol de trabajo se deriva normalmente del estado del árbol referido por HEAD. HEAD es una referencia a una de las heads en tu repositorio, excepto cuando se usa una HEAD separada, en cuyo caso hace referencia directa a un commit cualquiera.

Sinónimo de head.

Durante la ejecución normal de varios comandos Git se realizan llamadas a scripts opcionales que permiten al desarrollador agregar funcionalidad o verificaciones. Típicamente, los hooks permiten pre-verificar un comando y potencialmente abortarlo, así como una pos-notificación después de terminar la operación. Los scripts de hooks se encuentran en directorio $GIT_DIR/hooks/ y se habilitan simplemente al quitar del nombre del fichero el sufijo .sample; en las primeras versiones de Git se tenían que hacer ejecutables.

Una colección de ficheros con información, cuyo contenido se almacena como objetos. El índice es una versión guardada de tu árbol de trabajo. A decir verdad, también puede contener una segunda, e incluso tercera versión de un árbol de trabajo, las cuales se usan en el merge.

La información relacionada a un fichero en particular, almacenada en el índice. Una entrada de índice puede ser separada, si se ha iniciado un merge pero aún no se ha terminado (ej. si el índice contiene múltiples versiones de ése fichero).

La rama predeterminada de desarrollo. Siempre que creas un repositorio Git, se crea una rama nombrada como "master" y se convierte en la rama activa. En la mayoría de los casos, ésta contiene el desarrollo local, aunque es meramente una convención y no es requerida.

Como verbo: Traer el contenido de otra rama (posiblemente de un repositorio externo) hacia la rama actual. En el caso donde la rama fusionada proviene de un repositorio diferente, primero se hace <def_fetch,fetch>> de la rama remota y luego se fusiona el resultado en la rama actual. Esta combinación de operaciones fetch y fusión se le llama jalar. Las fusiones se realizan por un proceso automático que identifica cambios hechos desde que las ramas divergen, y entonces aplica todos esos cambios en conjunto. En casos donde los cambios conflictúan, se puede requerir intervención manual para completar la fusión.

La unidad de almacenamiento en Git. Se identifica únicamente (de unicidad) por el SHA1 de su contenido. Consecuentemente, un objeto no puede ser modificado.

Almacena un conjunto de "objetos". Un objeto individual es identificado por su nombre de objeto. Los objetos suelen estar en $GIT_DIR/objects/.

Sinónimo de nombre de objeto.

El identificador único de un objeto. El nombre de objeto se suele representar con una cadena hexadecimal de 40 caracteres. También se le conoce coloquialmente como SHA-1.

Uno de los identificadores "commit", "tree (árbol)", "tag (etiqueta)" o "blob" describiendo el tipo de un objeto.

Para fusionar mas de dos ramas.

El repositorio de subida predeterminado. La mayoría de los proyectos tienen por lo menos un proyecto principal a seguir; por default origin es usado para ése propósito. Nuevas actualizaciones al flujo principal serán extraídas en las ramas de seguimiento-remoto nombradas origin/nombre-de-la-rama-de-subida, las cuales puedes ver usando git branch -r.

Sólo actualizar y añadir ficheros al directorio de trabajo, pero no eliminarlos, similar a como cp -R actualizaría el contenido en el directorio destino. Este es el modo predeterminado en un checkout cuando se hace checkout a ficheros de un índice o un árbol-ismo. En contraste, el modo sin-sobreponer también elimina ficheros rastreados no presentes en el origen, similar a rsync --delete.

Un conjunto de objetos que han sido comprimidos en un fichero (para ahorrar espacio o para transmitirlos eficientemente).

La lista de identificadores -y otra información- de los objetos en un paquete, para ayudar a acceder eficientemente el contenido de un paquete.

Patrón usado para limitar rutas en comandos Git.

Un objeto commit contiene una lista -posiblemente vacía- de predecesor(es) en la línea de desarrollo, ej. sus padres.

El término pickaxe se refiere a una opción para las rutinas de diffcore que ayudan a seleccionar los cambios que agregan o eliminan cierta cadena de texto. La opción --pickaxe-all puede usarse para ver el conjunto de cambios completo que introdujo o removió, digamos, a línea de texto en particular. Ver git-diff[1].

Un lindo nombre para núcleo de Git.

Un nombre bonito para programas y suites de programas que dependen del núcleo Git, presentando un acceso de alto nivel al núcleo de Git. Porcelanas exponen mas una interfase de un SCM que la plomería.

Referencia que es por-árbol de trabajo, en lugar de global. Esto es presentemente sólo HEAD y cualquier referencia que comienza con refs/bisect/, pero posteriormente puede incluir otras referencias inusuales.

Las pseudoreferencias son una clase de ficheros bajo $GIT_DIR que se comportan como referencias para propósitos de rev-parse, pero los cuales son tratados especialmente por git. Pseudoreferencias tienen nombres totalmente en mayúsculas y siempre comienzan con una línea consistente en un SHA-1 seguido de un espacio en blanco. Entonces, HEAD no es una pseudoreferencia porque a veces es una referencia simbólica. Pueden contener opcionalmente datos adicionales. MERGE_HEAD y CHERRY_PICK_HEAD son ejemplos. Al contrario de referencias por árbol de trabajo esos ficheros no pueden ser referencias simbólicas y nunca tendrán reflogs. Tampoco pueden ser actualizadas con la maquinaria de actualización de referencias normales; en cambio, son actualizadas escribiendo directamente en los ficheros. Sin embargo, pueden ser leídas como si fueran referencias, de tal manera que git rev-parse MERGE_HEAD funcionará.

Incorporar una rama significa traerla y fusionarla. Ver también git-pull[1].

Enviar una rama significa obtener la referencia a head de la rama de un repositorio remoto, determinar si es un ancestro de la referencia a head de la rama local, y en tal caso, poner todos los objetos que son alcanzables desde la referencia a head local y que son faltantes en el repositorio remoto en la base de datos de objetos remota actualizando la referencia a head remota. Si la head remota no es ancestro del head local, el envío falla.

Todos los ancestros de una <def_commit,confirmación> dada se dice que son "alcanzables" desde esa confirmación. Mas en general, un objeto es alcanzable por otro si podemos alcanzar uno desde otro por una cadena que siga etiquetas a lo que sea que etiqueten, confirmaciones a sus antecesores o árboles, y árboles a los árboles o blobs que los contengan.

Los mapas de bits de alcance almacenan información acerca del alcance de un conjunto seleccionado de confirmaciones en un fichero de paquete, o un índice multi-paquete (MIDX), para acelerar la búsqueda de objetos. Los mapas de bits se almacenan en un fichero ".bitmap". Un repositorio puede tener a lo mucho un fichero de mapa de bits en uso. El fichero de mapa de bits puede pertenecer ya sea a un paquete, o al índice multi-paquete de un repositorio (si existe).

Re-aplicar una serie de cambios de una rama de una base diferente, y reasignar la head de esa rama al resultado.

Un nombre que comienza con refs/ (ej. refs/heads/master) que apunta a un nombre de objeto o a otra referencia (a éste último se le llama referencia simbólica). Por conveniencia, una referencia puede a veces ser abreviada cuando se usa como argumento de un comando Git; ver gitrevisions[7] para detalles. Las referencias se almacenan en el repositorio.

Una bitácora de referencia muestra el historial local de una referencia. En otras palabras, te puede decir cuál fue la 3era última revisión en este repositorio, y cuál era el estado actual en este repositorio ayer a las 9:14pm. Ver git-reflog[1] para detalles.

Una "especificación de referencia" es usada por traer y por enviar para describir el mapeo entre referencia remota y referencia local.

Un repositorio el cual es usado para rastrear el mismo proyecto pero que reside en otro lugar. Para comunicarse con remotos, ver traer o enviar.

Una referencia que es usada para seguir cambios desde otro repositorio. Típicamente se ve como refs/remotes/foo/bar (indicando que da seguimiento una rama llamada bar en un remoto llamado foo), y coincide el lado derecho de una especificación de referencia de envío configurada. Una rama de seguimiento remoto no debería contener modificaciones directas ni tener confirmaciones locales hechas a ella.

Una colección de referencias junto con una base de datos de objetos conteniendo todos los objetos que son alcanzables desde referencias, posiblemente acompañada por metadatos de uno o mas porcelains. Un repositorio puede compartir una base de datos de objetos con otros repositorios vía mecanismos alternos.

La acción de arreglar manualmente lo que quedó de una fusión automática fallida.

Sinónimo para confirmación (el sustantivo).

Para descartar parte del desarrollo, ej. para asignar la head a una revisión anterior.

Administración de código fuente (herramienta).

"Algoritmo de Hash Seguro 1"; una función hash criptográfica. En el contexto de Git se usa como sinónimo de nombre de objeto.

Comúnmente un sinónimo de repositorio superficial pero la frase hace mas explícito que fue creado por la ejecución del comando git clone --depth=....

Un repositorio superficial tienen un historial incompleto, donde algunos de los padres de sus confirmaciones han sido cauterizados (en otras palabras, se le ha instruido a Git a pretender que esas confirmaciones no tienen padres, aunque estén registrados en el objeto confirmación). En ocasiones esto es útil cuando sólo se esta interesado en el historial reciente de un proyecto, aunque el historial real almacenado en el upstream es mucho mayor. Un repositorio superficial es creado al proporcionar la opción --depth a git-clone[1], y su historial puede ser profundizado posteriormente con git-fetch[1].

Un objeto usado para almacenar temporalmente el contenido de un directorio de trabajo sucio así como el índice para reuso futuro.

Un repositorio que mantiene el historial de un proyecto separado dentro de otro repositorio; a este último se le llama superproyecto.

Un repositorio que referencía repositorios de otros proyectos en su árbol de trabajo como submódulos. El superproyecto sabe de los nombres -mas no mantiene copias- de objetos commit de los submódulos contenidos.

Referencia simbólica; en lugar de contener el identificador SHA-1 por sí mismo, está en el formato: ref: referencia/a/algo y cuando es referenciado, se des-referencía recursivamente de ésta referencia. HEAD es el principal ejemplo de una referencia simbólica. Las referencias simbólicas son manipuladas con el comando git-symbolic-ref[1].

Una referencia bajo el espacio de nombres refs/tags/`que apunta a un objeto de tipo arbitrario (típicamente una etiqueta que apunta ya sea a una <<def_tag_object,etiqueta>> o a un <<def_commit_object,commit>>). En contraste a <<def_head,head>>, una etiqueta no es actualizada por el comando `commit. Una etiqueta Git no tiene nada que ver con una etiqueta Lisp (la cual sería llamada tipo de objeto en contexto Git). Una etiqueta es más típicamente usada para marcar un punto en particular en la cadena de ascendencia.

Un objeto que contiene una referencia apuntando a otro objeto, el cual puede contener una mensaje tal como un objeto commit. También puede contener una firma (PGP), en cuyo caso se le llama un "objeto etiqueta firmado".

Una rama Git regular que es usada por un desarrollador para identificar una linea de desarrollo conceptual. Dado que las ramas son fáciles y baratas, a menudo es deseable tener varias ramas pequeñas que contengan conceptos bien definidos o pequeños cambios incrementales relacionados.

Ya sea un árbol de trabajo o un objeto árbol junto con el blob dependiente y objetos árbol (ej. una representación almacenada de un árbol de trabajo).

Un objeto conteniendo una lista de nombres de fichero y modos junto con referencias al blob asociado y/o objetos árbol. Un árbol es equivalente a un directorio.

Un objeto árbol o un objeto que puede ser recursivamente dereferenciado a un objeto árbol. Dereferenciar un objeto commit resulta en el objeto árbol correspondiente al directorio raíz de la revisión. Los siguientes son todos árbol-ismos: un confirmacion-ismo, un objeto árbol, un objeto etiqueta que apunta a un objeto árbol, un objeto etiqueta que apunta a un objeto etiqueta que apunta a un objeto árbol, etc..

Un índice que contiene entradas de índice sin fusionar.

Un objeto que no es alcanzable desde una rama, etiqueta o cualquier otra referencia.

La rama predeterminada que es fusionada en la rama en cuestión (o en la que se basa la rama en cuestión). Se configura vía branch.<nombre>.remote y branch.<nombre>.merge. Si la rama upstream de A es origin/B a veces decimos "A sigue a origin/B".

El árbol de los ficheros actualmente en revisión. El árbol de trabajo normalmente contiene el contenido del árbol de confirmaciones de HEAD, además de los cambios locales que hayas hecho pero aún sin confirmar.

Un repositorio puede tener cero (ej. repositorio básico) o uno o mas árboles de trabajo ligados a él. Un "árbol de trabajo" consiste en un "árbol en trabajo" y repositorio de metadatos, la mayoría de los cuales se comparten entre otros árboles de trabajo de un mismo repositorio, y algunos de los cuales son mantenidos separadamente por árbol de trabajo (ej. el índice, HEAD y pseudoreferencias como MERGE_HEAD, referencias por árbol de trabajo y fichero de configuración por árbol de trabajo).