tag repositorio que password crear and git

repositorio - git push tag



¿Cuál es la diferencia entre HEAD ^ y HEAD ~ en Git? (13)

Ejemplo real de la diferencia entre HEAD ~ y HEAD ^

Cuando especifico un objeto de confirmación de antepasado en Git, estoy confundido entre HEAD^ y HEAD~ .

Ambos tienen una versión "numerada" como HEAD^3 y HEAD~2 .

Me parecen muy similares o iguales, pero ¿hay alguna diferencia entre la tilde y el caret?


Aquí hay una muy buena explicación tomada literalmente de http://www.paulboxley.com/blog/2011/06/git-caret-and-tilde :

ref~ es una abreviatura de ref~1 y significa el primer padre del commit. ref~2 significa el primer padre del primer padre del commit. ref~3 significa el primer padre del primer padre del primer padre del compromiso. Y así.

ref^ es una abreviatura de ref^1 y significa el primer padre del commit. Pero donde los dos difieren es que ref^2 significa el segundo padre del commit (recuerde, los commit pueden tener dos padres cuando son una fusión).

Los operadores ^ y ~ se pueden combinar.


El formato ^<n> permite seleccionar el noveno padre de la confirmación (relevante en las fusiones). El formato ~<n> permite seleccionar el nth commit anterior, siempre siguiendo al primer padre. Consulte la documentación de git-rev-parse para ver algunos ejemplos.


En pocas palabras, para el primer nivel de parentesco (ascendencia, herencia, linaje, etc.) HEAD ^ y HEAD ~ apuntan al mismo commit, que es (ubicado) un padre sobre el HEAD (commit).

Además, HEAD ^ = HEAD ^ 1 = HEAD ~ = HEAD ~ 1. Pero HEAD ^^! = HEAD ^ 2! = HEAD ~ 2. Sin embargo, HEAD ^^ = HEAD ~ 2. Sigue leyendo

Más allá del primer nivel de filiación, las cosas se ponen más complicadas, especialmente si la rama que trabaja / la rama principal ha tenido fusiones (de otras ramas). También está el tema de la sintaxis con el cursor, HEAD ^^ = HEAD ~ 2 (son equivalentes) BUT HEAD ^^! = HEAD ^ 2 (son dos cosas completamente diferentes).

Cada / la careta se refiere al primer padre de la CABEZA, por lo que las caretas unidas son equivalentes a las expresiones de tilde, porque se refieren a los primeros padres del primer padre (el primer padre), etc., basados ​​estrictamente en el número de caretos conectados o en el número que sigue a la tilde (de cualquier manera, ambos significan lo mismo), es decir, se quedan con el primer padre y suben x generaciones.

HEAD ~ 2 (o HEAD ^^) se refiere al compromiso que se encuentra dos niveles de ascendencia arriba / arriba del compromiso actual (HEAD) en la jerarquía, es decir, el compromiso de abuelo de HEAD.

HEAD ^ 2, por otro lado, se refiere NO al compromiso del segundo padre del primer padre, sino simplemente al compromiso del segundo padre. Esto se debe a que el símbolo de intercalación significa el padre de la confirmación, y el número siguiente significa a qué / a qué confirmación principal se refiere (el primer padre, en el caso de que el símbolo de intercalación no esté seguido de un número [porque es una taquigrafía para el número siendo 1, lo que significa el primer padre]). A diferencia del cursor, el número que sigue después no implica otro nivel de jerarquía hacia arriba, sino que implica cuántos niveles de lado, en la jerarquía, uno debe buscar el padre correcto (cometer). A diferencia del número en una expresión de tilde, solo hay un padre arriba en la jerarquía, sin importar el número (inmediatamente) que procede de la intercalación. En lugar de ascendente, el número de seguimiento del corsé cuenta lateralmente para los padres en toda la jerarquía [a un nivel de padres hacia arriba que es equivalente al número de caretes consecutivos].

Por lo tanto, HEAD ^ 3 es igual al tercer padre del cometer HEAD (NO el bisabuelo, que es lo que HEAD ^^^ Y HEAD ~ 3 serían ...).


HEAD ^^^ es lo mismo que HEAD ~ 3, seleccionando la tercera confirmación antes de HEAD

HEAD ^ 2 especifica la segunda cabecera en un commit de fusión


La diferencia entre HEAD^ y HEAD~ está bien descrita por la ilustración (por Jon Loeliger) que se encuentra en http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html .

Esta documentación puede ser un poco oscura para los principiantes, así que he reproducido la siguiente ilustración:

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


Mis dos centavos...


TLDR

~ es lo que desea la mayoría de las veces, hace referencia a compromisos anteriores a la rama actual

^ hace referencia a los padres (git-merge crea un segundo padre o más)

A ~ es siempre lo mismo que A ^
A ~~ es siempre lo mismo que A ^^, y así sucesivamente
A ~ 2 no es lo mismo que A ^ 2, sin embargo,
porque ~ 2 es taquigrafía para ~~
mientras ^ 2 no es una abreviatura de nada, significa el segundo padre


Tanto ~ como ^ por su propia cuenta se refieren al padre del compromiso ( ~~ y ^^ ambos se refieren al compromiso de abuelo, etc.) Pero difieren en el significado cuando se usan con números:

  • ~2 significa hasta dos niveles en la jerarquía , a través del primer padre si un compromiso tiene más de un padre

  • ^2 significa el segundo padre donde un compromiso tiene más de un padre (es decir, porque es una combinación)

Estos pueden combinarse, por lo que HEAD~2^3 significa el compromiso principal del tercer padre de HEAD .


Vale la pena tener en cuenta que git también tiene una sintaxis para rastrear "de donde viniste" / "querer volver ahora"; por ejemplo, HEAD@{1} hará referencia al lugar desde donde saltó a la nueva ubicación de confirmación.

Básicamente, las variables HEAD@{} capturan la historia del movimiento de la CABEZA, y puedes decidir usar una cabeza en particular al buscar en los reflogs de git usando el comando git reflog .

Ejemplo:

0aee51f HEAD@{0}: reset: moving to HEAD@{5} 290e035 HEAD@{1}: reset: moving to HEAD@{7} 0aee51f HEAD@{2}: reset: moving to HEAD@{3} 290e035 HEAD@{3}: reset: moving to HEAD@{3} 9e77426 HEAD@{4}: reset: moving to HEAD@{3} 290e035 HEAD@{5}: reset: moving to HEAD@{3} 0aee51f HEAD@{6}: reset: moving to HEAD@{3} 290e035 HEAD@{7}: reset: moving to HEAD@{3} 9e77426 HEAD@{8}: reset: moving to HEAD@{3} 290e035 HEAD@{9}: reset: moving to HEAD@{1} 0aee51f HEAD@{10}: reset: moving to HEAD@{4} 290e035 HEAD@{11}: reset: moving to HEAD^ 9e77426 HEAD@{12}: reset: moving to HEAD^ eb48179 HEAD@{13}: reset: moving to HEAD~ f916d93 HEAD@{14}: reset: moving to HEAD~ 0aee51f HEAD@{15}: reset: moving to HEAD@{5} f19fd9b HEAD@{16}: reset: moving to HEAD~1 290e035 HEAD@{17}: reset: moving to HEAD~2 eb48179 HEAD@{18}: reset: moving to HEAD~2 0aee51f HEAD@{19}: reset: moving to HEAD@{5} eb48179 HEAD@{20}: reset: moving to HEAD~2 0aee51f HEAD@{21}: reset: moving to HEAD@{1} f916d93 HEAD@{22}: reset: moving to HEAD@{1} 0aee51f HEAD@{23}: reset: moving to HEAD@{1} f916d93 HEAD@{24}: reset: moving to HEAD^ 0aee51f HEAD@{25}: commit (amend): 3rd commmit 35a7332 HEAD@{26}: checkout: moving from temp2_new_br to temp2_new_br 35a7332 HEAD@{27}: commit (amend): 3rd commmit 72c0be8 HEAD@{28}: commit (amend): 3rd commmit

Un ejemplo podría ser que hice confirmaciones locales a-> b-> c-> d y luego volví a descartar 2 confirmaciones para verificar mi código ( git reset HEAD~2 ) y luego, después de eso, quiero mover mi HEAD hacia atrás. a d - git reset HEAD@{1} .


HEAD^ significa el primer padre de la punta de la rama actual.

Recuerde que git commit puede tener más de un padre. HEAD^ es la abreviatura de HEAD^1 , y también puede dirigirse a HEAD^2 y así sucesivamente, según corresponda.

Puede llegar a los padres de cualquier compromiso, no solo a HEAD . También puede retroceder de generación en generación: por ejemplo, master~2 significa el abuelo de la punta de la rama maestra, favoreciendo al primer padre en caso de ambigüedad. Estos especificadores pueden ser encadenados arbitrariamente, por ejemplo , topic~3^2 .

Para obtener todos los detalles, consulte "Especificar revisiones" en la documentación de git rev-parse .

Para tener una representación visual de la idea, citemos parte de la documentación:

Aquí hay una ilustración, por Jon Loeliger. Ambos nodos de confirmación B y C son los 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


Simplísticamente :

  • ~ especifica ancestros
  • ^ especifica padres

Puede especificar una o más ramas al fusionar. Luego, un compromiso tiene dos o más padres y luego ^ es útil para indicar a los padres.

Supongamos que estás en la rama A y tienes dos ramas más: B y C.

En cada rama las tres últimas confirmaciones son:

  • A : A1 , A2 , A3
  • B : B1 , B2 , B3
  • C : C1 , C3 , C3

Si ahora en la rama A ejecuta el comando:

git merge B C

entonces están combinando tres ramas juntas (aquí su compromiso de fusión tiene tres padres)

y

~ indica el noveno ancestro en la primera rama, entonces

  • HEAD~ indica A3
  • HEAD~2 indica A2
  • HEAD~3 indica A1

^ indica el noveno padre, entonces

  • HEAD^ indica A3
  • HEAD^2 indica B3
  • HEAD^3 indica C3

El siguiente uso de ~ o ^ uno al lado del otro es en el contexto del compromiso designado por los caracteres anteriores.

Aviso 1 :

  • HEAD~3 siempre es igual a: HEAD~~~ y a: HEAD^^^ (todo indica A1 ),

y en general

  • HEAD~n siempre es igual a: HEAD~...~ ( n veces ~ ) y a: HEAD^...^ ( n veces ^ ).

Aviso 2 :

  • HEAD^3 no es lo mismo que HEAD^^^ (el primero indica C3 y el segundo A1 ),

y en general

  • HEAD^1 es lo mismo que HEAD^ ,
  • pero para n > 1: HEAD^n no siempre es lo mismo que HEAD^...^ ( n veces ~ ).

  • HEAD ~ especifica el primer padre en una "rama"

  • HEAD ^ le permite seleccionar un padre específico de la confirmación

Un ejemplo:

Si quieres seguir una rama lateral, debes especificar algo como

master~209^2~15