Git, EGit i Gerrit …

Podczas prac nad moją pracą inżynierska mam przyjemność używać git’a jako systemu kontroli wersji. Żeby współpraca układała się „zgrabniej” używam wtyczki do Eclipse‘a EGit znajdującej się w inkubatorze Eclispe Fundation (kilka dni temu zdarzyło się mi popełnić mały artykuł na temat EGit’a).

W naszej współpracy brakowało mi pewnych dwóch małych wodotrysków w dialogu do wybierania gałęzi, mianowicie reakcji na podwójne kliknięcie w nazwę gałęzi oraz poruszania się po drzewie za pomocą kursorów. Pomyślałem sobie, że warto by było chłopaków wesprzeć w pracy, w końcu odwalili kawał dobrej roboty … tak więc stworzyłem odpowiednią poprawkę. Niby nic wielkiego … do czasu … okazuje się projekt ten używa rozbudowanego narzędzia do przeglądania (review) i współtworzenia (conribute) kodu no i właśnie tutaj znajduje się problem … ale do rzeczy.

Gerrit, jest rozbudowanym (przynajmniej z mojego punktu widzenia) narzędziem do zarządzania rozproszonym projektem. Wymusza on pewien system pracy. Każdy patch musi zostać przejrzany oraz oceniony zanim trafi do głównego repozytorium. Nad każdą poprawką odbywa się głosowanie; dopiero po uzyskaniu odpowiedniej liczby głosów (od osób uprawnionych) zostanie ona włączona do głównej gałęzi kodu. Dodatkowo każdą linie poprawki można skomentować co ułatwia współpracę w rozproszonym zespole, zwłaszcza z nowymi jego członkami. Wprowadzane poprawki do poprawki ( 😉 ) np. na podstawie komentarzy, są widoczne w jednym miejscu. Całość od strony interfejsu wygląda ładnie i przejrzyście (osobiście nie miałem najmniejszych kłopotów żeby się „połapać” w tym web’owym interfejsie).

Projekt EGit udostępnia dokumentację ułatwiającą rozpoczęcie współpracy z Gerrit’em. Bezproblemowo przez nią przebrnąłem, stworzyłem potrzebne konto, dodałem klucz publiczny, odpowiednio skonfigurowałem Git’a dodając hook‘i … więc można zaczynać zabawę. ;>

Szybkie ogarnięcie w kodzie, lokalizacja odpowiedniej klasy, chwila google’ania o SWT … i gotowa jest poprawka. Szybki commit do lokalnego repo, potem wypchnięcie tego do Gerrit’a … i oczekiwanie na werdykt developerów ;>

Minęły 3 dni … jest pierwszy werdykt … -1 :|. Z mojego pośpiechu wkradły się dwie literówki błąd dość infantylny … no i nie trzymam standardów formatowania (nie potrzebnie ujmuję w klamry jedno-instrukcjowe linie w if’ach i else’ach). Trzeba to poprawić … no i tutaj właśnie zaczęły się strome schody …

Zrobiłem poprawkę, commit, push … Gerrit zamiast dodać tą poprawkę do już istniejącej wyodrębnił to jako zupełnie osobną zmianę … nie tak się umawialiśmy, nie tak miało być.

Jak się po chwili okazuje, EGit nie wspiera hook’ów … w ogóle ich nie używa tak więc w moim commit’cie zabrakło jednej bardzo ważnej linii:

Change-Id:

Teraz muszę to jakoś ręcznie połączyć …

Nie równa walka trwała dwie czy trzy godziny … w tym czasie za-spamowałem trochę skrzynki mailowe commit‘erą, bo dostają maila o każdej nowej poprawce zgłoszonej do systemu, a ja takich nie prawdziwych poprawek podczas walki wprowadziłem :/. Na szczęście całość zakończyła się sukcesem. Tak więc co zrobić jeżeli wypchniemy do Gerrit’a naszą zmianę bez Change-Id i chcemy do niej wprowadzić poprawkę ?

Najpierw musimy się na pewno znajdować w odpowiednim miejscu historii Git’a. Tak więc na początku tworzymy sobie nową gałąź i przełączamy się na nią (oczywiście wszystko robimy z linii poleceń):

git branch fixes
git checkout fixes

Za pomocą git log znajdujemy commit który wypchnęliśmy do repozytorium, niech to będzie np. f4a33b1 (wystarczy 6 pierwszych znaków z SHA-1) i cofamy się w czasie:

git reset –hard  f4a33b1

Dokonujemy potrzebnych zmian, za pomocą git add dodajemy nasze zmiany do commit’a i (ważne), poprawiamy ostatni commit (czyli ten f4a33b1):

git commit –amend

Najlepiej w samej treści wiadomości dołączonej do commit‘a nic nie zmieniać, zatwierdzamy commit wychodząc z edytora. Teraz ponownie odpalamy git log i zapisujemy/zapamiętujemy 6 pierwszych znaków z nowego commit’a (na pewno będą różne od poprzednich), np. ee421a. Wypychamy naszą poprawkę do repozytorium

git push ssh://username@egit.eclipse.org:29418/egit.git ee421a:refs/for/master

Po chwili powinniśmy dostać maila potwierdzającego wprowadzenie zmian.

Uff, to na tyle. Być może jest na to lepszy sposób … ale ten na pewno działa (a nie chcę wystawiać cierpliwości developerów EGit’a na zbyt dużą próbę).

BTW. Ten post starałem się pisać bez zbędnych anglikanizmów … wyszło to raczej średnio, nie mogłem skojarzyć odpowiedniego polskiego odpowiednika dla commit oraz hook.

JGit + EGit = Eclipse Git support

Jakiś czas temu projekty jgit (czyli implementacja git‘a w java’ie) oraz egit (plugin do eclipse’a dodający wsparcie dla git’a) znalazły się w inkubatorze fundacji Eclipse. Dawno temu wyczytałem nawet, że git ma zastąpić CVS‘a na miejscu domyślnego systemu kontroli wersji w IDE … ale zanim to nastąpi upłynie pewnie jeszcze sporo czasu … nie mniej jednak już teraz można podejrzeć jak się mają rzeczy, co też właśnie w uczynię ;).

Może na początek kilka numerków 3.5.2 oraz 0.6.0.201002030558, nie nie są to numery dużego lotka ;). Pierwszy oczywiście opisuje aktualną wersje stabilną Eclipse, drugi zaś jest numerem wersji egit/jgit.

Pierwotnie stroną domową obu projektów było jgit.org (tutaj też znajduje się update site dla eclpse‘a) ale po przejściu projektu pod skrzydła Eclipse Fundation dostępne są dwie stronki eclipse.org/egit/ oraz eclipse.org/jgit/ na obu w sekcji download znajdziemy ten sam link do update site’u:

http://download.eclipse.org/egit/updates

Ja używam ciągle starego update site‘u:

http://www.jgit.org/updates

Z tego co sprawdziłem to podana wcześniej wersja jest dostępna tylko w drugim repo, możliwe że jest to jakiś nightly build czy coś “nie stabilnego” … nie wiem, u mnie działa ;>

W tym wpisie chciał bym omówić jak “podłączyć” nowy projekt pod git SCM (zakładając, że wcześniej nie współdzieliliśmy go w żadnym SCM‘ie). Jeżeli chodzi natomiast o dodanie istniejącego już projektu podpiętego pod jakieś git‘owe repo to robi się to przez File -> Import, nie ma do tego nowej perspektywy wszystko robią wizard‘y.

Tak więc dla przykładu zakładamy sobie nowy projekt GitTest, dodajemy tam jedną klasę Main z “standardowym”

System.out.println("Hello git!");

Następnie na tak spreparowanym projekcie klikamy prawym myszy i wybieramy po kolei Team -> Schare Project… z dostępnej listy oczywiście wybieramy git. Jeżeli plugin znajdzie w jakimś katalogu nadrzędnym katalog .git (czyli miejsce gdzie git przechowuje swoje metadane) to zasugeruje podpięcie się pod już istniejące repo. W moim przypadku taka sytuacja nie występuje.

Zaznaczmy nasz projekt, klikamy w Create Repository, następnie w Next i oto wykonaliśmy odpowiednik git init … sam nie wiem co jest prostsze, chyba jednak wolał bym to zrobić z “palca”.

Skoro już zainicjalizowaliśmy nasze repo trzeba by je czymś wypełnić, czyli wykonać odpowiednik git add. Spokojnie, wszystko można wyklikać 😉 tak wiec zaczynajmy klikać ;>. Parawym myszy na pliku/katalogu który chcemy dodać (w moim wypadku jest tylko jeden katalog src) i poklei Team -> Add to version control.

Kolejny krok to git commit. Znowu to wyklikamy ;> Team -> Commit. Możemy teraz dodać komentarz do commit‘a jak również odznaczyć pliki które nie chcemy dodać do repo. Po kliknięciu w Commit nasze zmiany zostaną zapisane w repozytorium.

Jako że przez pomyłkę na dodałem cały projekt do commita (Team -> Add to version control) również “nie chciane pliki” takie jak .setting, .classpath oraz .project dodały się co commit‘a. W takim wypadku odpalamy widok Navigator i na każdym takim pliku wykonujemy po kolei operację Team -> Remove from version control, Team -> Add to .gitignore. Tak powstały plik .gitignore dodajemy do git‘a i commit‘ujemy (czyli: Team -> Add to version control, Team -> Commit).

Pora zrobić coś bardziej szalonego … zmieńmy zawartość Main.java ! Żeby za bardzo nie szaleć ja dodałem dodatkowy wykrzyknik na końcu “Hello git!” ;>. Zapisujemy zmiany. Eclipse automatycznie (podobnie z resztą jak to ma miejsce podczas korzystania z CVS‘a) informuje nas o tym, że względem repozytorium nasz plik jest zmieniony. Jak sprawdzić zmiany ? Nie ma czegoś takiego jak Synchronize with repository … ale jest za to: Compare with -> Git index. Moje „szalone zmiany” są widoczne jak na dłoni … albo jak kto woli “jak na CVS’ie” 😉

Niestety na chwilę obecną nie dopatrzyłem się żadnych możliwości porównania całego projektu, jak to jest możliwe w CVS’ie. Trzeba porównywać każdy plik z osobna … jest to trochę męczące ale mam nadzieje, że w kolejnych wydaniach taka funkcjonalność zostanie “jakoś” zaimplementowana oraz dodana.

Po sprawdzeniu jakie zmiany, względem repo, wprowadziliśmy w naszym projekcie możemy śmiało wyklikać Team -> Commit na naszym zmienionym pliku. W ten sposób moje repo zawiera już 3 commit‘y ;>

Może teraz sobie po-branch‘ujemy. Prawie standardowo klikamy na projekt i wybieramy Team -> Branch… wyskakuje nam okienko w którym możemy dodać nową gałąź, zmienić jej nazwę oraz przełączyć się na wybraną gałąź. Aktualna gałąź jest pogrubiona oraz dodatkowo oznaczona przypisem (current). Klikamy w New branch nazwa jest praktycznie dowolna, ja nazwałem nowy branch jako “awesome-changes” ;), akceptujemy zaznaczamy nowo dodany branch i klikamy Checkout, żeby się na niego przełączyć. Prawda, że proste ? 😉

Teraz jeżeli klikniemy na projekt prawym myszy i z menu wybierzmy Team -> Show in Resource History widzimy historię zmian w naszym projekcie.

Niestety na chwilę obecną plugin nie pozwala merge‘ować branch‘y … szkoda, trzeba to robić ręcznie z linii poleceń czyli git merge <target> <source>.

Dostępna jest natomiast opcja nadpisywania poczynionych zmian. Przez Team -> Reset można wykonać reset wprowadzonych zmian do poziomu w wskazanej gałęźi.

To tyle mojego małego przeglądu, więcej informacji można znaleźć w User Guide EGit‘a.

Gitosis dodanie repo

Prace nad programem do inżynierki zaszły już tak “daleko”, że wypadało by gdzieś ten kod przetrzymywać dla bezpieczeństwa. Dobrym dodatkowym feature’m byla by też możliwość jego wersjonowania … jako, że jakiś temu postawiłem sobie własne repo git’a (dwie (1, 2) z zamierzonych trzech części opisu instalacji zostały już opublikowane) wybór był oczywisty.

Początkowo zadanie wydawało się bardzo banalne … dodać repozytorium do gitosis i wszystko powinno się zrobić automatycznie … cóż tak niestety nie było. Dla potomności (oraz mojej często wątpliwej pamięci) postanowiłem opisać całą procedurę.

Będzie do tego potrzebna nam konfiguracja gitosis. Jako że jest ona przetrzymywana jako jedno z repozytoriów nie powinno być żadnych problemów z jej uzyskaniem. Tak więc jeżeli nie mamy już jakiejś kopi na dysku wywołujemy komendę:

git clone ssh://gitosis@server.z.gitem.org/gitosis-admin.git

Następnie edytujemy plik gitosis.conf w którym odajemy nowe repo:

[repo nazwa-nowego-repo]
owner = joe
description = opis

No i niby wygląda na to, że to wszystko … niestety nie jest tak łatwo, z tego co doświadczyłem to  gitosis wymaga, żeby każde repo posiadało osobną grupę o tej samej nazwie (możliwe, że można to jakoś przekonfigurować ale ja nie znalazłem takich informacji). Więc nie pozostaje nam nic innego jak dodać kolejną grupę:

[group nazwa-nowego-repo]
owner = joe
writable = nazwa-nowego-repo
members = joe

Zapisujemy zmiany i za pomocą git push wypychamy je na serwer … no to konfiguracje gitosis mamy za sobą. Teraz zostało nam jeszcze utworzyć repo ;>

Tak więc w lokalnym systemie tworzymy sobie nowy katalog albo wchodzimy do katalogu projektu który chcemy wrzucić do repo, w środku wywołujemy git init, następnie przy użyciu git add dodajemy wszystkie pliki do commit’a. Potem commit’ujemy zmiany do lokalnego repo (git commit -m “initial commit”) … no i teraz najważniejsze, dodajemy nasze zdalne repo:

git remote add dowolna-nazwa-repo ssh://gitosis@server.z.gitem.org/nazwa-nowego-repo.git

i tryumfalnie wypychamy wszystko na serwer

git push dowolna-nazwa-repo --all

To tyle, wszystko powinno działać … przynajmniej na razie u mnie działa ;>

Dziś lub jutro dodam wpis odnośnie aktualnego stanu wtyczki dodającej obsługę git’a dla Eclipse 😉 będzie to bardzo szybkie overview funkcjonalności których do tej pory użyłem/używałem.

UPDATE:
Wpis o git’cie i eclipse jest prawie gotowy, zostało mi jeszcze opisać branche’owanie, merge’owanie, push’owanie oraz pull’owanie i wstawić screenshot’y 😉

UPDATE2:
Dziś git też mnie pokonał 😐 … okazało się, że aktualnie plugin nie wspiera merge’owania branche’y, a push’owanie i fetch’owanie jest zbyt skomplikowane żeby opisywać je w jednym wpisie (zwłaszcza jeżeli nie ma się z tym zbyt wiele doświadczenia). Postaram się skończyć wpis jutro (zapamiętać: jutro nigdy nie umiera ;)) i go opublikować.

Ściągi dla developera

Dziś dzięki serwisowi develway.pl który dość nie dawno trafił do mojego  czytnika RSS, trafiłem na serwis <a href="http://devcheatsheet helpful site.com” target=”_blank”>devcheatsheet.com na którym to znajdują się  ściągawki (tzw. chetsheet’y) do wielu języków, framework’ów oraz narzędzi developerskich (nie które odnośniki są puste np. do GWT ale może za jakiś czas coś się tam pojawi).

Mnie w szczególności zainteresowały te pozycje:

Miłego ściągania ;>

Koniec Google Summer of Code 2009

GSoC09 t-shirtMimo, ze oficjalne ogłoszenie wyników GSoC09 odbyło się prawie dwa miesiące temu, dla mnie google’owe lato z kodowaniem zakończyło się dopiero parę dni temu kiedy to kurier dostarczył do mnie paczkę z koszulka i certyfikatem.

Co do samego projektu, to niestety nie udało mi się go skończyć w wyznaczonym terminie. Osobiście stopień zaawansowania oceniam na 75-80%. Mimo to Reinhard (mój mentor) uznał, że wykonałem na tyle dobrą pracę że ukończyłem pozytywnie GSoC.

Koniec Summer of Code nie oznacza dla mnie końca współpracy z developerami Cocoon’a, zwłaszcza, że nie wykonałem w pełni stawianych sobie celów. Dodatkowo na horyzoncie pojawiły się nowe interesujące pomysły na rozwój modułu monitorującego trzecią wersję Cocoon‘a.

Ostatnio pisząc o Summer of Code wspominałem o artykule traktującym o Spring JMX, miał on się ukazać w ciągu 2-3 tygodni … cóż nie udało się ale nie wydaje mi się by jego los był przesądzony ;). Wszystko jest ciągle kwestią czasu … jest to jedna z rzeczy którą chciałem zrealizować w czasie GSoC i ciągle pozostaje na mojej (dość, długiej(sic!) już) liście TODO.

EDIT:

Zapomniałem o jednej bardzo ważnej rzeczy … 90% napisanego przeze mnie kodu podczas GSoC znajduje się już w repozytorium ASF, a dokładniej mówiąc to jest tutaj. Natomiast całość kodu dostępna jest w archiwum znajdującym się pod koniec tej listy.