Udostępnij za pomocą


Otrzymywanie opinii za pomocą pull requestów

Pull requesty obsługują przeglądanie i scalanie kodu w ramach jednego procesu współpracy. Po dodaniu przez dewelopera nowej funkcji lub poprawki błędu, tworzą pull request, aby rozpocząć proces scalania zmian z gałęzią główną. Inni członkowie zespołu mają szansę przejrzeć i zatwierdzić kod przed jego sfinalizowanie. Użyj żądań ściągnięcia, aby przejrzeć prace w toku i uzyskać wczesną opinię na temat zmian. Nie ma jednak zobowiązania do scalania zmian. Właściciel może w dowolnym momencie wycofać pull request.

Uzyskaj przegląd kodu

Przegląd kodu wykonany w ramach pull requestu nie służy jedynie do znajdowania oczywistych usterek; do tego są właśnie testy. Dobry przegląd kodu przechwytuje mniej oczywiste problemy, które mogą prowadzić do kosztowych problemów później.

Przeglądy kodu pomagają chronić zespół przed błędnymi scaleniami i uszkodzonymi kompilacjami, które obniżają produktywność zespołu. Przeglądy wykrywają problemy przed scaleniem, chroniąc ważne gałęzie przed niechcianymi zmianami.

Przeglądy kodu zachęcają również i wzmacniają współpracę i komunikację między deweloperami. A zespół zyskuje jasną historię wszystkich zmian wprowadzonych między gałęzią główną a gałęziami funkcjonalnymi.

** Wzajemne dzielenie się wiedzą i dzielenie się strategiami rozwiązywania problemów z udziałem wielu recenzentów podczas przeglądów kodu. Rozprzestrzenianie umiejętności i wiedzy sprawia, że zespół jest silniejszy i bardziej odporny.

Prześlij świetną opinię

Recenzje wysokiej jakości zaczynają się od wysokiej jakości opinii. Klucze do doskonałej opinii w żądaniu ściągnięcia to:

  • Zapewnij, aby właściwe osoby przejrzały pull request.
  • Upewnij się, że recenzenci wiedzą, co robi kod.
  • Przekaż konstruktywne informacje zwrotne z możliwością działania.
  • Odpowiedz na komentarze w odpowiednim czasie.

Podczas przypisywania recenzentów do pull requestu upewnij się, że wybierasz odpowiedni zestaw recenzentów. Recenzenci i deweloperzy pracujący w innych obszarach powinni wiedzieć, jak działa kod, aby mogli podzielić się swoimi pomysłami.

Podaj jasny opis zmian i podaj kompilację kodu, który zawiera poprawkę lub funkcję działającą w nim. Recenzenci powinni starać się przekazać opinię na temat zmian, z którymi nie zgadzają się. Zidentyfikuj problem i podaj konkretne sugestie dotyczące tego, co można zrobić inaczej. Ta opinia ma wyraźną intencję i jest łatwa do zrozumienia dla właściciela pull requestu.

Właściciel wniosku o wciągnięcie zmian powinien odpowiedzieć na komentarze, zaakceptować sugestie lub wyjaśnić, dlaczego rezygnują z ich zastosowania. Niektóre sugestie są dobre, ale mogą znajdować się poza zakresem pull requesta. Weź te sugestie i utwórz nowe elementy robocze oraz gałęzie funkcjonalne niezależnie od żądania pull requestu, aby wprowadzić te zmiany.

Ochrona gałęzi za pomocą zasad

Istnieje kilka krytycznych gałęzi w repozytorium, na których zespoły polegają, aby zawsze były w dobrym stanie, takie jak gałąź main. Zespoły mogą wymagać żądań zmian, aby wprowadzić wszelkie zmiany w tych gałęziach za pomocą platform takich jak GitHub i Azure DevOps. Deweloperzy wypychając zmiany bezpośrednio do chronionych gałęzi będą mieli odrzucone wypychania.

Dodaj dodatkowe warunki do pull requestów, aby wymusić wyższy poziom jakości kodu w kluczowych gałęziach. Czysta kompilacja scalonego kodu i zatwierdzenie przez wielu recenzentów należą do dodatkowych wymagań, które są często stosowane w celu ochrony kluczowych gałęzi.

Dowiedz się więcej

Usługa GitHub zawiera obszerną dokumentację dotyczącą wprowadzania zmian w pracy za pomocą żądań pull request.

Przeczytaj więcej o dawaniu świetnej informacji zwrotnej o przeglądach kodu i używaniu szablonów pull requestów do dawania wskazówek recenzentom. Usługa Azure DevOps oferuje również bogate środowisko pull requestów, które jest łatwe w użyciu i skaluje się w miarę potrzeby.