Git – rozproszony system kontroli wersji (DVCS)

Ostatnim razem ponarzekałem trochę na SVN i scentralizowany model systemów kontroli wersji. Jedną z wspomnianych alternatyw, realizującą model rozproszony, jest Git – i o nim dzisiaj kilka słów.

Nie zamierzam pisać tutoriala dla Git czy nawet omawiać zasad jego działania. Zamiast tego zbiorę i zaprezentuję garść linków, które warto odwiedzić chcąc zająć się Gitem na poważne. Muszę ostrzec, że zabawa ta nie jest banalna – i nie zawsze przyjemna. Ja korzystam z Gita od ponad pół roku, a mimo to jeszcze do niedawna zdarzało mi się dość regularnie zaglądać do manuala albo coś zamieszać. Za taki stan rzeczy w głównej mierze odpowiadało moje podejście znane z zajebiaszczej bajki: “what does this button do?“. Nie, moi drodzy, w ten sposób nie pracuje się z Gitem. Sytuacja uległa dramatycznej poprawie od czasu, gdy postanowiłem metodycznie NAUCZYĆ SIĘ korzystać z Gita – i zachęcam do podążenia tą właśnie drogą.

Git ma wiele zalet, i większość z nich wynika z jego rozproszonej natury. Nigdy nie trzeba czekać na “właściwy moment” aby wykonać commit. Chcemy zrobić commit – to go robimy. Co ważne: historię repozytorium można ZMODYFIKOWAĆ. Zawsze możemy cofnąć się o kilka wersji, zmienić wiadomość wysłaną z commitem, a nawet złączyć kilka commitów w jeden lub podzielić jeden w kilka! Jednocześnie mamy lokalnie CAŁE repozytorium, z całą historią. A co za tym idzie – osiągamy najlepszą możliwą wydajność przy wszelakich operacjach, ponieważ wszystko odbywa się lokalnie! Diff, merge, log… błyskawica. I wbrew pozorom takie repozytorium wcale nie zajmuje dużo więcej niż analogiczne working copy z SVN! Między innymi dlatego, że (i to jest kolejna spora zaleta) wszystkie informacje o repozytorium zawarte są w jednym miejscu: w katalogu .git umieszczonym w głównym folderze. W porównaniu z syfem generowanym przez SVN jest to naprawdę miła odmiana. Praca offline nie jest też żadnym problemem – taka jest po prostu natura tego modelu. I co najważniejsze: nareszcie nie czuję ŻADNEGO dyskomfortu tworząc nową gałąź. Mało tego – nie mam innego wyjścia, ponieważ w Git WSZYSTKO jest gałęzią. I bardzo dobrze, ponieważ merge działa naprawdę świetnie – i nawet jeśli coś niechcący zepsujemy, to zawsze można wrócić do stanu poprzedniego. Dlatego taki workflow dla każdej, nawet najmniejszej czynności jest całkowicie normalny: branch -> work -> commit -> merge. W SVN niestety sobie tego nie wyobrażam. I na dodatek Git jest napisany… z jajem! Mały przykład: wywołałem kiedyś komendę “git pull“, której zadaniem jest pociągnięcie zmian dokonanych w zdalnym repozytorium. Nie miałem jednak skonfigurowanej definicji żadnego zdalnego repozytorium, więc operacja musiała się zakończyć niepowodzeniem. Jakie było moje zaskoczenie, gdy zamiast standardowego “error” zobaczyłem komunikat “where do you want to fetch from today?“:). Czyżby mały prztyczek z palca Linusa w nos Microsoftu?

O wadach wspomniałem poprzednio, jednak mała powtórka. Git i Windows to niekoniecznie jedna wielka szczęśliwa rodzina. Git został stworzony przez Linusa Torvaldsa – autora jądra Linuxa (co oczywiście wadą nie jest, bo niesie za sobą gwarancję naprawdę porządnie i najsolidniej jak to możliwe wykonanej roboty). Celem powstania systemu było przechowywanie źródeł tegoż Linuxa. A co za tym idzie: raczej nikt nie myślał o nas, upośledzonych w pewnym sensie, programistach wywodzących się z Windowsa, przyzwyczajonych do okienek i wykonujących zdecydowaną większość czynności poprzez jakieś GUI a nie z linii komend. TAK: linia komend jest jest najlepszym (póki co) sposobem na pracę z Gitem. Początkowo podchodziłem do tego sceptycznie, ale po kilku dniach zaczęło mi to odpowiadać. Oprócz lekkiej “niewygody” użytkowania, pod Windowsem Git jest ponoć o wiele wolniejszy niż pod Linuxem. Nie wiem, nie sprawdzałem – ale wierzę na słowo (chociaż i pod Win działa jak dla mnie bardzo sprawnie). Inną wadą jest autentyczna trudność w sprawnym posługiwaniu się Gitem. O ile do zabawy z takim SVNem wystarczy 5 minut – i już możemy włączyć się w normalny tryb pracy zespołowej – o tyle z Gitem prawdopodobnie większości osób będzie trudniej (mi było). Ale tak jak wspomniałem na początku – tego trzeba się po prostu nauczyć (cały czas jestem w trakcie). A, i jeszcze jedna cecha różniąca Git (i chyba większość, jeśli nie wszystkie, DVCSy) od chociażby SVNa – nie ma czegoś takiego jak “partial checkout“. Albo pobieramy całe repozytorium, albo nie pobieramy go w ogóle. Koniec z jednym repozytorium przechowującym pierdyldziesiąt projektów, z którego ciągnie się za każdym razem tylko potrzebną cząstkę.

A teraz kilka linków, które z pewnością przydadzą się każdemu git-masta-wannabe:

• strona projektu: http://git-scm.com/ wraz z dokumentacją i darmową książką utrzymywaną przez społeczność
• instrukcja użytkownika – User’s Manual
• darmowa książka Git Magic
• godzinne wystąpienie Linusa Torvaldsa na temat Gita – naprawdę polecam, bardzo ciekawie się to ogląda
• GitHub – http://github.com/ – najbardziej popularny hosting Git (darmowy dla OpenSource)
• poradnik “Using Git and Github for the Windows for newbies“
• TortoiseGit – port niesamowitego TortoiseSVN, jednak moim zdaniem nie jest tak niezbędny jak w przypadku SVN – dla mnie przydaje się wyłącznie do inwestygacji aktualnego stanu working copy (sprawdzenia co i jak się zmieniło od ostatniego commita oraz przywracania stanu sprzed zmian)
• Git Extensions – narzędzia mające usprawnić pracę z Git po Windows; powiem szczerze, że nawet nie pamiętam co tam jest, pamiętam jedynie że kilka miesięcy temu doszedłem do wniosku, że do niczego mi się to nie przyda… ale może od tamtej pory coś się zmieniło

I to by było na tyle. Zachęcam do poznania Gita, bo oprócz świetnego systemu kontroli wersji jest to po prostu bardzo ciekawy kawałek softu z interesującymi rozwiązaniami, na których opis można natknąć się pod powyższymi linkami. Czytając bardziej zaawansowane opisy jego wewnętrznych mechanizmów trudno oprzeć się wrażeniu, że Linus naprawdę jest swego rodzaju geniuszem (chociaż teksty w stylu “I have only one thing to say for SVN developers: you are stupid!” są lekkim przegięciem;) – cytat z jego wystąpienia podlinkowanego wyżej).

I jeszcze jedno. Wiem, że się powtarzam, ale jeśli nie chcesz ryzykować marnowania zbyt dużo czasu na poznawanie nowego narzędzia, a jednocześnie zależy ci na przesiadce z SVN (czy jakiegokolwiek innego scentralizowanego version-control-system) na DVCS – polecam Mercurial. Pobawiłem się nim bardzo pobieżnie, ale wygląda na idealny rozproszony system kontroli wersji dla programisty Windows. Potężny, a zarazem nieskomplikowany, z doskonałą wręcz dokumentacją. Wszystko (i więcej!), czego w Git uczyłem się miesiącami, tam udało mi się osiągnąć w ciągu 2 godzin od wejścia na stronę! I wygląda na to, że TortoiseHg (klon Tortoise dla Mercuriala) jest sprawnym w 100% odpowiednikiem SVNowego brata.

Czego możecie spodziewać się w najbliższym czasie? Na pisanie tutoriala się nie porywam, zresztą wystarczająco dużo ich jest w sieci. Zapewne pojawi się tu kilka porad “scenariusz -> rozwiązanie” – porobiłem trochę notatek ułatwiających mi codzienną pracę i będę je sukcesywnie przenosił z plików testowych na bloga. Jakby ktoś miał problem z Git to niechaj da znać w komentarzach, jeśli ja nie będę umiał pomóc to pewnie znajdzie się inna dobra dusza, która podzieli się swoją wiedzą.

UPDATE: kolejny fajny link: http://whygitisbetterthanx.com/ – zwięzłe podsumowanie powodów wyższości Gita nad konkurencją.