(część 1 część 2) Naskrobię teraz coś o narzędziach GUI (zarówno pod Linuksem jak i windą) oraz o grzebaniu w historii repozytorium. Git jest całkiem dobrze zaopatrzony w narzędzia do GUIowego śledzenia historii, ale konsolowcy też nie mają się czego wstydzić bo narzędzie git log też dużo potrafi.

Ale na starcie trochę kustomizacji. Na początek powinnieneś przyznawać się do swoich patchy

git config --global user.name "Mariusz Gronczewski"<br /> git config --global user.email "xanigdziestam@poczta.ru"

Następnie dobrze żeby domyślnie robił push tylko aktualnej gałęzi żeby przy każdym nowym projekcie nie spamował nam warninga o tym
<br /> git config --global push.default current<br />
Pewnie kolorki w konsoli tekstowej by sie przydały (bardzo przydatne przy git log -graph)
<br /> git config --global color.ui auto<br />
Wracając do logów

zacznę od komendy git log, daje nam ono log w długim formacie z pełnym hashem, datą i autorem wraz z emailem oraz pełnym komentarzem, np:

commit 0cc57e3f854e7903d7ec46d8d4b0e46bba4a8739
Author: Florian Forster
Date:   Sat Oct 10 17:04:09 2009 +0200

    network plugin: Implement statistics collection about the plugin itself.

Jeżeli nie chcesz całego logu od czasu powstania projektu możesz wybrać część z historii przez podanie odpowiednich parametrów, takich jak:

• -5 – 5 ostatnich commitów
• --since="2008-01-01" – wszystko po 2008
• --until="2 weeks ago" – wszystko oprócz ostatnich 2 tygodni (można ofc łączyć z since)
• 0d8ba9a..4f0c7b9 –  od hasha 0d8ba9a do hasha 0d8ba9a. Są to hashe skrócone czyli pierwsze 7 liter hasha,  można ofc użyć pełnych
• --author="Ktoś" – tylko commity gdy autor zawiera w sobię podany ciąg znaków (case-sensitive)
• hamster.c – tylko commity z plikem hamster.c

Jeżeli dodasz --stat dostaniesz statystyki nt. ile zmian wprowadził każdy commit i w jakich plikach,
--shortstat podobnie tylko w krótszej wersji (sama ilość, bez plików),
--name-status, same pliki + literka oznaczajaca czy plik został dodany, zmodyfikowany czy usunięty
-p wygeneruje dodatkowo diffy każdego commita
--no-merges jak nazwa wskazuje, nie pokazuje commitów które powstały przez merge gałęzi

Teraz coś o krótszych formatach (wszystkie podane wyżej opcje dalej z nimi działają)
--pretty=short – sam autor, hash commitu i tytuł (pierwsza linijka komentarza)
--pretty=oneline – jedna linijka, pełen hash + tytuł
--pretty=full i fuller – więcej szczegółów, rzadko używane
--graph – tekstowy “wykres”, podobny jaki generują GUIowe narzędzia, podane wyżej opcje wpływają na ten graf

Oprócz log, przydatną komendą jest git blame, pokazuje ona kto jest autorem każdej linijki i do jakiego commitu należy zmiana np.

86c466db (xani 2009-09-12 13:19:44 +0200   1) #!/usr/bin/perl
6f683b75 (xani 2009-09-12 13:01:02 +0200   2) use Linux::Inotify2;
91cd27a5 (xani 2009-09-12 14:24:15 +0200   3) use Thread;

git log ma znacznie więcej opcji, po resztę zapraszam do man git-log, a teraz coś na GUI ;]. Pod Linnuksem bawiłem się dwoma narzędziami, gitk i gitg.

Gitk jest starszym z tych dwóch i także brzydszym, oparty jest o Tcl/Tk przez co w efekcie nie grzeszy wyglądem ;]. Ale oprócz tego działa całkiem nieźle, można nim zrobić właściwie wszystko co było możliwe w jego konsolowym odpowiedniku. Jedyne co mnie trochę denerwuje to to że domyślnie pokazuje tylko domyślną gałąź i żeby pokazywał wszystkie trzeba go odpalić z opcją –all, podczas gdy w gitg wystarczy tylko wybrać all branches w menu

Gitg jest dosyć nowym (wersja 0.0.5) napisanym pod gnome (więc wygląda dużo lepiej) viewerem logów, niestety akutalnie ma problem że gdy color.ui ustawione jest na “always” (auto działa) to diffy wyglądają trochę krzaczaście, oraz samo wyszukiwanie wymaga jeszcze trochę pracy (nie można np. wyszukać po autorze), ale ogólnie jeżeli bardziej zaawansowane funkcje są niepotrzebne to jest to przyzwoity soft, a te jeden na 1000 przypadków gdy jednak trzeba zrobić coś bardziej zaawansowanego ,zawsze jest konsola ;]

I to chyba tyle jeżeli chodzi o logi, w następnej części postaram się napisać o zaawansowanych funkcjach (branching, merging, rebasing) i jak za ich pomocą wprowadzić porządek w repo, potem może coś o narzędziach na windę, pewnie skrobnę jak zarządzać configami przez git. W międzyczasie polecam gitcast.com i gitready.com, świetne źródła informacji i trików nt. git-a.