Różnica między HEAD^ i HEAD~ jest dobrze opisana przez ilustrację (autorstwa Jona Loeligera) znalezioną na http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html .

Ta dokumentacja może być nieco niejasna dla początkujących, więc odtworzyłem tę ilustrację poniżej:

G   H   I   J
 \ /     \ /
  D   E   F
   \  |  / \
    \ | /   |
     \|/    |
      B     C
       \   /
        \ /
         A
A =      = A^0
B = A^   = A^1     = A~1
C = 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

Zarówno ~ jak i ^ same odnoszą się do rodzica commita (~~ i ^^ Oba odnoszą się do commita dziadków itp.), Ale różnią się one znaczeniem, gdy są używane z liczbami:

• ~2 oznacza dwa poziomy w hierarchii , poprzez pierwszego rodzica, jeśli commit ma więcej niż jednego rodzica

• ^2 oznacza drugi rodzic gdzie commit ma więcej niż jednego rodzica (tzn. ponieważ jest to merge)

Te mogą być połączone, więc HEAD~2^3 oznacza HEAD's dziadkowy commit' s third rodzic commit.

Moje dwa centy...

Oto bardzo dobre wyjaśnienie zaczerpnięte dosłownie z http://www.paulboxley.com/blog/2011/06/git-caret-and-tilde :

ref~ jest skrótem ref~1 i oznacza pierwszego rodzica commita. ref~2 oznacza pierwszego rodzica commita. ref~3 oznacza pierwszy rodzic commita. I tak dalej.

ref^ jest skrótem ref^1 i oznacza pierwszego rodzica commita. Ale gdzie dwa różnią się, to ref^2 oznacza drugi rodzic commita (pamiętaj, że commity mogą mieć dwoje rodziców, gdy są połączeniem).

Operatory ^ i ~ można łączyć.

Format ^<n> pozwala wybrać n-ty rodzic commita (istotny w połączeniach). Format ~<n> pozwala wybrać n-ty commit przodka, zawsze po pierwszym rodzicu. Niektóre przykłady można znaleźć w dokumentacji git-rev-parse.

Warto zauważyć, że git posiada również składnię do śledzenia "from-where-you-came" / "want-to-go-back-now" - na przykład, HEAD@{1} będzie odwoływać się do miejsca, z którego przeskoczyłeś do nowej lokalizacji zatwierdzania.

Zasadniczo HEAD@{} zmienne przechwytują historię ruchu głowicy i możesz zdecydować się na użycie konkretnej głowicy, patrząc na reflogs git za pomocą polecenia git reflog.

Przykład:

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

Przykładem może być to, że zrobiłem local-commits a->b->c - > d i wróciłem odrzucenie 2 zobowiązuje się sprawdzić mój kod - git reset HEAD~2 - a potem chcę przenieść głowę z powrotem do d - git reset HEAD@{1}.

Uproszczone :

• ~ określa przodków
• ^ określa rodziców

Możesz określić jedną lub więcej gałęzi podczas scalania. Wtedy commit ma dwóch lub więcej rodziców i wtedy {[2] } jest przydatne do wskazania rodziców.

Załóżmy, że jesteś na gałęzi A i masz jeszcze dwie gałęzie: B i C .

Na każdej gałęzi trzy ostatnie commity to:

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

Jeśli teraz na gałęzi A wykonujesz polecenie:

git merge B C

Następnie łączysz trzy gałęzie razem (tutaj twój merge commit ma trzech rodziców)

I

~ wskazuje n ' - ty przodek w pierwszej gałęzi, więc

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

^ oznacza rodzica n ' tego, więc

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

Następne użycie ~ lub ^ obok siebie jest w kontekście commitu wyznaczonego przez poprzednie postaci.

Zawiadomienie 1:

• HEAD~3 jest zawsze równa: HEAD~~~ i: HEAD^^^ (każdy wskazuje A1),

I ogólnie :

• HEAD~n jest zawsze równa: HEAD~...~ (N razy ~) i do: HEAD^...^ (N razy ^).

Zawiadomienie 2:

• HEAD^3 jest Nie to samo co HEAD^^^ (pierwszy wskazuje C3 a drugi wskazuje A1),

I ogólnie :

• HEAD^1 jest tym samym co HEAD^,
• ale dla n > 1: HEAD^n jest zawsze a nie to samo co HEAD^...^ (N razy ~).

TLDR

~ jest tym, czego chcesz przez większość czasu, odwołuje się do poprzednich commitów do bieżącej gałęzi

^ odwołuje się do rodziców (git-merge tworzy drugi rodzic lub więcej)

A~ jest zawsze takie samo jak a^
A~ ~ jest zawsze takie samo jak a^^ i tak dalej
A~2 to nie to samo co a^2 jednak,
ponieważ ~2 jest skrótem od ~~
podczas gdy ^2 nie jest skrótem od niczego, oznacza to 2. rodzic

HEAD^^ jest tym samym co HEAD~3, wybierając trzeci commit przed HEAD

HEAD^2 określa drugi head w commicie scalającym

• HEAD~ określa pierwszego rodzica na"gałęzi"

• HEAD^ pozwala wybrać konkretny rodzic commita

Przykład:

Jeśli chcesz podążać za boczną gałęzią, musisz podać coś w rodzaju

master~209^2~15

Rzeczywisty przykład różnicy między głową~ i głową^

~ to znaczy rodzic.

^ jeśli ma rodziców dwóch lub więcej, np. merge commit, możemy wybrać drugi rodzica lub inny.

Więc jeśli tylko jedna rzecz jak (HEAD~ lub HEAD^), ma same wyniki.

^ Selektor gałęzi
git checkout HEAD^2
Zaznacza drugą gałąź commita (merge), przechodząc do wybranej gałęzi (jeden krok wstecz na drzewie commitów)

~ COMMIT Selector
git checkout HEAD~2
Przesuwa 2 commity do tyłu na domyślnej / wybranej gałęzi

Definiowanie zarówno~, jak i ^ względnych referencji jako selektorów rodzicielskich jest zdecydowanie dominującą definicją opublikowaną wszędzie w Internecie, z którą do tej pory się natknąłem - w tym oficjalnym Git Book. Tak, są to selektory nadrzędne, ale problem z tym "wyjaśnieniem" polega na tym, że jest to całkowicie sprzeczne z naszym celem: czyli jak rozróżnić te dwa... :)

Inny problem polega na tym, że zachęcamy do użycia selektora gałęzi ^ do wyboru zmian (aka HEAD^ = = HEAD~).
Ponownie, tak, możesz go używać w ten sposób, ale nie jest to jego przeznaczony cel. Zachowanie selektora gałęzi ^ do tyłu jest efektem ubocznym, a nie jego celem.

Tylko przy scalonych commitach, czy numer należy przypisać do selektora gałęzi^. W związku z tym jego pełną zdolność produkcyjną można wykorzystać tylko wtedy, gdy istnieje potrzeba wyboru między oddziałami. Najprostszym sposobem wyrażenia zaznaczenia w forku jest przejście na wybraną ścieżkę / gałąź - to jest jeden krok wstecz na drzewie zatwierdzeń. Jest to tylko efekt uboczny, a nie jego główny cel.

Mówiąc najprościej, dla pierwszego poziomu rodzicielstwa (pochodzenie, dziedziczenie, rodowód itp.) HEAD^ I HEAD~ oba wskazują na ten sam commit, który znajduje się (znajduje) jeden rodzic nad głową (commit).

Ponadto HEAD^ = HEAD^1 = HEAD~ = HEAD~1. Ale głowa^^ !/ Align = "left" // Align = "left" / Jednak głowa^^ = Głowa~2. Czytaj dalej.

Poza pierwszym poziomem rodzicielstwa, sprawy stają się trudniejsze, zwłaszcza jeśli działająca gałąź/gałąź master miała połączenia (z innych gałęzi). Jest też sprawa składnia z karetką, HEAD^^ = HEAD~2 (są równoważne) ale HEAD^^ != HEAD^2 (to zupełnie dwie różne rzeczy).

Każdy / karetka odnosi się do pierwszego rodzica głowy, dlatego karetki ułożone razem są równoważne wyrażeniom tyldy, ponieważ odnoszą się do pierwszego rodzica (pierwszego rodzica), itp., itd. oparte wyłącznie na liczbie na połączonych karetkach lub na liczbie po tyldzie (tak czy inaczej, obie oznaczają to samo), tzn. pozostają przy pierwszej rodzic i iść w górę x pokolenia.

HEAD~2 (lub HEAD^^) odnosi się do commita, który jest dwoma poziomami przodków w górę/powyżej bieżącego commita (głowy) w hierarchii, co oznacza commit dziadka głowy.

HEAD^2, z drugiej strony, odnosi się nie do commit pierwszego rodzica, ale po prostu do commit drugiego rodzica. Wynika to z faktu, że karetka oznacza rodzica commita, a Numer poniżej oznacza, do którego / do którego commita nadrzędnego się odnosi (pierwszy rodzica, w przypadku, gdy po karetce nie następuje liczba [ponieważ jest ona skrótem od liczby 1, czyli pierwszego rodzica]). W przeciwieństwie do karetki, liczba, która następuje po nim, nie oznacza kolejnego poziomu hierarchii w górę, ale raczej oznacza, ile poziomów na boki, w hierarchii, trzeba znaleźć właściwego rodzica (commit). W przeciwieństwie do liczby w wyrażeniu tyldy, jest ona tylko jednym rodzicem w hierarchii, niezależnie od liczby (bezpośrednio) postępującej karetka. Zamiast w górę, liczba końcowa opiekuna liczy się bokiem dla rodziców w całej hierarchii [na poziomie rodziców w górę, który jest równoważny liczbie kolejnych opiekunów].

Więc głowa^3 jest równa trzeciemu rodzicowi głowy (nie pradziadkowi, czyli tym, czym byłaby głowa^^ i głowa~3...).

Jeśli zastanawiasz się, czy wpisać HEAD^ Czy HEAD~ w swoim poleceniu, po prostu użyj :

Obie są nazwami tego samego commita - pierwszego rodzica bieżącego commita.

Podobnie z master~ i master^ - obie nazwy dla pierwszego rodzica mistrza.

W taki sam sposób jak 2 + 2 i 2 x 2 są obie 4 - są różne sposoby dotarcia tam, ale odpowiedź jest taka sama.

To odpowiada na pytanie: Jaka jest różnica między HEAD^ I HEAD~ w Git?

Jeśli właśnie wykonałeś scalenie (tak, że Twój bieżący commit ma więcej niż jednego rodzica), lub nadal jesteś zainteresowany działaniem Careta i Tildy, zobacz inne odpowiedzi (których Nie będę powielał tutaj), aby uzyskać szczegółowe wyjaśnienie, a także Jak używać ich wielokrotnie (np.HEAD~~~) lub liczbami (np.HEAD^2). W przeciwnym razie, mam nadzieję, że ta odpowiedź zaoszczędzi ci trochę czasu.