Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
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.