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.

8 Comments Git, EGit i Gerrit …

  1. Leszek

    “(nie potrzebnie ujmuję w klamry jedno-instrukcjowe linie w if’ach i else’ach)”

    Eeeee. Że co? Niepotrzebnie?

    Przecież to jest czytelne… co my w średniowieczu żyjemy, że trzeba oszczędzać na linijkach bo się program skompiluje o 0,000000001ns szybciej? Ja rozumiem emisję CO2 ale to inna bajka 😉

    Śmiało używaj angielskich słów. Niestety (lub stety) używanie koniecznie polskich może dopiero śmiesznie wyglądać. Ci co zrozumieją Twój post, rozumieją te wyrazy.

    Reply
  2. [LocK]

    Eeeee. Że co? Niepotrzebnie?

    Przecież to jest czytelne… co my w średniowieczu żyjemy, że trzeba oszczędzać na linijkach bo się program skompiluje o 0,000000001ns szybciej? Ja rozumiem emisję CO2 ale to inna bajka ;-)

    Cóż, takie mają konwencje i jako osoba z zewnatrz projektu powinienem się ich trzymać.

    Śmiało używaj angielskich słów. Niestety (lub stety) używanie koniecznie polskich może dopiero śmiesznie wyglądać. Ci co zrozumieją Twój post, rozumieją te wyrazy.

    Wiem, że zostane zrozumiany, ale mi chodzi bardziej o to, że czasem łapię się że nie znam polskiego odpowiednika dla jakiegoś słowa angielskiego … mimo to, że powinienem go znać :|. W pracy inżynierskiej też nie powinienem używać anglikanizmów …

    Reply
  3. zenek

    Zaczniesz się bać, gdy nie będziesz potrafił sobie przypomnieć zwykłych słów. Ja od wieków mam problem z “flexible” i polskim “elastyczny” 🙂

    Reply
  4. Filus

    Słusznie, należy się gimnastykować i wzbogacać swój słownik. Bierz spokojnie przykład ze starszego (niestety 😉 ) kolegi, najwyżej też będziesz stale nierozumiany ;). Azaliż to takie straszne jakieś? 😉 Co do “commit”, ja sobie z reguły zastępuję “oddawaniem” lub kolokwialnym “wypychaniem” (no chyba, że znajdzie się lepsza propozycja 😉 ), a z haczykiem jeszcze problemu nie było, bo nie używam gita 😉

    Reply
  5. Mateusz

    Dopiero się uczę Gerrita, ale wydaje mi się, że innym sposobem na rozwiązanie Twojego problemu jest pobranie change-id przypisanego do naszego review przez interfejs webowy gerrita i doklejenie go na końcu komentarza “amendowanego” commita . Gerrit powinien wówczas utworzyć nowy patch-set w ramach tej samej zmiany.

    Reply
  6. Dariusz Łuksza

    @Mateusz
    Dokładnie, teraz też to wiem 😉 Wcześniej z jakiś powodów nie było to możliwe lub też nie wydawało się mi takie proste. Nie mniej sposoby “na około” pozwalają się nauczyć więcej niż w przypadku kiedy rozwiązujemy problem w najprostszy możliwy sposób 😉

    Reply

Leave a Reply to [LocK] Cancel reply

Your email address will not be published. Required fields are marked *