¿Qué es una expresión de revisión de Git?

Git necesita ser capaz de identificar un commit durante una serie de operaciones comunes

Hay varias maneras de identificar un commit. Puedes usar una rama, una etiqueta, un commit sha1 o expresiones. Por ejemplo:

git log HEAD

HEAD finalmente se resuelve a una confirmación específica, y se le dará el registro para eso. También podrías decir:

git log master

master es una rama, y que también se resolverá a un commit específico.

git log fd72e9c99312

Ahora que ES el real cometer.

La siguiente documentación es lo que está buscando. Tomado de la documentación del comando git-rev-parse en http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html .

ESPECIFICACIÓN DE REVISIONES

Un parámetro de revisión típicamente, pero no necesariamente, nombra un objeto de confirmación. Utilizan lo que se llama una sintaxis SHA1 extendida. Aquí hay varias formas de deletrear nombres de objetos. Los que se enumeran cerca del final de esta lista son para nombrar árboles y blobs contenidos en un commit.

El nombre completo del objeto SHA1 (cadena hexadecimal de 40 bytes), o una subcadena de tales que es única dentro del repositorio. Por ejemplo, dae86e1950b1277e545cee180551750029cfe735 y dae86e ambos nombran el mismo objeto de confirmación si no hay otro objeto en su repositorio cuyo nombre de objeto comience con dae86e.

Una salida de git-describe; es decir, una etiqueta más cercana, opcionalmente seguida de un guión y un número de confirmaciones, seguido de un guión, una g y una abreviatura nombre del objeto.

Un nombre de referencia simbólico. Por ejemplo, master normalmente significa el objeto de confirmación referenciado por G GIT_DIR/refs/heads / master. Si tienes tanto heads / master como tags/master, puedes decir explícitamente heads/master para decirle a git cuál quieres decir. Cuando es ambiguo, a es desambiguado tomando la primera coincidencia en las siguientes reglas:

Si existe G GIT_DIR/, eso es lo que quiere decir (esto es generalmente útil solo para HEAD, FETCH_HEAD, ORIG_HEAD y MERGE_HEAD);

De lo contrario, G GIT_DIR/refs/ si existe;

De lo contrario, G GIT_DIR/refs/tags/ si existe;

De lo contrario, G GIT_DIR/refs/heads/ si existe;

De lo contrario, G GIT_DIR/refs/remotes/ si existe;

De lo contrario, HEAD GIT_DIR/refs/remotes//HEAD si existe.

HEAD nombra la confirmación en la que se basan sus cambios en el árbol de trabajo. FETCH_HEAD registra la rama que has obtenido de un repositorio remoto con tu última invocación git-fetch. ORIG_HEAD es creado por comandos que mueve la CABEZA de una manera drástica, para registrar la posición de la CABEZA antes de su operación, para que pueda cambiar la punta de la rama de nuevo al estado antes de ejecutarlos fácilmente. MERGE_HEAD registra la(s) confirmación (es) que estás fusionando en tu rama cuando ejecutas git-merge.

Un ref seguido del sufijo @ con una especificación de fecha encerrada en un par de llaves (por ejemplo, {yesterday}, {1 mes 2 semanas 3 días 1 hora 1 segundo hace} o {1979-02-26 18: 30: 00}) para especificar el valor de el árbitro en un momento anterior. Este sufijo solo se puede usar inmediatamente después de un nombre de referencia y la referencia debe tener un registro existente (G GIT_DIR/logs/). Tenga en cuenta que esto busca el estado de su ref local en un momento dado; por ejemplo, lo que estaba en su rama master local la semana pasada. Si quieres ver las confirmaciones realizadas durante ciertos momentos, ve --since y until until.

Un ref seguido del sufijo @ con una especificación ordinal encerrada en un par de llaves (por ejemplo, {1}, {15}) para especificar el n-ésimo prior valor de ref. Por ejemplo, master@{1} es el valor previo inmediato de master mientras que master@{5} es el 5to valor previo de master. Este sufijo solo se puede usar inmediatamente después de un nombre de referencia y la referencia debe tener un registro existente (G GIT_DIR/logs/).

Puede usar el @ construct con una parte ref vacía para obtener un reflog de la rama actual. Por ejemplo, si estás en la rama blabla, entonces @{1} significa lo mismo que blabla@{1}.

La construcción especial @ { - } significa el th branch se retiró antes de la actual.

Un sufijo ^ a un parámetro de revisión significa el primer padre de ese objeto de confirmación. ^ significa la matriz (es decir, rev^ es equivalente a rev^1). Como regla especial, rev^0 significa el commit en sí y se usa cuando rev es el nombre del objeto de una etiqueta que se refiere a un objeto commit.

Un sufijo ~ a un parámetro de revisión significa el objeto commit que es el grand-parent de la generación th del objeto commit nombrado, padre. Es decir, rev~3 es equivalente a rev^^^ que es equivalente a rev^1^1^1. Vea a continuación una ilustración del uso de este formulario.

Un sufijo ^ seguido por un nombre de tipo de objeto encerrado en un par de llaves (por ejemplo, v0.99.8^{commit}) significa que el objeto podría ser una etiqueta, y desreferenciar la etiqueta recursivamente hasta que se encuentre un objeto de ese tipo o el objeto ya no pueda desreferenciarse (en cuyo caso, barf). rev^0 introducido anteriormente es una abreviatura de rev^{commit}.

Un sufijo ^ seguido por un par de llaves vacías (por ejemplo, v0.99.8^{}) significa que el objeto podría ser una etiqueta, y desreferenciar la etiqueta recursivamente hasta que se encuentre un objeto sin etiqueta.

Dos puntos, seguido de una barra diagonal, seguido de un texto: esto nombra un commit cuyo mensaje de commit comienza con el texto especificado. Este nombre devuelve la confirmación coincidente más joven a la que se puede acceder desde cualquier ref. Si el mensaje de confirmación comienza con a !, tienes que repetir eso; la secuencia especial:/!, seguido de algo más que! ser reservado por ahora.

Un sufijo : seguido de un camino; esto nombra el blob o árbol en el camino dado en el objeto tree-ish nombrado por la parte antes de los dos puntos.

Dos puntos, opcionalmente seguidos de un número de etapa (0 a 3) y dos puntos, seguidos de una ruta; esto nombra un objeto blob en el índice en la ruta dada. El número de etapa que falta (y los dos puntos que lo siguen) nombra una entrada de etapa 0. Durante una fusión, la etapa 1 es el ancestro común, la etapa 2 es la versión de la rama de destino (típicamente la rama actual), y la etapa 3 es la versión de la rama que se fusiona.

Aquí hay una ilustración, de Jon Loeliger. Ambos nodos de confirmación B y C son los padres del nodo de confirmación A. Las confirmaciones principales se ordenan de izquierda a derecha.

G   H   I   J
 \ /     \ /
  D   E   F
   \  |  / \
    \ | /   |
     \|/    |
      B     C
       \   /
        \ /
         A
A =      = A^0
B = A^   = A^1     = A~1
C = A^2  = A^2
D = A^^  = A^1^1   = A~2
E = B^2  = A^^2
F = B^3  = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2  = B^^2    = A^^^2  = A~2^2
I = F^   = B^3^    = A^^3^
J = F^2  = B^3^2   = A^^3^2