git-identyfikowanie-rewizji

Git – identyfikowanie rewizji

Identyfikowanie rewizji, czyli jak odnieść się do komita istniejącego w naszej historii. Napiszę jakie są możliwe sposoby wraz z przykładami. Zapraszam 🙂

Pełny SHA-1

Pospolicie commit, profesjonalnie identyfikator rewizji czyli 40-znakowy skrót SHA-1. Polecenie:

Spowoduje wyświetlenie wszystkich rewizji, każdy w jednej linii z informacją: sha1 a następnie wiadomość commita. Przykład:

Każda rewizja jest identyfikowana unikalnym 40-znakowym skrótem SHA-1. Aby przywrócić obszar roboczy, ze stanu konkretnej rewizji, należy wydać polecenie:

W tym przypadku nasz obszar roboczy będzie posiadać stan plików z komitu ‚a’ oraz ‚b’.

Skrócony SHA-1

Zamiast podawać pełnego skrótu SHA-1 możemy podać jego skróconą wersję, która wynosi 4 znaki. Jest jeden warunek, dana rewizja musi być unikatowa. Jeżeli w historii będą dwie rewizje, które mają taki sam początkowy SHA-1, wtedy komenda nie zadziała. Gdy okaże się, że skrócony zapis nie działa, wtedy należy podać więcej niż 4 znaki. Przykład:

Ilość znaków, jakie podamy podczas polecenia git checkout jest nie ważna, ważne, aby ilość znaków SHA-1 była unikatowa.

Znaczniki

Jeżeli rewizje oznaczymy znacznikiem

wówczas poniższe polecenia działają tak samo:

HEAD

HEAD wskazuje ostatnią rewizję w bieżącej gałęzi.

Poniższe polecenia są równoznaczne

Przywracanie rewizji domyślnej

Inaczej mówiąc, rewizja domyślna działa tak samo, jak rewizja z HEAD, różnica jest w zapisie. Poniższe polecenia działają tak samo:

Repozytoria nieliniowe

Słowo wstępu, jeżeli nie wiesz, czym jest gałąź (ang. branch), nie przejmuj się :), te elementy zostaną omówione w kolejnych wpisach. Przykłady z nieliniową historią rewizji ma pokazać, że git nie ogranicza się tylko do historii liniowej.

Powyższe przykłady pokazują historie rewizji w jednej linii tzn z jednym rodzicem.

W git istnieją gałęzie (ang. branch), pozwalają one na utworzenie historii nieliniowych, będę pisać o tym w dalszej części serii.

Przykład historii wieloliniowej:

Oba przykłady mają wspólny element, mowa o rodzicach (ang. parent revision, parent node).
Używając Gita możemy, identyfikować rodziców za pomocą specjalnych znaków:

Komity opisujemy tutaj znakiem X. Liczbą naturalną jest n, która wskazuję na konkretnego rodzica. Znak ~ wskazuję na przodka n-tej generacji, zaś ^ mówi o n-tym rodzicu.

Kolejność rodziców

Mając w historii wielu rodziców, warto wiedzieć jaka jest kolejność, który jest pierwszy, drugi i ostatni…
Zaprezentuję to na przykładzie:

Polecenie git log pokaże następujące wiadomości:

Czyli pierwszym rodzicem rewizji Merged commit jest one commit, a drugim rodzicem jest two commit.
Mówiąc inaczej, pierwszym rodzicem w historii rewizji, zawsze jest ten najniżej. Gdy spojrzymy na wynik w konsoli, najniższym będzie pierwszy z lewej strony na samym dole. Przykład konsoli:

Przodek n-tej generacji

Teraz zidentyfikujemy rewizję za pomocą wcześniej wspomnianym przykładzie X~n. Odwołamy się do n-tego przodka w historii liniowej, czyli takim z jednym rodzicem.

W miejsce znaku n podajemy liczbę kroków, o jaką należy cofnąć się w historii. Powyższy przykład mówi nam: X jest dzieckiem, X~1 ojcem, X~2 dziadkiem itp

W miejce X wstawiamy przykładowo znak SHA-1, pełny albo skrócony, można podać HEAD(czyli zaczynamy od dziecka) oraz znaczniki (ang.tags):

Jeżeli historia rewizji mam kilku rodziców, zapis X~n dotyczny zawsze pierwszego rodzica.

n-ty rodzic

Aby, odwołać się do konkretnego rodzica należy użyć schematu X^n. Tak X^1 wskazuje na pierwszego rodzica, X^2 drugiego itp

Używać komendy X^n możemy tak samo pracować, jak z X~n. Utworzyłem jeden plik a.txt w gałęzi master. Stworzyłem Gałąź A, B i C w każdej z gałęzi robiłem edycje na pliku a.txt. Gałąź główną master scaliłem z gałęziami A, B i C. Obecnie nasz ostatni commit ma plik a.txt, który był edytowany przez 3 różne źródła, teraz doskonale zobaczymy jaki rodzic, jakie zmiany wprowadził za pomocą komendy X^n.
Przykład: (ten przykład wykonuj na konsoli git bash)

Sprawdzanie n-tego rodzica dla danego pliku. Powtarzam po raz kolejny :), Jeżeli nie rozumiesz powyższego przykładu, nie przejmuj się, w kolejnej serii będą wpisy dotyczące gałęzi oraz operacji na nich, wtedy ta podkategoria będzie czytelniejsza. Jedyne co z tego podtytułu należy wiedzieć to, że identyfikacje rewizji możemy robić na wiele sposobów. 🙂

Dziennik reflog

W git posiadamy dziennik reflog, w tym dzienniku zapisywane są identyfikatory bieżących rewizji. Gdy wykonujemy operacje na rewizji i ‚zapisujemy’ nasze zmiany, wtedy do dziennika reflog trafiają kolejne wpisy.

Do sprawdzenia zawartości dziennika używamy polecenia: git reflog
Przykład:

Dziennik reflog jest przydany, gdy chcemy wrócić do stanu kodu przed mergem gałęzi, albo gdy popełnimy jakiś faux-pas i będziemy chcieli wrócić do poprzedniego stanu. Przechodzenie do stanu z danego wpisu z reflog należy użyć polecenia git checkout HEAD@{n}, gdzie n jest liczbą naturalną i oznacza n-ty od góry wpis.

Aby sprawdzić dziennik dla innej gałęzi, należy wydać polecenie git reflog NazwaGalezi.
Przykład:

W dzienniku reflog możemy poruszać się nie tylko za pomocą konkretnej liczby, mam tutaj na myśli n z HEAD@{n}. Oprócz tego można użyć jednostki w czasie np: godziny, bądź daty.

Poniższy przykład pokaże nam dziennik reflog z gałęzi master pokazując rewizje ze stanu godzinę temu, czyli wszystkie operacje na rewizjach wykonane jedną godzine wstecz od aktualnej:

Tutaj podobnie ale dostaniemy informację stanu gałęzi master z dnia 11 kwietnia roku 2018 o godzinie 16:30:00

Poprawne formaty:
@{yyyy-mm-dd.hh:mm:ss}
@{n.minute.ago}
@{n.hour.ago}
@{n.day.ago}

Aby wyczyścić dziennik reflog, użyjemy komendy:
git reflog expire –all –expire=now

Podsumowanie

Dotarliśmy do końca 🙂 w tym wpisie było dużo informacji na temat rewizji oraz informacji o tematyce, która zostanie poruszona w dalszych wpisach mam tu na myśli temat gałęzi i poruszania się po nich. Informację na temat dziennika reflog są bardzo pomocne, mi w pracy z Git’em ten dzienniczek bardzo pomógł, gdy jeszcze byłem początkującym ‚git-owcem’ :D.

Jeżeli coś jest nie jasne, czegoś nie rozumiesz, albo zauważyłeś błąd, bądź po prostu chcesz wyrazić swoją opinię, zapraszam Cię do skomentowania, bądź bezpośredniego kontaktu e-mailowego do mnie 🙂

 

 

 

Pozdro 🙂
 

 

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*