[Septiusz]

Jaka jest różnica #gerrit vs #github pod kątem code review? Zakładając że mamy nielimitowane zasoby jeśli chodzi o sprzęt w organizacji.
#programowanie #kiciochpyta

[fegwegw]

@Septiusz: to są dwa zupełnie róźne narzędzia.

[Septiusz]

@fegwegw: zapomniałem dodać, że chodzi tylko o code review.

[fegwegw]

@Septiusz: no to fundamentalna jest taka, że Gerrita stawiasz 'u siebie', a GitHub jest zewnętrzną organizacją.

Gerrit jest w pytę.

[Septiusz]

@fegwegw: to akurat doszedłem, ale to nie może być jedyna różnica. Czy coś zyskujemy oprócz tego że wszystkie dane są in-house?

[Septiusz]

@fegwegw: "to akurat doszedłem" nie miało zabrzmieć lekceważąco jak by co. Szukam za i przeciw pomiędzy tymi dwoma narzędziami.

[fegwegw]

"to akurat doszedłem" nie miało zabrzmieć lekceważąco jak by co.

@Septiusz: Spoko, nie brzmiało :)

Ja szczerze mówiąc zawsze używałem rozwiązań 'in-house', i nigdy z tego powodu nie cierpiałem. Wszystko zależy od ogranizacji - jeśli jest na tyle duża, że nie poczuje narzutu wynikającego z trzymania wszystkiego 'u siebie', to raczej poszedłbym w tę stronę.

[Septiusz]

@fegwegw: a wiesz może jaka jest różnica w zarządzaniu uprawnieniami? W gerrit wiem, że jest kontrola nad tym kto co może zrobić. O githubie niewiele wiem.

[fegwegw]

@Septiusz: Szczerze, to o GH też niewiele wiem. Aczkolwiek takie podstawy jak ACL muszą tam być :)

[Nadrill]

@Septiusz: gerrit jest czytelniejszy imo, i ma tez inna troche zasade dzialania - oparty byl u mnie przynajmniej na rebase, a nie wystawianiu PR. jest tez znacznie szybszy.

[Septiusz]

@Nadrill: przy rebase nie gubimy trochę traceability? Nigdy z tym nie pracowałem, więc jestem tylko teoretykiem, a potrzebuję niestety się trochę nauczyć na ten temat.

Przy rebase git tworzy commity i master wygląda wtedy liniowo. Czy da się zobaczyć, że była jakaś gałąź, czy to wygląda jakby wszystkie commity były na masterze?

[Nadrill]

@Septiusz: faktycznie, na gerricie czesto praktykuje sie patchsety. przez to po 10 zmianach na CR dalej w hisotrii gita bedziemy mieli tylko 1 zmiane.

[Septiusz]

@Nadrill: a da się porównywać poszczególne przeglądy w Gerricie? Mamy np 3 amendy jednego commita i chcemy sprawdzić tylko co się zmieniło względem drugiego żeby nie sprawdzać całości. Da się tak?

[Nadrill]

@Septiusz: oczywiscie, mozna robic diffa pomiedzy np. 2 a 5 patchsetem.

[Septiusz]

@Nadrill: czyli w zasadzie gerrit (rebase) vs github (pull request) różni się tym, że w gerricie mamy bardziej przejrzystą historię commitów, ale po szczegóły z code review musimy już sięgnąć do gerrita, a w githubie całość się zamyka w narzędziach wbudowanych w samego Gita?

[Nadrill]

@Septiusz: poniekad tak

[black_janusz]

@Septiusz: nie do konca rozumiem co chcesz przez to powiedziec. W gerrit system review i "wpuszczania" zmian jest bardziej rozbudowany (-2, +2 itd) niz w githubie, do tego zawsze robisz commit amend i push force aby stworzyc nowy patch-set z poprawkami, jest to dobrze widoczne i łatwe do przegladania (w githubie mniej czytelne, ale tez commit amend + push force dziala)

[Septiusz]

@black_janusz: właśnie o to mi chodzi. Dzięki za podsumowanie. Do tego jeszcze czy dobrze rozumiem, to w githubie po commit amend tracisz historię, a w gerricie nie. Jest to prawda?

[black_janusz]

@Septiusz: kojarzy mi sie, że po wrzuceniu poprawki za pomoca amenda wczesniejsze komentarze dot. danego fragmentu kodu zostawaly ukryte, nie jestem pewien czy dalo sie jakos zobaczyc kod sprzed tego amenda. W gerrit jest to zdecydowanie czytelniejsze (mimo ze UI jest dosc archaiczne).

[Septiusz]

@black_janusz: jak zajrzałem w code review androida to zauważyłem na dole "New UI". Trochę bardziej przyjemne dla oka.

Dzięki za podpowiedź. W GitHub pewnie dałoby się komentarze odzyskać, ale nie tak prosto jak w gerricie. Co dopiero porównać z poprzednią wersją. Przychodzi Ci coś jeszcze na myśl, co mogłoby mieć znaczenie dla managementu przedsiębiorstwa? Kiedyś był wyciek z GitHuba. Ryzyko trzymania czegoś na zewnątrz jest dużym punktem moim zdaniem.

[black_janusz]

@Septiusz: o, wyglada faktycznie fajnie. Jak dla mnie sprawa jest dosc prosta - jest firma jest spora i stac ja na trzymanie tego u siebie (zespol devops, infra) to lepiej tak zrobic, natomiast jesli firma jest mala to lepiej chyba trzymac to zewnetrznie, jakby nie patrzec jest tam sztab ludzi ktory dba o security i uptime bo to ich zarobek.