Git
Składnia wersji Git

Uwagi

Określanie wersji według nazwy obiektu

$ git show dae86e1950b1277e545cee180551750029cfe735
$ git show dae86e19

Możesz określić wersję (lub w rzeczywistości dowolny obiekt: znacznik, drzewo, tj. Zawartość katalogu, obiekt blob, tj. Zawartość pliku), używając nazwy obiektu SHA-1, pełnego 40-bajtowego ciągu szesnastkowego lub podłańcucha, który jest unikalny dla repozytorium.

Symboliczne nazwy referencyjne: gałęzie, tagi, gałęzie zdalnego śledzenia

$ git log master    # specify branch
$ git show v1.0     # specify tag
$ git show HEAD     # specify current branch
$ git show origin   # specify default remote-tracking branch for remote 'origin'

Możesz określić wersję za pomocą symbolicznej nazwy ref, która obejmuje gałęzie (na przykład „master”, „next”, „Maintenance”), tagi (na przykład „v1.0”, „v0.6.3-rc2”), zdalne- śledzenie gałęzi (na przykład „origin”, „origin / master”) oraz specjalne referencje, takie jak „HEAD” dla bieżącej gałęzi.

Jeśli symboliczna nazwa odwołania jest niejednoznaczna, na przykład jeśli masz gałąź i znacznik o nazwie „fix” (nie zaleca się posiadania gałęzi i znacznika o tej samej nazwie), musisz określić rodzaj odwołania, którego chcesz użyć:

$ git show heads/fix      # or 'refs/heads/fix', to specify branch
$ git show tags/fix       # or 'refs/tags/fix', to specify tag

Wersja domyślna: HEAD

$ git show         # equivalent to 'git show HEAD'

„HEAD” nazywa zatwierdzenie, na podstawie którego dokonano zmian w drzewie roboczym, i jest zwykle nazwą symboliczną dla bieżącej gałęzi. Wiele (ale nie wszystkie) poleceń, które przyjmują parametr zmiany domyślnie na „HEAD”, jeśli go brakuje.

Referencje referencji: @ { }

$ git show @{1}            # uses reflog for current branch
$ git show master@{1}      # uses reflog for branch 'master'
$ git show HEAD@{1}        # uses 'HEAD' reflog

Ref, zazwyczaj gałąź lub HEAD, po którym następuje sufiks @ ze specyfikacją porządkową zawartą w parze nawiasów klamrowych (np. {1} , {15} ) określa n-tą poprzednią wartość tego ref w twoim lokalnym repozytorium . Możesz sprawdzić ostatnie wpisy --walk-reflogs polecenia git reflog --walk-reflogs lub opcji --walk-reflogs / -g , aby uzyskać git log .

$ git reflog
08bb350 HEAD@{0}: reset: moving to HEAD^
4ebf58d HEAD@{1}: commit: gitweb(1): Document query parameters
08bb350 HEAD@{2}: pull: Fast-forward
f34be46 HEAD@{3}: checkout: moving from af40944bda352190f05d22b7cb8fe88beb17f3a7 to master
af40944 HEAD@{4}: checkout: moving from master to v2.6.3

$ git reflog gitweb-docs
4ebf58d gitweb-docs@{0}: branch: Created from master

Uwaga : używanie reflogów praktycznie zastąpiło starszy mechanizm wykorzystywania ref ORIG_HEAD (w przybliżeniu równoważny HEAD@{1} ).

Referencje referencji: @ { }

$ git show master@{yesterday}
$ git show HEAD@{5 minutes ago}   # or HEAD@{5.minutes.ago}

Ref, po którym następuje sufiks @ ze specyfikacją daty zawartą w parze nawiasów klamrowych (np. {yesterday} , {1 month 2 weeks 3 days 1 hour 1 second ago} lub {1979-02-26 18:30:00} ) określa wartość referencji we wcześniejszym momencie (lub najbliższym jej punkcie). Zauważ, że to sprawdza stan twojego lokalnego ref w danym momencie; np. co było w twoim lokalnym oddziale „master” w zeszłym tygodniu.

Możesz użyć git reflog ze specyfikatorem daty, aby sprawdzić dokładny czas, w którym zrobiłeś coś dla danego ref w lokalnym repozytorium.

$ git reflog HEAD@{now}
08bb350 HEAD@{Sat Jul 23 19:48:13 2016 +0200}: reset: moving to HEAD^
4ebf58d HEAD@{Sat Jul 23 19:39:20 2016 +0200}: commit: gitweb(1): Document query parameters
08bb350 HEAD@{Sat Jul 23 19:26:43 2016 +0200}: pull: Fast-forward

Oddział śledzony / wyjściowy: @{pod prąd}

$ git log @{upstream}..       # what was done locally and not yet published, current branch
$ git show master@{upstream}  # show upstream of branch 'master'

Przyrostek @{upstream} dołączony do nazwy gałęzi (skrócona <branchname>@{u} ) odnosi się do gałęzi, na którą gałąź określona przez nazwę gałęzi ma być zbudowana na górze (skonfigurowana z branch.<name>.remote i branch.<name>.merge lub z git branch --set-upstream-to=<branch> ). Brakująca nazwa gałęzi jest domyślnie ustawiona na bieżącą.

W połączeniu ze składnią zakresów rewizji bardzo przydatne jest zobaczenie zatwierdzeń, które twój oddział wyprzedza w górę (zatwierdzenia w lokalnym repozytorium jeszcze nie są obecne w górę), oraz jakie zatwierdzenia jesteś za (zatwierdzenia w górę nie są scalone z lokalnym oddziałem), lub obie:

$ git log --oneline @{u}..
$ git log --oneline ..@{u}
$ git log --oneline --left-right @{u}...  # same as ...@{u}

Zatwierdź łańcuch przodków: ^, ~ itd.

$ git reset --hard HEAD^             # discard last commit
$ git rebase --interactive HEAD~5    # rebase last 4 commits

Przyrostek ^ do parametru zmiany oznacza pierwszego rodzica tego obiektu zatwierdzenia. ^<n> oznacza <n> -tego rodzica (tj. <rev>^ jest równoważne <rev>^1 ).

Przyrostek ~<n> do parametru rewizji oznacza obiekt zatwierdzenia, który jest przodkiem nazwanego obiektu zatwierdzenia <n> -tej generacji, podążając tylko za pierwszymi rodzicami. Oznacza to, że na przykład <rev>~3 jest równoważne <rev>^^^ . Jako skrót, <rev>~ oznacza <rev>~1 i jest równoważne z <rev>^1 lub <rev>^ w skrócie.

Ta składnia jest możliwa do skomponowania.

Aby znaleźć takie symboliczne nazwy, możesz użyć polecenia git name-rev :

$ git name-rev 33db5f4d9027a10e477ccf054b2c1ab94f74c85a
33db5f4d9027a10e477ccf054b2c1ab94f74c85a tags/v0.99~940

Zauważ, że --pretty=oneline a nie --oneline należy użyć w poniższym przykładzie

$ git log --pretty=oneline | git name-rev --stdin --name-only
master Sixth batch of topics for 2.10
master~1 Merge branch 'ls/p4-tmp-refs'
master~2 Merge branch 'js/am-call-theirs-theirs-in-fallback-3way'
[...]
master~14^2 sideband.c: small optimization of strbuf usage
master~16^2 connect: read $GIT_SSH_COMMAND from config file
[...]
master~22^2~1 t7810-grep.sh: fix a whitespace inconsistency
master~22^2~2 t7810-grep.sh: fix duplicated test name

Dereferencing gałęzi i tagów: ^ 0, ^ { }

W niektórych przypadkach zachowanie polecenia zależy od tego, czy nadano mu nazwę gałęzi, nazwę znacznika, czy dowolną wersję. Możesz użyć składni „usuwania odnośników”, jeśli potrzebujesz tej drugiej.

Sufiks ^ po którym następuje nazwa typu obiektu ( tag , commit , tree , obiekt blob ) zawarty w parze nawiasów klamrowych (na przykład v0.99.8^{commit} ) oznacza dereferencję obiektu w <rev> rekurencyjnie aż do obiektu typu <type> został znaleziony lub obiekt nie może być już wyrejestrowany. <rev>^0 to skrót dla <rev>^{commit} .

$ git checkout HEAD^0    # equivalent to 'git checkout --detach' in modern Git

Sufiks ^ po którym następuje pusta para nawiasów klamrowych (na przykład v0.99.8^{} ) oznacza rekurencyjne v0.99.8^{} znacznika, dopóki nie zostanie znaleziony obiekt inny niż znacznik.

Porównać

$ git show v1.0
$ git cat-file -p v1.0
$ git replace --edit v1.0

z

$ git show v1.0^{}
$ git cat-file -p v1.0^{}
$ git replace --edit v1.0^{}

Najmłodsze pasujące zatwierdzenie: ^ {/ },: /

$ git show HEAD^{/fix nasty bug}   # find starting from HEAD
$ git show ':/fix nasty bug'       # find starting from any branch

Dwukropek („ : ”), po którym następuje ukośnik („ / ”), po których następuje tekst, zatwierdza nazwę, której komunikat zatwierdzenia pasuje do określonego wyrażenia regularnego. Ta nazwa zwraca najmłodsze pasujące zatwierdzenie, które jest dostępne z dowolnego numeru referencyjnego. Wyrażenie regularne może pasować do dowolnej części komunikatu zatwierdzenia. Aby dopasować wiadomości zaczynające się od łańcucha, można użyć np . :/^foo . Specjalna sekwencja :/! jest zarezerwowany dla modyfikatorów tego, co jest dopasowane. :/!-foo wykonuje dopasowanie negatywne, podczas gdy :/!!foo dopasowuje literał! znak, a następnie foo .

Sufiks ^ do parametru rewizji, po którym następuje para nawiasów zawierających tekst prowadzony ukośnikiem, jest taki sam, jak składnia :/<text> poniżej, że zwraca najmłodsze pasujące zatwierdzenie, które jest dostępne z <rev> przed ^ .