Apruwować / Zatwierdzać: co to jest, approval i code review w Git

Co to jest apruwacja pull request

Apruwacja (approval) — to pozytywna recenzja pull request, oznaczająca, że recenzent sprawdził kod, nie znalazł krytycznych problemów i uważa zmiany za gotowe do scalenia. W interfejsie GitHub jest to zielony przycisk «Approve» na stronie PR. Po apruwacji autor (lub dowolny uczestnik z prawami do zapisu) może wykonać merge.

Proces apruwacji — część Branch Protection Rules. Właściciele repozytorium konfigurują obowiązkowe wymagania: minimalną liczbę apruwacji (np. 1 lub 2), kto może apruwować (właściciele kodu, członkowie zespołu) i czy PR musi być ponownie apruwowany po zmianach (Dismiss stale reviews). Bez konfiguracji zasad apruwacja jest opcjonalnym krokiem, ale w profesjonalnych zespołach jest obowiązkowa.

GitLab używa podobnego mechanizmu o nazwie Approval Rules. W GitLab można skonfigurować, ile apruwacji jest wymaganych od różnych grup (np. 2 od programistów backendu i 1 od DevOps). Po otrzymaniu wszystkich obowiązkowych apruwacji PR automatycznie odblokowuje się do merge pod warunkiem zielonego CI/CD pipeline.

Rodzaje przeglądu: Approve, Request Changes, Comment

W GitHub i GitLab istnieje trzy rodzaje przeglądu, które recenzent może zostawić na pull request. Każdy rodzaj ma inny status i konsekwencje dla procesu scalania. Approve — zielony, Request Changes — czerwony, Comment — neutralny szary. Wybór rodzaju zależy od jakości kodu i gotowości zmian do przyjęcia.

Approve — recenzent potwierdza: kod napisany poprawnie, zgodny ze standardami, nie zawiera oczywistych błędów i może być scalony. Approve nie oznacza, że kod jest idealny — tylko że jest wystarczająco dobry dla produkcji. Jeśli są drobne uwagi (styl, nazewnictwo), można je zostawić jako komentarze bez blokowania PR.

Request Changes — recenzent znajduje problemy, które należy naprawić przed merge: błędy logiczne, podatności, naruszenie architektury, brak testów. Po Request Changes PR jest blokowany, a do odblokowania wymagana jest ponowna apruwacja od tego samego recenzenta (jeśli włączona jest opcja Dismiss stale reviews przy nowych commitach).

• Approve — kod gotowy do scalenia, można merge po przejściu CI.
• Request Changes — obowiązkowe poprawki, PR zablokowany do ponownego przeglądu.
• Comment — ogólna uwaga lub sugestia bez blokowania PR.

Konfiguracja zasad apruwacji w repozytorium

Branch Protection Rules — to mechanizm GitHub do kontroli jakości scaliń. Konfigurowany w Settings → Branches dla każdej chronionej gałęzi (main, develop, release/*). Główne parametry: liczba obowiązkowych apruwacji, właściciele kodu (CODEOWNERS), obowiązkowa kontrola CI/CD i zakaz push bez PR.

Parametr Dismiss stale pull request approvals — automatycznie usuwa apruwacje, jeśli do PR dodano nowy commit. Gwarantuje to, że recenzenci apruwują dokładnie tę wersję kodu, która zostanie scalona. Bez tego ustawienia autor może dodać nowy kod po apruwacji i trafi on do main bez ponownej kontroli.

CODEOWNERS — plik w katalogu głównym repozytorium, który wyznacza odpowiedzialnych za różne katalogi. Jeśli PR dotyczy plików należących do właściciela kodu, jego apruwacja staje się obowiązkowa. CODEOWNERS pozwala rozdzielić strefy odpowiedzialności: programista iOS odpowiada za pliki Swift, DevOps — za konfiguracje Docker, testerzy — za scenariusze testowe.

# Przykładowy plik CODEOWNERS w katalogu głównym repozytorium

# Programiści iOS odpowiadają za kod Swift
*.swift @team/ios-developers

# DevOps odpowiada za konfigurację CI/CD
.github/workflows/* @devops-team

# Inżynierowie QA przeglądają testy
**/tests/* @qa-engineers

# Domyślni właściciele dla wszystkiego innego
* @tech-leads

Code review przed apruwacją: co sprawdzać

Code review przed apruwacją — to systematyczna kontrola kodu, a nie pobieżne przeglądanie diff. Jakościowy code review obejmuje sprawdzenie architektury, logiki, stylu, testów i bezpieczeństwa. Bez tej kontroli apruwacja staje się formalnością, a nie narzędziem kontroli jakości.

Co sprawdza się w pierwszej kolejności: logika zmian — czy kod rozwiązuje postawione zadanie, czy nie ma efektów ubocznych, czy poprawna jest obsługa przypadków brzegowych. Testy — czy nowe testy pokrywają wszystkie scenariusze, czy istniejące testy przechodzą po zmianach. Bezpieczeństwo — czy nie ma SQL-iniekcji, XSS, wycieków wrażliwych danych.

Co nie powinno być przedmiotem przeglądu: styl formatowania (do tego są lintery i formatter’y), decyzje architektoniczne podjęte z wyprzedzeniem (są omawiane przed pisaniem kodu). Jeśli w przeglądzie jest więcej niż 400 linii lub zajmuje więcej niż godzinę — to sygnał, że zadanie jest zbyt duże i wymaga dekompozycji. Najlepsze praktyki przeglądów — porcje po 200–400 linii w ciągu 24 godzin od utworzenia PR.

• Logika — poprawność rozwiązania zadania, obsługa błędów, przypadki brzegowe.
• Testy — pokrycie nowych scenariuszy, przejście istniejących, brak flaky-testów.
• Bezpieczeństwo — brak iniekcji, ekranowanie wyjścia, dostęp do danych.
• Wydajność — efektywność algorytmów, zbędne zapytania, wycieki pamięci.
• Dokumentacja — czy dokumentacja jest zaktualizowana, czy komentarze w złożonych fragmentach są zrozumiałe.

Workflow z apruwacją w zespole

Typowy workflow z apruwacją w zespole 5–10 programistów wygląda następująco: programista tworzy PR, wyznacza recenzentów (zwykle 1–2 osoby z zespołu lub właścicieli kodu), CI/CD uruchamia automatyczne kontrole. Po otrzymaniu wszystkich obowiązkowych apruwacji i zielonego CI autor wykonuje merge. Czas od utworzenia PR do merge wynosi średnio od 2 godzin do 2 dni w zależności od złożoności.

GitHub Actions pozwalają zautomatyzować merge po apruwacji. Jeśli skonfigurowano zasady gałęzi, GitHub sam blokuje merge do spełnienia wszystkich warunków. Niektóre zespoły używają bors-ng lub Mergify — botów, które automatycznie scalają PR po otrzymaniu wszystkich apruwacji i przejściu CI. Przyspiesza to proces i eliminuje czynnik ludzki przy merge.

Nowoczesne podejście — trunk-based development z krótkożywotnymi gałęziami. W tym workflow apruwacja powinna być uzyskana w ciągu kilku godzin, w przeciwnym razie zadanie uznaje się za nieaktualne i wymaga ponownej synchronizacji z main. Zespoły z wysoką kulturą przeglądu dążą do czasu apruwacji nie więcej niż 4 godzin roboczych.

Błędy przy apruwacji i jak ich unikać

Najczęstszy błąd — formalna apruwacja bez rzeczywistej kontroli kodu. Gdy PR jest duży lub deadline bliski, recenzent może nacisnąć Approve bez wgłębiania się w zmiany. To dewaluuje cały proces code review. Rozwiązanie: ustawić limit wielkości PR (nie więcej niż 400 linii) i używać narzędzi analizy kodu (SonarQube, CodeClimate) do automatycznej kontroli.

Drugi błąd — nadmiernie surowa apruwacja. Oczekiwanie idealnego kodu blokuje rozwój. Recenzenci czasami wymagają poprawienia uwag stylistycznych, które nie wpływają na jakość. Rozwiązanie: wyraźnie rozdzielać obowiązkowe uwagi (blokujące) i opcjonalne sugestie (komentarze). GitHub pozwala wyraźnie wskazać, czy komentarz jest blokujący.

Trzeci błąd — apruwacja bez sprawdzenia CI/CD. Nawet jeśli kod wygląda poprawnie, może się nie kompilować lub padać na testach. Skonfigurowane Branch Protection automatycznie blokują merge przy czerwonym CI, ale niektóre zespoły wyłączają tę ochronę dla przyspieszenia. Rozwiązanie: zawsze sprawdzać status CI przed apruwacją i nigdy nie zatwierdzać PR z czerwonym pipeline’em.

• Formalna apruwacja — brak rzeczywistej kontroli kodu. Rozwiązanie: limit 400 linii na PR.
• Nadmierna surowość — blokowanie z powodu uwag stylistycznych. Rozwiązanie: podział na blocking i optional.
• Ignorowanie CI — apruwacja przy czerwonym pipeline’ie. Rozwiązanie: zawsze sprawdzać status kontroli.
• Wyznaczenie autora — apruwacja od autora PR. Rozwiązanie: konfiguracja Branch Protection przeciw autorowi.