Git tiene que ser capaz de identificar una confirmación durante una serie de operaciones comunes
Hay un número de maneras de identificar una confirmación. Podría usar una rama, etiqueta, cometer sha1 o expresiones. Por ejemplo:
git log HEAD
HEAD finalmente se resuelve a cometer un procedimiento específico, y se le dará el registro para eso. También se podría decir:
git log master
master es una rama, y que también puede resolver a cometer un específico.
git log fd72e9c99312
Ahora que ES la confirmación real.
La siguiente documentación es lo que estás 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.
REVISIONES ESPECIFICACIÓN
Un parámetro revisión típicamente, pero no necesariamente, nombres un objeto de comprometerse. Usan lo que se llama una sintaxis SHA1 extendida. Aquí hay varias formas de deletrear nombres de objetos. Los que se enumeran al final de esta lista son para nombrar árboles y blobs contenidos en una confirmación.
El nombre completo del objeto SHA1 (cadena hexadecimal de 40 bytes), o una subcadena de tal que es única dentro del repositorio. P.ej. 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 una serie de confirmaciones, seguida de un guión, una g y un nombre de objeto abreviado.
Un nombre de referencia simbólico. P.ej. maestro generalmente significa el objeto de compromiso referenciado por $ DIR_DESIGNACIÓN/referencias/encabezados/maestro. Si tienes ambos cabezales/maestro y etiquetas/maestro, puedes decir explícitamente cabezas/maestro para decirle a quien te refieres.Cuando ambiguo, a es desambiguado tomando la primera coincidencia en las siguientes reglas:
si $ GIT_DIR/existe, eso es lo que quiere decir (esto suele ser útil solo para HEAD, FETCH_HEAD, ORIG_HEAD y MERGE_HEAD);
de lo contrario, $ GIT_DIR/refs/if existe;
de lo contrario, $ GIT_DIR/refs/tags/si existe;
de lo contrario, $ GIT_DIR/refs/heads/si existe;
de lo contrario, $ GIT_DIR/refs/remotes/if existe;
de lo contrario, $ GIT_DIR/refs/mandos a distancia // 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 ha extraído de un repositorio remoto con su última invocación de git-fetch. ORIG_HEAD se crea mediante comandos que mueven su HEAD de forma drástica, para registrar la posición de HEAD antes de su operación, de modo que pueda volver a cambiar la punta de la rama al estado antes de ejecutarlos fácilmente. MERGE_HEAD registra los commit (s) que se fusionan en su branch cuando ejecuta git-merge.
Una referencia seguida del sufijo @ con una especificación de fecha incluida en un par de llaves (por ejemplo, {ayer}, {1 mes, 2 semanas, 3 días, 1 hora 1 segundo} o {1979-02-26 18:30: 00}) para especificar el valor de la referencia en un punto anterior en el tiempo. Este sufijo solo se puede usar inmediatamente después de un nombre de referencia y la referencia debe tener un registro existente ($ GIT_DIR/logs /). Tenga en cuenta que esto busca el estado de su ref local en un momento dado; por ejemplo, qué estaba en su sucursal principal local la semana pasada. Si desea ver las confirmaciones realizadas en determinados momentos, consulte --since y --until.
Una referencia seguida del sufijo @ con una especificación ordinal incluida en un par de llaves (por ejemplo, {1}, {15}) para especificar el n-ésimo valor anterior de esa referencia. Por ejemplo, master @ {1} es el valor anterior inmediato de master mientras que master @ {5} es el 5to valor anterior de master. Este sufijo solo se puede usar inmediatamente después de un nombre de referencia y la referencia debe tener un registro existente ($ GIT_DIR/logs /).
Puede usar el constructo @ con una parte de ref vacía para obtener un reflog de la rama actual. Por ejemplo, si está en la rama blabla, entonces @ {1} significa lo mismo que blabla @ {1}.
La construcción especial @ {-} significa la rama th desmantelada antes de la actual.
Un sufijo^a un parámetro de revisión significa el primer elemento primario de ese objeto de confirmación.^significa que el padre (es decir, rev^es equivalente a rev^1). Como regla especial, rev^0 significa el compromiso en sí mismo y se usa cuando rev es el nombre del objeto de una etiqueta que se refiere a un objeto de confirmación.
Un sufijo ~ a un parámetro de revisión significa el objeto de confirmación que es el abuelo padre de la generación del objeto de confirmación nombrado, siguiendo solo al primer 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 de un nombre de tipo de objeto incluido en par de corchetes (por ejemplo, v0.99.8^{commit}) significa que el objeto podría ser una etiqueta y eliminar la etiqueta recursivamente hasta que se encuentre un objeto de ese tipo o objeto ya no se puede desreferenciar (en este caso, barf). rev^0 introducido anteriormente es una abreviación para rev^{commit}.
Un sufijo^seguido de 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 encontrar un objeto que no sea etiqueta.
Dos puntos, seguidos de una barra inclinada, seguidos de un texto: esto nombra una confirmación cuyo mensaje de confirmación comienza con el texto especificado. Este nombre devuelve el compromiso de coincidencia más joven al que se puede acceder desde cualquier referencia. Si el mensaje de confirmación comienza con a!, Debe repetir eso; la secuencia especial: /! seguido de algo más que! está reservado por ahora.
Un sufijo: seguido de una ruta; esto nombra el blob o árbol en la ruta dada en el objeto tree-ish nombrado por la parte antes del colon.
Dos puntos, seguidos opcionalmente por 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 faltante (y los dos puntos que lo siguen) nombra una entrada de etapa 0. Durante una combinación, la etapa 1 es el ancestro común, la etapa 2 es la versión de la rama objetivo (generalmente la rama actual) y la etapa 3 es la versión de la rama que se fusiona.
Aquí está una ilustración, por Jon Loeliger. Ambos nodos de confirmación B y C son padres del nodo de confirmación A. Las confirmaciones de los padres 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
si desea fusionar los cambios de control remoto a su local (maestro para mí), puede escribir remote/master – cgao