HEAD y ORIG_HEAD en Git
¿A qué se refieren estos símbolos y qué significan?
(No encuentro ninguna explicación en la documentación oficial)
HEADes una referencia (directa o indirecta, es decir, simbólica) a la confirmación actual. Es una confirmación que ha verificado en el directorio de trabajo (a menos que haya realizado algunos cambios, o equivalente), y es una confirmación además de la cual "git commit" crearía una nueva. Generalmente HEADes una referencia simbólica a alguna otra rama nombrada; esta rama es actualmente una rama retirada o una rama actual. HEADtambién puede apuntar directamente a una confirmación; este estado se llama "HEAD separado" y puede entenderse como si estuviera en una rama anónima y sin nombre.
Y @solo es un atajo para HEAD, desde Git 1.8.5
ORIG_HEADes el estado anterior de HEAD, establecido por comandos que tienen un comportamiento posiblemente peligroso, para que sea fácil revertirlos. Es menos útil ahora que Git tiene reflog: HEAD@{1}es aproximadamente equivalente a ORIG_HEAD( HEAD@{1}siempre es el último valor de HEAD, ORIG_HEADes el último valor de HEADantes de una operación peligrosa).
Para obtener más información, lea la página de manual de git(1) / [gitrevisions(7) manpage][git-revisions], el Manual del usuario de Git , el Libro de la comunidad de Git y el Glosario de Git.
ORIG_HEAD
Desde git reset
"tirar" o "fusionar" siempre deja la punta original de la rama actual en
ORIG_HEAD.git reset --hard ORIG_HEADAl restablecerlo por completo, su archivo de índice y el árbol de trabajo regresan a ese estado, y restablece la punta de la rama a esa confirmación.
git reset --merge ORIG_HEADDespués de inspeccionar el resultado de la fusión, es posible que el cambio en la otra rama no sea satisfactorio. Ejecutar "
git reset --hard ORIG_HEAD" le permitirá volver a donde estaba, pero descartará los cambios locales que no desea. "git reset --merge" mantiene los cambios locales.
Antes de aplicar cualquier parche, ORIG_HEAD se establece en la punta de la rama actual.
Esto es útil si tiene problemas con múltiples confirmaciones, como ejecutar 'git am' en la rama incorrecta o un error en las confirmaciones que se soluciona más fácilmente cambiando el buzón (por ejemplo, +errores en las líneas "De:").Además, la combinación siempre establece "
.git/ORIG_HEAD" en el estado original de HEAD, por lo que se puede eliminar una combinación problemática utilizando "git reset ORIG_HEAD".
Git 2.40 (primer trimestre de 2023) documenta ORIG_HEADun poco más:
Consulte el compromiso f1c9243 , el compromiso c6eec9c , el compromiso 0c514d5 , el compromiso d03c773 , el compromiso e29678b (10 de enero de 2023) por Philippe Blain ( phil-blain) .
(Fusionado por Junio C Hamano -- gitster-- en el compromiso 9c2003a , 21 de enero de 2023)
git-rebase.txt: agregue una nota sobre "ORIG_HEAD" siendo sobrescritoReportado por: Erik Cervin Edin
Firmado por: Philippe Blain
Acreditado por: Phillip Wood
'
ORIG_HEAD' está escrito al inicio de la rebase, pero no se garantiza que aún apunte a la punta de la rama original al final de la rebase.De hecho, el uso de otros comandos que escriben '
ORIG_HEAD' durante la rebase, como dividir una confirmación usando 'git reset' ( man ) HEAD^', provocará que 'ORIG_HEAD' se sobrescriba.
Esto causa confusión en algunos usuarios .Agregue una nota sobre eso en la sección 'Descripción' y mencione la alternativa más sólida de usar el registro de la sucursal.
git rebaseahora incluye en su página de manual :
[NOTE]:
ORIG_HEADno se garantiza que siga apuntando a la sugerencia de la rama anterior al final del cambio de base sigit resetse utilizan otros comandos que escriben esa pseudo-referencia (por ejemplo, ) durante el cambio de base.
Sin embargo, se puede acceder a la sugerencia de la rama anterior utilizando el reflog de la rama actual (es decir@{1}).
Y:
revisions.txt: sea explícito acerca de la escritura de comandos 'ORIG_HEAD'Aprobado por: Philippe Blain
Aprobado por: Phillip Wood
Cuando mencione '
ORIG_HEAD', sea explícito sobre qué comando escribe esa pseudo-referencia, es decir, 'git am' ( man ) , 'git merge' ( man ) , 'git rebase' ( man ) y 'git reset' ( man ) .
revisionsahora incluye en su página de manual :
ORIG_HEADse crea mediante comandos que lo muevenHEADde manera drástica (git am,git merge,git rebase,git reset), para registrar la posición deHEADantes de su operación, de modo que pueda cambiar fácilmente la punta de la rama al estado antes de ejecutarla.
HEAD
Nota: desde aquí
HEAD es un puntero en movimiento. A veces significa la rama actual, a veces no.
Entonces HEAD NO es sinónimo de "rama actual" en todas partes.
HEAD significa "actual" en todas partes de git, pero no necesariamente significa "rama actual" (es decir, HEAD independiente).
Pero casi siempre significa el "compromiso actual".
Es el compromiso "git commit" que se construye sobre el que "git diff --cached" y "git status" se comparan.
Significa la rama actual solo en contextos muy limitados (exactamente cuando queremos que funcione un nombre de rama --- restablecer y hacer crecer la punta de la rama a través de commit/rebase/etc.).Reflog es un vehículo para retroceder en el tiempo y las máquinas del tiempo tienen una interacción interesante con la noción de "actualidad".
HEAD@{5.minutes.ago}podría significar "desreferenciar HEAD symref para saber en qué rama estamos AHORA MISMO, y luego averiguar dónde estaba la punta de esa rama hace 5 minutos".
Alternativamente, podría significar "¿cuál es el compromiso al que me habría referido como HEAD hace 5 minutos, por ejemplo, si hubiera hecho "git show HEAD" en ese entonces".
git1.8.4 (julio de 2013) presenta introdujo una nueva notación!
(En realidad, será para 1.8.5, cuarto trimestre de 2013: reintroducido con el compromiso 9ba89f4 ), por Felipe Contreras .
En lugar de escribir cuatro letras mayúsculas "
HEAD", ahora puede decir "@",
por ejemplo "git log @".
Ver confirmación cdfd948
Escribir '
HEAD' es tedioso, especialmente cuando podemos usar '@' en su lugar.La razón para elegir '
@' es que se desprende naturalmente de laref@opsintaxis (p. ej.HEAD@{u}), excepto que no tenemos referencia ni operación, y cuando no las tenemos, tiene sentido asumir 'HEAD'.Así que ahora podemos usar '
git show @~1', y todas esas bondades.Hasta ahora '
@' era un nombre válido, pero entra en conflicto con esta idea, así que hagámoslo inválido. Probablemente muy pocas personas, si es que hubo alguna, utilizaron este nombre.
De man 7 gitrevisions:
HEAD nombra la confirmación en la que basó los cambios en el árbol de trabajo. FETCH_HEAD registra la rama que recuperaste de un repositorio remoto con tu última invocación de git fetch. ORIG_HEAD se crea mediante comandos que mueven su HEAD de manera drástica, para registrar la posición del HEAD antes de su operación, de modo que pueda cambiar fácilmente la punta de la rama al estado antes de ejecutarlos. MERGE_HEAD registra las confirmaciones que estás fusionando en tu rama cuando ejecutas git merge. CHERRY_PICK_HEAD registra la confirmación que estás seleccionando cuando ejecutas git cherry-pick.
