Git
Español ▾ Topics ▾ Latest version ▾ gitglossary last updated in 2.44.0

NOMBRE

glosariogit - Un glosario de Git

SINOPSIS

*

DESCRIPCIÓN

base de datos alterna de objetos

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".

repositorio básico

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.

objeto blob

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

rama

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.

cache (antememoria)

Obsoleto por: index.

cadena

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).

conjunto de cambios

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.

checkout (angl.)

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.

selección de cerezas

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.

limpio

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

commit (angl.)

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.

Como verbo: La acción de guardar una nueva instantánea del estado del proyecto en el historial de Git, creando un nuevo commit que represente el estado actual del index y avanzando HEAD para apuntar al nuevo commit.

concepto de grafo de confirmaciones, representaciones y uso

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".

fichero 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.

objeto commit

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.

confirmación-ismo (también confirmacionismo)

Un objeto confirmación o un objeto que puede ser recursivamente desreferenciado 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.

núcleo Git

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

GAD

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).

objeto colgado

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.

desreferencia

Refiriendo a una referencia simbólica: la acción de accesar la referencia a la que apunta una referencia simbólica. Desreferenciar recursivamente involucra repetir el proceso antes mencionado a la referencia resultante hasta que se encuentre un referencia no-simbólica.

Referring to a tag object: the action of accessing the object a tag points at. Tags are recursively dereferenced by repeating the operation on the result object until the result has either a specified object type (where applicable) or any non-"tag" object type. A synonym for "recursive dereference" in the context of tags is "peel".

Refiriendo a un objeto confirmación: la acción de accesar al árbol de objetos de una confirmación. Las confirmaciones no se pueden desreferenciar recursivamente.

A menos que se especifique lo contrario, "desreferenciar" como se usa en el contexto de comandos de Git o protocolos, es implícitamente recursivo.

HEAD separada

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".

Nótese que los comandos que figuran en el historial de la rama actual (ej. git commit para crear una nueva entrada en la punta del historial ) aún funcionan mientras HEAD este separada. Actualizan HEAD para apuntar a la punta del historial actualizado sin afectar cualquier otra rama. Comandos que actualizan o solicitan información acerca de la rama actual (ej. git branch --set-upstream-to que asigna con cuál rama de rastreo-remoto se integra) obviamente no funcionan, ya que no hay -realmente- una rama actual para consultar en este estado.

directorio

El listado que obtienes con "ls" :-)

sucio

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

fusión malvada

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

avance-rápido

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.

fetch (extraer)

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].

sistema de ficheros

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.

Git archive

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

fichero git

Un simple fichero .git en la raíz de un árbol de trabajo que apunta al directorio que es el repositorio real. Para su uso apropiado ver git-worktree[1] o git-submodule[1]. Para sintaxis ver gitrepository-layout[5].

injertos

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.

Notar que el mecanismo de injertos es obsoleto y puede provocar problemas al transferir objetos entre repositorios; ver git-replace[1] para un sistema más flexible y robusto que hace lo mismo.

hash

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

cabeza

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].)

HEAD (angl.)

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.

referencia a head

Sinónimo de head.

hook (angl.)

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.

índice

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.

entrada de índice

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).

master (angl.)

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.

fusión

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 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.

Como sustantivo: A menos que sea un fast-forward, una fusión exitosa resulta en la creación de una nueva confirmación representando el resultado de la fusión, y teniendo como antecesores las puntas de las ramas fusionadas. Este commit es referido como "confirmación de fusión", o a veces simplemente como "fusión".

objeto

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

base de datos de objetos

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

identificador de objeto

Sinónimo de nombre de objeto.

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.

tipo de objeto

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

pulpo

Para fusionar mas de dos ramas.

huérfano

The act of getting on a branch that does not exist yet (i.e., an unborn branch). After such an operation, the commit first created becomes a commit without a parent, starting a new history.

origen

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.

overlay

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.

paquete

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

índice de paquete

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

especificación de ruta

Patrón usado para limitar rutas en comandos Git.

Las especificaciones de ruta son usadas en la línea de comandos de "git ls-files", "git ls-tree", "git add", "git grep", "git diff", "git checkout", y muchos otros comandos para limitar el alcance de operaciones a un subconjunto del árbol o árbol de trabajo. Ver la documentación de cada comando para saber si las rutas son relativas al directorio actual o al toplevel. La sintaxis de las especificaciones de ruta es la siguiente:

  • cualquier ruta coincide consigo misma

  • la especificación de ruta hasta la última diagonal representa un prefijo de directorio. El alcance de esa especificación de ruta se limita a ese sub-árbol.

  • el resto de la especificación de ruta es un patrón para el resto de el nombre de la ruta. Rutas relativas a el prefijo de directorio serán comparadas con ese patrón usando fnmatch(3); en particular, * y ? pueden coincidir con separadores de directorio.

Por ejemplo, Documentación/*.jpg coincidirá con todos los ficheros .jpg en el sub-árbol Documentación, incluyendo Documentación/capitulo_1/figura_1.jpg.

Una especificación de ruta que comienza con dos puntos : tiene un significado especial. En la forma corta, a los dos puntos iniciales le siguen cero o mas letras de "marca mágica" (las cuales terminan opcionalmente con otros dos puntos :), y el resto es el patrón a comparar con la ruta. La "marca mágica" consiste de símbolos ASCII que no son ni alfanuméricos, ni glob, ni caracteres especiales de expresiones regulares, ni dos puntos. Los dos puntos opcionales con los que termina una "marca mágica" pueden ser omitidos si el patrón comienza con un caracter que no pertenece al conjunto de símbolos de "marca mágica" y no es dos puntos.

En la forma larga, a los dos puntos iniciales : le sigue una apertura de paréntesis (, una lista separada por comas de cero o mas "palabras mágicas", y un cierre de paréntesis ), el resto es el patrón de comparación con la ruta.

Una especificación de ruta con sólo dos puntos significa "no hay especificación de ruta". Esta forma no debe combinarse con otras especificaciones de ruta.

top

La palabra mágica top (marca mágica: /) hace la comparación del patrón desde la raíz el árbol de trabajo, incluso cuando el comando se ejecuta desde el interior de un subdirectorio.

literal

Comodines en patrones como * o ? son tratados como caracteres literales.

icase

Búsqueda insensible a mayúsculas.

glob

Git trata el patrón como un glob adecuado para consumo por fnmatch(3) con la bandera FNM_PATHNAME: comodines en el patrón no coincidirán con / en el nombre de la ruta. Por ejemplo, "Documentación/*.html" coincidirá con "Documentación/git.html" pero no con "Documentación/ppc/ppc.html" o "herramientas/perf/Documentación/perf.html".

Dos asteriscos consecutivos ("**") en patrones comparados con nombre de ruta completo puede tener un significado especial:

  • Un "**" inicial seguido por una diagonal significa coincidir en todos los directorios. Por ejemplo, "**/foo" coincidirá con el fichero o directorio "foo" donde sea, lo mismo que "foo". "**/foo/bar" coincidirá con el fichero o directorio bar donde sea que esté directamente debajo del directorio "foo".

  • Un "/**" final coincidirá con todo lo que este dentro. Por ejemplo, "abc/**" coincidirá con todos los ficheros dentro del directorio "abc", relativos a la ubicación del fichero .gitignore, con profundidad infinita.

  • Una diagonal seguida por dos asteriscos consecutivos y luego otra diagonal coincide con cero o mas directorios. Por ejemplo, "a/**/b" coincidirá con "a/b", "a/x/b", "a/x/y/b" y así sucesivamente.

  • Otros asteriscos consecutivos son considerados inválidos.

    Glob mágico es incompatible con literal mágica.

attr

Después de attr: viene una lista separada por espacios de "requerimientos de atributo", todos los cuales deben estar en orden para que la ruta sea considerada una coincidencia; esto en adición a la usual comparación de patrones de especificaciones de ruta no-mágicas. Ver gitattributes[5].

Cada atributo requerido para la ruta toma una de estas formas:

  • "ATTR" requiere que el atributo ATTR se encuentre.

  • "-ATTR" requiere que el atributo ATTR no se encuentre.

  • "ATTR=VALUE" requiere que el atributo ATTR se encuentre asignado con la cadena VALUE.

  • "!ATTR" requiere que el atributo ATTR no este especificado.

    Note que cuando se compara con un objeto árbol, los atributos aún se obtienen del árbol de trabajo, no del objeto árbol proporcionado.

exclude

Después que una ruta coincide con cualquiera de las especificaciones de ruta no-excluyentes, será corrida por todas las especificaciones de ruta excluyentes (marca mágica: ! o su sinónimo ^). Si coincide, la ruta es ignorada. Cuando no hay especificación de ruta no-excluyente, la exclusión se aplica al conjunto resultante como si se hubiera invocado sin una especificación de ruta.

antecesor

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

pelar

La acción de desreferenciar recursivamente un objeto etiqueta.

pickaxe

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].

plomería

Un lindo nombre para núcleo de Git.

porcelana

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 por-árbol-de-trabajo

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.

pseudoreferencia

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

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

enviar

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.

alcanzable

Todos los ancestros de una confirmación> dada se dice que son "alcanzables" desde esa confirmación. Mas en general, un <<def_object,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.

mapas de bits de alcance

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).

rebase

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

ref

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.

El espacio de nombres de referencias es jerárquico. Diferentes sub-jerarquías se usan para fines distintos (ej. la jerarquía refs/heads/ se usa para representar ramas locales).

Hay unas cuantas referencias de propósito especial que no comienzan con refs/. El ejemplo más notable es HEAD.

bitácora de referencia

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.

especificación de referencia

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

repositorio remoto

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.

rama de seguimiento-remoto

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.

repositorio

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.

resolver

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

revisión

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

retroceder

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

GCF

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

SHA-1

"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.

clon superficial

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=....

repositorio superficial

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].

entrada de reserva

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

referencia especial

Una referencia que tiene semánticas diferentes a la referencias normales. Esas referencias pueden accesarse mediante comandos normales de Git pero en algunos casos podrían comportarse diferente a una referencia normal.

Las siguientes referencias especiales son reconocidas por Git:

  • "FETCH_HEAD" es escrito por git-fetch[1] o git-pull[1]. Se puede referir a múltiples identificadores de objeto. Cada identificador de objeto es anotado con metadatos indicando de dónde se obtuvo y el estado del fetch.

  • "MERGE_HEAD" es escrito por git-merge[1] cuando se resuelven conflictos de fusión. Contiene todos los identificadores de las confirmaciones que se están fusionando.

submódulo

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

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

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 desreferencí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].

tag (etiqueta)

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.

objeto etiqueta

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".

rama tópica

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.

árbol

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).

objeto árbol

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.

árbol-ismo (también arbolismo)

Un objeto árbol o un objeto que puede ser recursivamente desreferenciado a un objeto árbol. Desreferenciar 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..

no nacido

The HEAD can point at a branch that does not yet exist and that does not have any commit on it yet, and such a branch is called an unborn branch. The most typical way users encounter an unborn branch is by creating a repository anew without cloning from elsewhere. The HEAD would point at the main (or master, depending on your configuration) branch that is yet to be born. Also some operations can get you on an unborn branch with their orphan option.

índice sin-fusionar

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

objeto inalcanzable

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

rama upstream

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".

árbol de trabajo

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.

árbol de trabajo

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).

GIT

Parte de la suite de git[1]

scroll-to-top