Git log
git log -p -2
pokazuje zmiany wprowadzone przez dwa ostatnie commity
-- decorate dodaje informację o branchach
git log --since=2.years.1month.4weeks.1hour
„s” na końcu okresu nie ma znaczenia
git log --since 2017-06-26 --until 2017-06-30
since = after, until = before
git log --author "Karol Nowak"
git log --graph
git log -S ErrorMappingService
szuka commita który ma w diffie podany tekst
git log -L
git blame od innej strony
składnia start,end:plik bez spacji
start i end to numer albo regex w postaci /regex/
obowiązuje basic regexp (znaki specjalne muszą być poprzedzone \ nie działa alternatywa |
git log -L '/)\{2,3\}/',100:plik
śledzi kod od pierwszego wystąpienia podwójnego nawiasu zamykającego do setnej linii
git log --no-merges
analogicznie z --merges
git log -p -m
pokazuje zmiany wprowadzone w commitach mergujących
git log --grep "regex"
wyszukuje w wiadomościach commitów, może występować wiele razy
--all-match wiadomość musi spełniać wszystkie regexy
-i ignoruje wielkość znaków
-E wykorzystuje extended regexp
git log -g reflog sformatowany jak log
git reflog reflog śledzi każdą zmianę HEADa
git log --pretty=styl
style to:oneline (ma oddzielna komendę --oneline), short, medium (domyślny), full, fuller, email, raw, format (ustawiany ręcznie)
Zakresy commitów i odwołania do rodzica
git log branchOdejmowanyA..branchOdKtoregoOdejmujeB
nienaturalna kolejność
git log ^A B
bez kropek kolejność nie ma znaczenia
git log B --not A
wszystkie trzy poprzednie przykłady pokazują commity które są na branchu B i nie ma ich na A
git log A B ^C
wykorzystując ^ lub --not można porównywać więcej niż 2 commity
-- not odwraca działanie ^ po prawej
git log A...B
wyświetla commity które są tylko na jednym z tych dwóch branchy
git branch --no-merged commit lub --merged wyświetla tylko branche których ostatnie commity są osiągalne z podanego commita (musi być na końcu, domyślnie HEAD)
Przy obu notacjach z kropkami nie wpisanie prawej strony porównuje z HEADem
git log --left-right master...branch pokazuje który commit jest na którym branchu (nie działa dla ..), --chery-pick ignoruje cherry pickowane commity -- cherry-mark oznacza je
git log HEAD^ pokazuje rodzica aktualnego commita
git log HEAD^2 pokazuje drugiego rodzica(przy mergu)
git log HEAD~ pokazuje rodzica aktualnego commita
git log HEAD~3 pokazuje rodzica rodzica rodzica aktualnego commita
git log HEAD^^^ jak wyżej
^ przed referencją to negacja, po referencji to odwołanie do rodzica
git diff
git diff --staged wyświetla różnicę w plikach dodanych do indexu
--cached robi to samo
git diff -U10 pokazuje 10 linii otaczających rożnicę
git diff --stat --shortstat --dirstat
git diff --check sprawdza czy zmiana nie wprowadza zbędnych białych znaków
git diff w czasie konfliktu wyświetla tylko pliki które mają konflikty
po rozwiązaniu konfliktu można użyć parametrów -1 -2 -3 lub ich dłuższych odpowiedników --base, --ours, --theirs do wyświetlenia różnicy aktualnego stanu w stosunku do różnych stron zaangażowanych w merge
git grep
Działa jak linuksowy grep ale umożliwia przeszukiwanie repozytorium we wcześniejszym stanie bez checkoutu. Przeszukuje tylko pliki śledzone przez gita. Pusty łancuch dopasowuje wszystkie linie.
git grep regex HEAD^
-E --extended-regexp umożliwia wpisywanie regexu bez konieczności poprzedzania znaków specjalnych \ zamiast git grep ')\{2,\} można wpisać git grep -E '){2,}' (poprzednia wersja również działa)
git grep -n regex zwraca numery linii, parametry muszą być przed regexem
-count zwraca ilość pasujących linii na plik
-p próbuje wskazać nazwę funkcji w której znajduje się pasująca linia
--break wstawia pustą linię miedzy plikami
--headinginformacje o pliku poprzedzają dopasowania które są wypisane w nowych liniach
Pozostałe
git status -s pokazuje krótki opis stanu repozytorium
git shortlog podsumowuje informacje z git log
-s liczy commity poszczególnych autorów
git show gitowy toString()
wpisane bez parametrów implikuje HEAD jako parametr i pokazuje zmiany wprowadzone w ostatnim commicie
git show HEAD@{2.months} wykorzystuje reflog do pokazania stanu sprzed dwóch miesięcy
git blame -L 12,22 plik pokazuje git blame dla linijek od 12 do 22
jeśli przed hashem w git blame jest ^ to znaczy ze ta linijka nie zmieniła się od początku istnienia pliku
-C próbuje wykryć przenoszenie kodu żeby wskazać autora a nie przenoszącego raz wpisany parametr sprawdza czy kod nie jest skopiowany przeszukując tylko pliki z tego commitu, podany dwa razy szuka też w commicie tworzącym plik, podany trzy razy szuka wszędzie
git bisect start rozpoczyna bisecta
bad commit oznacza commit jako zły
good analogicznie
git bisect start złyCommit dobryCommit1 dobryCommit2 podanie dodatkowych informacji na starcie
po odnalezieniu szukanego commita trzeba wywolac git bisect reset zeby przywrocic HEADa tam gdzie ma byc
Źródła:
„Pro Git” 2nd ed. Scott Chacon, Ben Straub
Dokumentacja gita