Przepływ pracy dla recenzji kodu opartej na GitHub

Question

Rozważam użycie narzędzia GitHub jako podstawowego narzędzia do przeglądania kodu. Dzięki funkcjom, takim jak komentowanie w trybie in-line i porównywanie, ma wiele funkcji dostępnych w takich narzędziach, jak Gerrit.

Czy ktoś inny użył GitHub do tego? Jeśli tak, jaki jest twój przepływ pracy? I jakie są twoje doświadczenia, zarówno pozytywne, jak i negatywne?

Gdy mam kilka przemyśleń na ten temat i ustalę, co będzie dla nas najlepsze, zmienię moje pytanie, aby udostępnić mój własny proponowany przepływ pracy.

EDITED z proponowanymi workflow

Krok 0. Set up a post-receive hook pomocą niesamowite reviewth.is.

Następnie:

1. Commit jak zwykle z commit -a -s, ale w komunikacie popełnienia dołączyć #reviewthis @username.

2. Jeśli kompilacja się nie powiedzie, przegląd zostanie pominięty, dopóki kompilacja nie zostanie przywrócona.

3. Komentarze recenzenta na temat commit line-by-line lub na poziomie pliku.

4. GitHub automagicznie powiadamia recenzenta o komentarzach.

5. Recenzent powiadamia recenzenta pocztą elektroniczną, gdy komentarze zostaną uzupełnione o podsumowanie opinii.

6. Recenzent odpowiada na komentarze recenzentów w GitHub, umożliwiając projektowi dostęp do historii recenzji kodu.

Moje największe problemy dotyczą kroku 2 i kroków 4/5. Gerrit działa przyjemnie, nie pytając o recenzje, chyba że kompilacja się powiedzie; Chciałbym zrobić to w GitHub. Kroki 4/5 mogą również powodować irytujące (wielokrotne wiadomości e-mail) i ograniczać automatyczny charakter procesu sprawdzania (wymagającego streszczenia w wiadomości e-mail).

Używamy Hudsona jako naszego serwera kompilacji, jeśli to pomaga.

Wszelkie uwagi dotyczące tych problemów również byłyby pomocne.

Answer 1

Użyłem go do tego. Przepływ pracy, którego używam, polega na wykonaniu pracy w gałęzi tematu i wysłaniu żądania pobrania w tej gałęzi. Recenzenci sprawdzają kod i zatwierdzenia, używając komentarzy w linii (i przez-commit). Koder przyjmuje tę informację zwrotną i wykonuje destrukcyjny rebase w tej gałęzi tematu, ponownie ją przesyła (przepisując historię na repozytorium github), a następnie cykl recenzji powtarza się, aż do akceptacji połączenia.

Edytuj: Githubber opublikował na swoim blogu opis metody, której używają do rozwoju github, i jest bardzo podobny do tego, co zaproponowałem. link

Aktualizacja: Teraz używam tego przepływu pracy zarówno w moich projektach open source, jak iw mojej pracy zawodowej wciąż świetnie się rozwija.

Answer 2

W mojej pracy podążamy za procesem opisanym pod numerem "Using pull requests" w celu sprawdzenia kodu i jesteśmy z niego bardzo zadowoleni.