przegląd kodu za pomocą git-flow i github

Za pomocą zwykłych git i github mogę dokonać przeglądu kodu, po prostu tworząc żądanie ściągnięcia gałęzi funkcji, nad którą pracuję, do gałęzi master. Jak mam napisać recenzję kodu za pomocą git-flow? Jeśli chodzi o przepływ pracy, taki jak „zakończenie funkcji git flow”, jestem zdezorientowany co do tego, gdzie faktycznie ma miejsce przegląd kodu i jak git-flow lub git może ułatwić tę recenzję.

Niedawno natknęliśmy się na ten dokładnie problem. Naprawdę lubimy git flow, ponieważ używa dobrego poziomu semantycznego (używając tego samego poziomu, którego używasz w dyskusji zespołowej: „Zacznę cechę A” bardziej niż „Stworzę gałąź, kasę”), podczas gdy git to poziom „implementacyjny” (co jest dobre i użyteczne, ale inne).

Problem, z jakim mamy do czynienia git feature finish, gdy scala gałąź w fazie rozwoju, podczas gdy chcemy, aby prośba o ściągnięcie została wysłana i (jest to ważne) scalona przez recenzenta , a nie komisarza, aby podkreślić własność zespołu.

Nasze obecne rozwiązanie:

1. Ktoś używa git flow do utworzenia gałęzi funkcji
2. Po zakończeniu tworzy żądanie ściągnięcia (używając github)
3. Przegląd ma miejsce, z potencjalnymi dodatkowymi zobowiązaniami
4. Żądanie ściągnięcia jest scalane za pomocą GitHub przez recenzenta .
5. Nie ma zakończenia funkcji Git Flow (ponieważ gałąź jest już scalona)

Jest to zgodne z naszą praktyką, ponieważ wadą jest konieczność samodzielnego usuwania gałęzi (ponieważ nie kończymy przepływu). Naszym kolejnym krokiem będzie prawdopodobnie ponowne zaimplementowanie niektórych części przepływu git (ponieważ dotyczy to głównie łączenia łańcuchów poleceń git), aby wziąć to pod uwagę (mając część „czyszczenia” zakończenia bez scalania).

Proces, w którym pracuje z tym zespół, jest następujący:

1. Utwórz gałąź funkcji: git flow feature start module_1
2. Kod jest aktualizowany w gałęzi funkcji
3. Po zatwierdzeniu zmian są one przekazywane do GitHub (lub raz na końcu, jeśli jest to preferowane)
4. Po zakończeniu funkcji zostanie otwarte żądanie ściągania w GitHub porównywanie developi gałąź funkcjimodule_1
5. Zespół sprawdza żądanie ściągnięcia i komentuje
6. Wszelkie zmiany z żądania ściągnięcia są wprowadzane do gałęzi funkcji
7. Po wprowadzeniu wszystkich zmian w gałęzi funkcji gałąź funkcji jest zakończona: git flow feature finish module_1
8. developOddział jest popychany do GitHub (GitHub automatycznie oznaczyć żądanie rozwijane jako zamknięty / połączyły kiedy to nastąpi)

Zwykle cały ten proces jest wykonywany przez oryginalnego autora, ale nie jest to wymagane. Każdy członek naszego zespołu może w dowolnym momencie wziąć udział w tym procesie. Wszystko, co muszą zrobić, to przejrzeć gałąź funkcji i kontynuować proces. git flow feature finish module_1Każdy, kto kiedykolwiek uruchomi, będzie mógł usunąć luksus swojej lokalnej gałęzi funkcji, ale każdy, kto sprawdził gałąź, musi to zrobić ręcznie, jeśli chce użyć czegoś takiego git branch -D feature/module_1.

W przypadku poprawek używamy podobnego podejścia i tworzymy żądanie ściągnięcia w GitHub przed zakończeniem poprawki.

Jeśli robisz recenzje kodu, zakładam, że masz centralne repozytorium zawierające „oficjalny” kod. Programiści pobierają i przesyłają dane do tego centralnego repozytorium.

Gdy korzystasz z Gerrit , sam Gerrit staje się centralnym repozytorium (ma wbudowane serwery SSH i HTTP, które pozwalają użytkownikom na interakcję z nim w zasadniczo taki sam sposób, w jaki już są). Podczas korzystania z Gerrit przepływ pracy staje się:

1. Deweloper wprowadza zmiany w dowolnej gałęzi, zatwierdza lokalnie.
2. Deweloper przekazuje te zmiany Gerrit.
3. Gerrit tworzy elementy recenzji do oceny przez innych.
4. Rówieśnicy sprawdzają kod, komentują i akceptują lub odrzucają zatwierdzenie.
5. Gdy popełnić zostanie zaakceptowane, wówczas Gerrit sprawia, że zmiany te dostępne dla innych, aby wyciągnąć z branży.

Podczas korzystania z centralnego repozytorium inni programiści mogą zobaczyć przesłane zmiany po kroku 2. Gerrit wprowadza przepływ pracy przeglądania kodu, więc inni programiści widzą przesłane zmiany dopiero po kroku 5.

Działa to dobrze z git-flow (lub dowolnym innym schematem rozgałęziania), ponieważ Gerrit obsługuje sprawdzanie zmian dokonanych w dowolnej gałęzi.

Oto kolejna sugestia.

1. Wykonuj regularny proces git flow, aby utworzyć funkcję , ale nie kończ jej ani nie scalaj.
2. Utwórz żądanie ściągnięcia , ale nie łącz go. Poczekaj, aż osoba zatwierdzająca skomentuje. Komentarz jest znakiem aprobaty.
3. Wykonaj Git Flow . (Zarówno zatwierdzający, jak i programista mogą to zrobić, w zależności od uzgodnień zespołu.) Żądanie ściągnięcia zostanie oznaczone jako scalone na github. Nadal musisz usunąć gałąź na początku.