Przegląd kodu Gerrit, czy model widelca i ciągnięcia Githuba?

Zaczynam projekt oprogramowania, który zostanie opracowany przez zespół AND społeczność. Wcześniej sprzedawano mnie na Gerrit, ale teraz model widelca i żądania ściągania Githuba wydaje się zapewniać prawie więcej narzędzi, sposobów wizualizacji zatwierdzeń i łatwości użycia.

Dla kogoś, kto ma przynajmniej trochę doświadczenia z oboma, jakie są zalety / wady każdego z nich, i które byłyby lepsze dla projektu zespołowego, który chce pozostawić otwartą możliwość rozwoju społeczności?

— użytkownik1366476
źródło

Główną różnicą między przepływami pracy Gerrit i GitHub jest sposób modelowania zmian.

W Gerrit każde zatwierdzenie jest zmianą, która jest niezależna. Chociaż Gerrit pokaże relacje między zatwierdzeniami, recenzje są przeprowadzane na podstawie zatwierdzenia. Zespoły, które są dobre w dzieleniu dużych zmian na małe, niezależne zatwierdzenia, mogą odnieść większy sukces z Gerrit. Ponieważ jednak model Gerrit obejmuje kolejne zmiany konkretnego zatwierdzenia, zachęca do przepływów pracy w Git, do których wielu programistów nie jest przyzwyczajonych, takich jak zmiana wcześniejszego zatwierdzenia i ponowne przesłanie go lub zmiażdżenie rosnącego zestawu zatwierdzeń z gałęzi tematów w jednym popełnić.

W Github żądanie ściągnięcia modeluje związek między dwiema gałęziami. Oczekiwanym przepływem pracy w Github jest zatwierdzenie jednej lub więcej zmian w gałęzi tematu (często w rozwidleniu repozytorium, ale niekoniecznie) i utworzenie żądania ściągnięcia między tą gałęzią a gałęzią „w górę”. W tym przypadku przedmiotem przeglądu jest zestaw zatwierdzeń, który stale rośnie wraz z kontynuowaniem przeglądu. Rezultatem jest zestaw zmian, które można następnie połączyć atomowo po ich zakończeniu. Żądania ściągania mogą być skuteczne w śledzeniu zmian o większym zakresie, które mogą być realizowane w wielu zatwierdzeniach. Żądania ściągania obsługują również przepływy pracy SCM, do których przyzwyczajonych jest więcej programistów, takie jak odpowiadanie na komentarz do recenzji poprzez przesłanie potwierdzenia uzupełniającego w tym samym oddziale.

Dużą zaletą na korzyść Github jest liczba programistów, którzy znają go w porównaniu z Gerrit. Gerrit może być popularny wśród zaawansowanych użytkowników Git, ale korzystanie z niego bez tarcia wymaga pośredniej lub zaawansowanej wiedzy na temat gita oraz tolerancji stromej krzywej uczenia się.

Zaletą Gerrit jest głębszy związek z Git. Żądania ściągania Github są wystarczająco daleko usunięte od standardowego modelu danych Git, że do tworzenia żądań ściągania należy użyć internetowego interfejsu użytkownika Github lub jego zastrzeżonego API. Interfejsem Gerrit do tworzenia i aktualizacji zmian jest sam protokół git.

— Martin Atkins
źródło

Dzięki Martin, to ciekawa odpowiedź. Chciałem spojrzeć na Gerrita przez jakiś czas, ale myślę, że to odłożę. Jeśli zachęca to do edytowania historii i zgniatania zobowiązań, nie chcę mieć z tym nic wspólnego. * 8 '(

— Mark Booth

Żeby było jasne (często używam Gerrit w moim miejscu pracy), Martin mówi tutaj: „Gerrit ... zachęca do przepływu pracy w Git ... na przykład zmieniając wcześniejsze zatwierdzenie i ponownie je wypychając lub zgniatając rosnący zestaw zatwierdzeń. .. do pojedynczego zatwierdzenia ”jest dokładnie poprawne. Wyjaśniam, że komentarz @ MarkBooth na temat „edycji historii” nie jest tym, co powiedział Martin. Zmiana zatwierdzeń (wciąż na Gerrit i jeszcze nie scalona z origin / master) nie obejmuje „edycji historii”. W rzeczywistości ten przepływ pracy działa świetnie. „Zła” edycja historii, do której odwołuje się Mark Booth, polega na ponownym przesunięciu edytowanych historii do źródła / wzorca.

— likethesky

Dziękuję za wyjaśnienie @likethesky, ale mam raczej dosłowną interpretację „historii edycji”, a jeśli o mnie chodzi, wszystko, co skutkuje zestawami zmian zawierającymi treści, które nie zostały wyraźnie zatwierdzone, to „historia edycji”. Zdaję sobie jednak sprawę, że jest to raczej drakońska interpretacja, do której niewielu innych się stosuje. * 8 ')

— Mark Booth,

Słusznie. :-) Nie jestem pewien, czy rozumiem, co rozumiesz przez „zestawy zmian, które zawierają treści, których wyraźnie nie zatwierdziłeś”, więc proszę. opracować ... Zakładam, że jesteś nie mówiąc, że nigdy nie popełnić tymczasowy (lokalny lub dzielone pomiędzy członków zespołu za pośrednictwem zdalnych oddziałów) popełnia jak „WIP: ten próbuje rozwiązać problem arch omówiliśmy”, po której następuje bardziej pomocny squash / poprawka, która mówi: „Problem 123: Przeprojektowano XYZ w celu zwiększenia odporności i łatwości skalowania poziomego” jako ostateczny komunikat zatwierdzenia dla tej pracy. Ale w każdym razie, oczywiście, możesz użyć git w dowolny sposób, który cię uszczęśliwi!

— likethesky

To fantastyczna odpowiedź. Aby dodać, zauważyłem, że żądania ściągania GitHub sprzyjają mniejszym, bardziej iteracyjnym zatwierdzeniom i często kończą się znacznie bardziej opisowym dziennikiem git, który pokazuje nie tylko produkt pracy, ale proces pracy. Recenzja kodu Gerrit sprzyja o wiele bardziej przejrzystej historii repozytoriów (jest bardzo, bardzo niewiele rzeczywistych zatwierdzeń scalania) z większymi, bardziej dopracowanymi zatwierdzeniami.

— tophyr