o Ruby

Witam po kolejnej długiej przerwie. Ponieważ ostatnio nie za bardzo mam czas na pisanie porządnych wpisów (czyli takich gdzie muszę dobrze przemyśleć temat, poszperać w internecie, dodać swoje przemyślenia - a zajmuje dobre kilka godzin) to tym razem trochę w innym stylu. Bez kodu, bez przykładów. Ba, temat nawet nie będzie dotyczył Rubiego!

A jak nie chodzi o Ruby to chodzi o Git! Chciałbym podzielić się z Wami moimi spostrzeżeniami na temat tego narzędzia.

Mniej więcej rok temu zetknąłem się z gitem. Pamiętam, że obejrzałem film video Linus Torvalds on git. Chociaż nie do końca trafił do mnie (nie potrafiłem np. pojąć idei rozproszoności), to sposób w jaki Linus opowiadał o nim sprawił, że miałem ochotę zgłębić temat. Tak też zrobiłem. Opinie internautów, jak i moje pierwsze doświadczenie z gitem, potwierdzały, że jest to świetne narzędzie. Niestety okazało się także, że jest to stosunkowo trudne narzędzie.

Początkowe trudności wynikały głównie z dwóch powodów. Po pierwsze git pokazał, że znane mi do tej pory narzędzia do kontroli kodu źródłowego (czyli głównie svn, a w przeszłości także cvs), używam w dosyć prymitywny sposób i ogranicza się to mniej więcej do komend "update, commit, status". Po drugie, toporność pewnych czynności (powiedzmy, że "bardziej zaawansowanych") jakie należy wykonać we wspomnianym svn sprawiała, że albo ich świadomie nie używałem, albo po prostu nie wiedziałem, że istnieją. Z moich obserwacji wynika, że większość programistów ma podobne doświadczenie z svn i podobnymi systemami kontroli wersji. Poniższej zamieszczam dosyć luźno opisane aspektu gita, które najbardziej mnie zaskoczyły, utkwiły w pamięci i zmieniły sposób w jaki teraz tego typu narzędzi używam.

Tworzenie nowego repozytorium

Git od samego początku zachwyca. Założenie nowego repozytorium to kwestia jednego polecenia git init, wydanego z katalogu z projektem. Choć mogłoby się wydawać, że nie jest to zbyt istotne (w końcu jak często zakładamy nowe repozytorium?) to dzięki temu otwierają się przed nami nowe możliwości. Nie raz zdarzało mi się, że musiałem "pogrzebać" w jakimś katalogu/kodzie, ale nie chciałem stracić starej zawartości. Bawienie się w kopie jest uciążliwe, teraz używam do tego gita. Co ciekawe git tworzy tylko jeden katalog o nazwie .git, zatem ewentualne usunięcie repozytorium to kwestia skasowania tego katalogu.

Rozproszoność

Jedną z najczęściej powtarzanych i podkreślanych cech gita jest rozproszoność. W uproszczeniu polega to na tym, że każdy kto skopiuje (sklonuje) repozytorium ma wszystkie zawarte w nim informacje. W szczególności jest to cała historia. Wszystkie te informacje zawarte są we wspomnianym katalogu .git. Od momentu wykonania operacji clone stajemy się właścicielami własnego, prywatnego, lokalnego repozytorium. Jedynie operacje synchronizacji repozytoriów (w końcu musimy wymienić z innymi dane) wymagają dostępu do sieci. Każda inna jest lokalna i nie dość, że mogą nam odciąć kabel a i tak będzie wszystko działać, to jeszcze brak opóźnień operacji sieciowych odczujemy momentalnie (przypomnij sobie te kilkunastosekundowe lagi po wydaniu polecania svn log).

Rozmiar repozytorium

Pomimo tego, że klonując repozytorium gita pobieramy całą jego historię, rozmiar katalogu z projektem nie jest o wiele większy niż gdybyśmy użyli pojedynczego "checkouta" svn, a często jest nawet większy (pamiętajmy, że svn tworzy ogromną ilość podkatalogów o nazwie .svn. Dla przykładu repozytorium ze źródłami Django pod kontrolą gita zajmował 43MB, zaś pod kontrolą svna 61MB (źródło). Z kolei projekt, przy którym obecnie pracuję, przy ponad 3000 rewizjach zajmuje ~22MB z czego 7MB to cała historia, a pozostałe 15MB to rozmiar pojedynczego checkouta.

Gałęzie

Jest to jedna z tych cech gita, o których mógłbym pi(s)ać peany na jej cześć. Przed gitem nigdy nie używałem gałęzi. Projekty były "jednotokowe" (czyli "trunk" i cała naprzód). Brzmi znajomo? Podejrzewam, że tak...

Git maksymalnie upraszcza prace na gałęziach. Tworzenie gałęzi trwa ułamek sekundy (bo tyle trwa utworzenie i zapis 41 bajtów do pliku) a przełączanie się między nimi jest tylko ciut wolniejsze (w praktyce zależy od ilości różnic między przełączanymi gałęziami). Co ciekawe w gicie pracujemy na różnych gałęziach używając tego samego katalogu roboczego - zupełnie inaczej niż w svn, gdzie każda gałąź (tag) jest osobną kopią. Nie musimy się więc ograniczać co do ich ilości (osobiście tworzę osobny branch dla każdej zmiany). Chociaż jeśli komuś ten sposób nie podoba się to nic nie stoi na przeszkodzie by utworzyć dodatkowe klony w oddzielnych katalogach (tylko po co?).

Lokalność

Wspomniałem już o tym, że git jest rozproszony. Pochodną tej cechy jest fakt, że większość operacji na repozytorium jest lokalna. Nie doceniłem tego faktu, aż do wspomnianego momentu, gdy praca z repozytorium była czymś więcej niż "update, commit, status". I tak na prawdę nie chodzi mi o to, że możemy pracować odpięci od sieci (przecież niedużo nam trzeba, żeby mieć internet w lodówce), ale o prędkość i niezależność poleceń. Przykład? A choćby najprostsze git log trwa ułamek sekundy. Chcąc wyszukać commity, które zawierają w zmianach słowo "foo", wpisuję git log -S"foo" i wręcz natychmiast dostaję wyniki (dzięki temu szybko znajdę informację kto i kiedy dodał/usunął daną klasę/metodę itp.). Gdy czeka nas jakieś większe łączenie gałęzi, możemy pociągnąć wszystkie zmiany ze zdalnego repozytorium (git fetch) i od tego momentu działać lokalnie. Wspomniana lekkość i łatwość tworzenia branchy, daje nam możliwość bezstresowego próbowania różnych kombinacji. Jeśli coś nam nie wyjdzie, zawsze możemy szybko wrócić do stanu początkowego.

Perełki

Na koniec zostawiłem kilka ciekawych przykładów. Są to polecenia/narzędzia, która bardzo pozytywnie mnie zaskoczyły. Jednym z najczęściej używanych przeze mnie narzędzi jest gitk. Jest to graficzne narzędzie, które dosyć ładnie zwizualizuje nam powiązania commitów. Z uwagi na niezbyt nowoczesny wygląd GUI, może być z początku odbierany negatywnie, ale szybko się okazuje, że tak nie jest. W szczególności używam go do szybkiego przeglądu ostatnich zmian dokonanych przez innych (czyli robię fetch i przeglądam commity od master..origin/master).

Lista commitów, łatwy dostęp do diffów i inne informacje, które prezentuje nam gitk.

git cherry-pick pozwala na dołączania zmian z wybranych commitów z jednej gałęzi do drugiej. Przydatne jeśli posiadasz w projekcie gałąź rozwojową i produkcyjną i prowadzisz aktualne prace na tej pierwszej, ale czasem chciałbyś pociągnąć pewne zmiany do tej drugiej. Wtedy jednym poleceniem git cherry-pick SHA1 pociągasz zmiany i jeśli nie było konfliktu od razu jest tworzony commit.

Wyobraź sobie taką sytuację. Odpalasz aplikację, klikasz tu i tam, po czym okazuje się, że coś nie działa. Cóż, cudów nie ma, trzeba zlokalizować buga i go naprawić. I tu pojawiają się schody, bo pomimo iż dokładnie wiesz, która linijka powoduje błąd, to nie jesteś w stanie go poprawić bo błąd de facto siedzi w innej części systemu (nie trudno sobie wyobrazić takiej sytuacji, skoro aplikacja może być zależna od wielu zewnętrznych czynników takich jak użyte biblioteki, konfiguracja, system operacyjny, baza danych itp.). Jeśli dodatkowo towarzyszą Ci myśli "przecież to kiedyś działało!" to prawie na pewno potrzebujesz pomocy w postaci git bisect (mój ulubieniec). Idea jest prosta: znajdź pierwszy commit, który spowodował, że coś przestało działać. Jeśli wiesz, że kod sprzed tygodnia działał to informujesz o tym gita, następnie wskazujesz commit niedziałający (np. aktualny master) i rozpoczynasz binarne przeszukiwanie. Git pobiera jakąś wersję projektu, a Ty tylko odpowiadasz czy ten błąd występuje czy też nie. W ten sposób bardzo szybko (przypominam, że wyszukiwanie jest binarne) zostanie znaleziony commit, po którym to nasze "coś" przestało działać. Przyglądając się zmianom, które wniósł, możemy dosyć szybko wywnioskować, co jest przyczyną problemu (przykładowo, ktoś dokonał aktualizacji jakiejś biblioteki).

Podsumowanie

Uważam, że git to wspaniałe narzędzie. Nie jest to lek na całe zło zarządzania projektem od strony kodu źródłowego, ale ułatwia ogromną ilość spraw. Jest na pewno sporo trudniejszy do opanowania niż wspominany svn, ale każda chwila spędzona przy nauce tego narzędzia, zwraca nam się bardzo szybko. Moja osobista rada jest taka: jeśli w swoim zespole chcielibyście użyć tego narzędzia, to dobrze jest by przynajmniej jedna osoba miała dosyć dobrze opanowanego gita i w razie problemów (a na początku będą) będzie interweniować. W przeciwnym wypadku można się zniechęcić i nie dać szansy doznać olśnienia, którego niejeden doznał. Życzę miłego gitowania!