Ogólnie to nie przepadam za githubem, szczególnie za sposobem robienia review kodu. Prowadziłem wiele szkoleń z Gita w firmie i często opowiadam o różnicach w podejściu jednego sposobu, a drugiego. Nie są duże ale wpływają znacząco na jakość kodu, szczególnie u juniorów. Do tego tematu wrócę za chwilę, bo najpierw coś co mnie skłoniło do napisania tej treści.
Od września jestem w 2 projektach równocześnie. Nowy projekt jest tylko na 0.25 etatu, czyli 2 godziny dziennie. Firma tworzy fajne urządzienia oparte na Androidzie, muszę przyznać, że mam teraz jedno i wygląda super - taki projektor niedużo większy od telefonu, ale grubości ok. 15cm. Nazwę firmy podam kiedyś później.
No i potrzebują pomocy w połataniu pewnych rzeczy, ale to już NDA mi nie pozwala abym opowiadał. Istotniejsze jest to, że za kod odpowiadała firma X. Dostaliśmy od nich kod Androida w formie paczki spakowanej tarem. No i oczywiście trzeba to wrzucić na jakieś repozytorium. Klient wykupił sobie premium na github i zaczęło się dzielenie spakowanych 60GB źródeł na mniejsze paczki. Podzieliłem to tak samo jak jest podzielony AOSP. Zmodyfikowałem kod git-repo aby manifest był kompatybilny z github i jazda.
Pewny siebie zacząłem wypychanie źródeł. Jakie było moje zdziwienie gdy zaczęły wyskakiwać błędy, że pliki mają ponad 100Mb. Cały misterny plan mirrora androida 1:1 + zmiany zrobione przez firmę X poszedł się... Oczywiście rozwiązaniem jest LFS, ale ma to wady i zalety. Po pierwsze sam mechanizm LFS jest spoko pozwala wrzucić na jakiś inny serwer duże pliki, ale w Androidzie nikt tak nie robi. Robisz płytkie klonowanie --depth=1 i masz tyle samo danych ściągniętych co w przypadku LFS.
Po drugie chceałem wrzucić historię AOSP, a takie przerabianie na LFS oznacza przeoranie całej historii, bo jeśli nagle zamiast pliku przechować chcemy referencję do zewnętrznego serwera no to wiadomym jest, że sha komita się zmieni. Po trzecie LFS na github kosztuje. Nie ma ograniczeń w płatnym programie na github co do liczby i wielkości repozytorów, ale jest ograniczenie LFS do 2GB, powyżej tego trzeba kupić wyższy program. Dodatkowo pobierając zurzywa się transfer, który też jest limitowany.
Teraz już pewnie się domyślacie dlaczego jest limit wielkości plików. Tylko po to aby wymusić użycie LFS, które kosztuje i ma limity, a każdy kolejny program jest droższy.
No i teraz do początku. Zawsze gdy pracowałem z platformą androidową to używaliśmy własnych serwerów z postawionym gerritem i jenkinsem. To rozwiązanie może jest nawet droższe niż github, ale o ile wygodniejsze i przyjemniejsze. Czym się różni review? Na github odbywa się per branch, albo per feature, który jest na gałęzi. Patrzymy i oglądamy całość zmian. Gerrit ma inne podejście i przymonima bardziej listę mailingową kernela gdzie każda zmiana (commit) przechodzi szczegółowe review. Sprawdzany jest nie tylko kod, ale treść np. "commit msg". Jeśli dana funkcjonalność jest bardziej skomplikowana i jest podzielona na kilka zmian to lepiej widać co programista miał na myśli. W pierwszej zmianie dodaje jakieś interfejsy, potem jakiś kod i testy. Wszystko układa się krok po kroku w to co programista miał na myśli. Na github często do review trafia zmiana na kilka tysięcy linii, a na gerrita podczas jednego review sprawdzamy zazwyczaj mniej niż setki linijek. Amen
Ciekawe. W pracy używamy Gitlaba i chyba podobnie jak na Github? Chociaż można per commit sprawdzać, ale nie wiem czy ktoś tak robi.
A sam myślałem o postawieniu Gitea albo używaniu online Sourcehut xD
Github i gitlab wygląda podobnie co do zasady. Na github też możesz przeglądać konkretne zmiany i je komentować. Jednak na gerricie łatwiej jest śledzić czy np. po Twoim komentarzu, ktoś dokonał zmian. Mimo, że wizualnie gerrit to średniowiecze to mechanicznie jest super. Jest nawet projekt gerrithub czy coś takiego, gdzie łączysz swój projekt na github z gerritem. Po tym zabiegu używasz review z gerrita, a kod po zatwierdzeniu trafia na githuba. Kiedyś testowałem na studentach i działało spoko, ale to było 5 lat temu