Desde git reset
"pull" o "merge" siempre deja la punta original de la rama actual ORIG_HEAD
.
git reset --hard ORIG_HEAD
Al restablecerlo de manera difícil, el archivo de índice y el árbol de trabajo vuelven a ese estado, y restablece la punta de la rama a esa confirmación.
git reset --merge ORIG_HEAD
Después de inspeccionar el resultado de la fusión, puede encontrar que el cambio en la otra rama no es 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 sus 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 corrige más fácilmente al cambiar el buzón (por ejemplo, + errores en las líneas "De:").
Además, la combinación siempre establece ' .git/ORIG_HEAD
' al estado original de HEAD, por lo que se puede eliminar una combinación problemática usando ' git reset ORIG_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 en git, pero no necesariamente significa "rama actual" (es decir, HEAD separada).
Pero casi siempre significa el "compromiso actual".
Es el commit " git commit
" se construye encima y " git diff --cached
" y " git status
" se compara con.
Significa la rama actual solo en contextos muy limitados (exactamente cuando queremos que funcione un nombre de rama --- restablecer y aumentar 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 "actual".
HEAD@{5.minutes.ago}
podría significar "desreferenciar HEAD symref para averiguar 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 la confirmación a la que me habría referido como HEAD hace 5 minutos, por ejemplo, si" git show HEAD "en ese entonces".
git1.8.4 (julio de 2013) introduce introdujo una nueva notación!
(en realidad, será para 1.8.5 o 1.9, cuarto trimestre de 2013: reintroducido con commit 9ba89f4 )
En lugar de escribir cuatro letras mayúsculas " HEAD
", puede decir " @
" ahora,
por ejemplo " git log @
".
Ver commit cdfd948
Escribir ' HEAD
' es tedioso, especialmente cuando podemos usar ' @
' en su lugar.
La razón para elegir " @
es que se sigue naturalmente de la ref@op
sintaxis (por ejemplo HEAD@{u}
), excepto que no tenemos referencia ni operación, y cuando no las tenemos, tiene sentido suponer HEAD
".
Así que ahora podemos usar ' git show @~1
', y toda esa bondad.
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 alguna, usaron este nombre.
Una publicación en el blog durante el período 1.8.4-rc3 (14 de agosto de 2013) anunció que esta característica fue revertida y retrasada (Gracias Cupcake por el aviso ).
Nuevamente, se presenta nuevamente con commit 9ba89f4 (septiembre de 2013).
Ver commit 2c2b664 :
Revertir "Agregar nuevo @
acceso directo para HEAD
"
Esto revierte el compromiso cdfd948 , ya que no solo se aplica a " @
" (y a formularios con modificadores similares @{u}
), sino que también afecta, por ejemplo, a " refs/heads/@/foo
", que no debería.
La idea básica de dar una abreviatura podría ser buena, y el tema se puede volver a tratar más adelante, pero volvamos para evitar afectar los casos de uso existentes por ahora para el próximo lanzamiento.
HEAD
ahora es (próximo git1.8.4) '@
'! Vea mi respuesta editada a continuación