Approvare / Ottenere approvazione: cos’è, approvazione e code review in Git

Cos’è l’approvazione di pull request

L’approvazione è una revisione positiva di un pull request, il che significa che il revisore ha controllato il codice, non ha trovato problemi critici e ritiene le modifiche pronte per il merge. Nell’interfaccia di GitHub, questo è il pulsante verde «Approve» sulla pagina del PR. Dopo l’approvazione, l’autore (o qualsiasi membro con permessi di scrittura) può eseguire il merge.

Il processo di approvazione fa parte delle Branch Protection Rules. I proprietari del repository configurano i requisiti obbligatori: numero minimo di approvazioni (ad esempio 1 o 2), chi può approvare (proprietari del codice, membri del team) e se il PR deve essere ri-approvato dopo le modifiche (Dismiss stale reviews). Senza configurazione delle regole, l’approvazione è facoltativa, ma nei team professionali è obbligatoria.

GitLab utilizza un meccanismo simile chiamato Approval Rules. In GitLab, è possibile configurare quante approvazioni sono richieste da diversi gruppi (ad esempio, 2 dagli sviluppatori backend e 1 da DevOps). Dopo aver ricevuto tutte le approvazioni obbligatorie, il PR viene automaticamente sbloccato per il merge purché la pipeline CI/CD sia verde.

Tipi di revisione: Approve, Request Changes, Comment

GitHub e GitLab hanno tre tipi di revisione che un revisore può lasciare su un pull request. Ogni tipo ha uno stato e conseguenze diversi per il processo di merge. Approve è verde, Request Changes è rosso, Comment è grigio neutro. La scelta dipende dalla qualità del codice e dalla prontezza delle modifiche per l’accettazione.

Approve — il revisore conferma: il codice è scritto correttamente, rispetta gli standard, non contiene errori evidenti e può essere unito. Approve non significa che il codice sia perfetto — solo che è abbastanza buono per la produzione. Se ci sono osservazioni minori (stile, denominazione), possono essere lasciate come commenti senza bloccare il PR.

Request Changes — il revisore trova problemi da correggere prima del merge: errori logici, vulnerabilità, violazioni dell’architettura, mancanza di test. Dopo Request Changes, il PR viene bloccato e per sbloccarlo è necessaria una nuova approvazione dello stesso revisore (se l’opzione Dismiss stale reviews è attivata per nuovi commit).

• Approve — codice pronto per il merge, può essere unito dopo il superamento del CI.
• Request Changes — correzioni obbligatorie, PR bloccato fino a nuova revisione.
• Comment — osservazione generale o suggerimento senza bloccare il PR.

Configurazione delle regole di approvazione nel repository

Le Branch Protection Rules sono il meccanismo di GitHub per controllare la qualità delle fusioni. Configurato in Settings → Branches per ogni ramo protetto (main, develop, release/*). Parametri principali: numero di approvazioni obbligatorie, proprietari del codice (CODEOWNERS), verifica CI/CD obbligatoria e divieto di push senza PR.

Il parametro Dismiss stale pull request approvals rimuove automaticamente le approvazioni se viene aggiunto un nuovo commit al PR. Ciò garantisce che i revisori approvino esattamente la versione del codice che verrà unita. Senza questa impostazione, l’autore potrebbe aggiungere nuovo codice dopo l’approvazione e questo arriverebbe in main senza nuove verifiche.

CODEOWNERS — un file nella root del repository che assegna i responsabili per diverse directory. Se un PR interessa file appartenenti a un proprietario del codice, la sua approvazione diventa obbligatoria. CODEOWNERS consente di distribuire le aree di responsabilità: gli sviluppatori iOS sono responsabili dei file Swift, DevOps delle configurazioni Docker, i tester degli scenari di test.

# File CODEOWNERS di esempio nella root del repository

# Gli sviluppatori iOS possiedono il codice Swift
*.swift @team/ios-developers

# DevOps possiede la configurazione CI/CD
.github/workflows/* @devops-team

# Gli ingegneri QA revisionano i test
**/tests/* @qa-engineers

# Proprietari predefiniti per tutto il resto
* @tech-leads

Code review prima dell’approvazione: cosa verificare

La code review prima dell’approvazione è un controllo sistematico del codice, non un’occhiata veloce al diff. Una code review di qualità include la verifica dell’architettura, della logica, dello stile, dei test e della sicurezza. Senza questo controllo, l’approvazione diventa una formalità anziché uno strumento di controllo qualità.

Cosa viene verificato per primo: la logica delle modifiche — il codice risolve il compito, ci sono effetti collaterali, la gestione dei casi limite è corretta. Test — i nuovi test coprono tutti gli scenari, i test esistenti passano dopo le modifiche. Sicurezza — ci sono SQL injection, XSS, fughe di dati sensibili.

Cosa non dovrebbe essere oggetto di revisione: lo stile di formattazione (a questo servono linter e formattatori), le decisioni architetturali prese in anticipo (vengono discusse prima di scrivere il codice). Se una revisione supera le 400 righe o richiede più di un’ora, è segno che il compito è troppo grande e richiede decomposizione. Migliori pratiche di revisione — porzioni di 200–400 righe entro 24 ore dalla creazione del PR.

• Logica — correttezza della soluzione, gestione degli errori, casi limite.
• Test — copertura di nuovi scenari, test esistenti superati, assenza di test flaky.
• Sicurezza — assenza di injection, escaping dell’output, controllo accesso dati.
• Prestazioni — efficienza degli algoritmi, query eccessive, perdite di memoria.
• Documentazione — se la documentazione è aggiornata, se i commenti nelle parti complesse sono chiari.

Workflow con approvazione in team

Un workflow tipico con approvazione in un team di 5–10 sviluppatori è il seguente: uno sviluppatore crea un PR, assegna i revisori (di solito 1–2 persone del team o proprietari del codice), CI/CD esegue controlli automatici. Dopo aver ricevuto tutte le approvazioni obbligatorie e un CI verde, l’autore esegue il merge. Il tempo dalla creazione del PR al merge varia da 2 ore a 2 giorni a seconda della complessità.

GitHub Actions consente l’automazione del merge dopo l’approvazione. Se le regole del ramo sono configurate, GitHub blocca automaticamente il merge fino a quando tutte le condizioni non sono soddisfatte. Alcuni team utilizzano bors-ng o Mergify — bot che uniscono automaticamente i PR dopo aver ricevuto tutte le approvazioni e il superamento del CI. Ciò accelera il processo ed elimina il fattore umano nei merge.

Un approccio moderno è il trunk-based development con rami di breve durata. In questo workflow, l’approvazione deve essere ottenuta entro poche ore, altrimenti il ​​compito viene considerato obsoleto e richiede la risincronizzazione con main. I team con una solida cultura della revisione mirano a un tempo di approvazione non superiore a 4 ore lavorative.

Errori nell’approvazione e come evitarli

L’errore più comune è l’approvazione formale senza un controllo effettivo del codice. Quando un PR è grande o la scadenza è vicina, il revisore può fare clic su Approve senza esaminare le modifiche. Ciò svaluta l’intero processo di code review. Soluzione: stabilire un limite alla dimensione del PR (non più di 400 righe) e utilizzare strumenti di analisi del codice (SonarQube, CodeClimate) per il controllo automatico.

Il secondo errore è un’approvazione eccessivamente rigorosa. Aspettarsi un codice perfetto blocca lo sviluppo. I revisori a volte richiedono di correggere osservazioni stilistiche che non influiscono sulla qualità. Soluzione: separare chiaramente le osservazioni obbligatorie (bloccanti) dai suggerimenti opzionali (commenti). GitHub consente di specificare esplicitamente se un commento è bloccante.

Il terzo errore è l’approvazione senza verificare CI/CD. Anche se il codice sembra corretto, potrebbe non compilare o fallire nei test. Le Branch Protection configurate bloccano automaticamente il merge su CI rosso, ma alcuni team disattivano questa protezione per velocità. Soluzione: verificare sempre lo stato del CI prima di approvare e non approvare mai un PR con pipeline rossa.

• Approvazione formale — assenza di controllo effettivo del codice. Soluzione: limite di 400 righe per PR.
• Rigore eccessivo — blocco per osservazioni stilistiche. Soluzione: dividere in bloccanti e opzionali.
• Ignorare CI — approvazione su pipeline rossa. Soluzione: verificare sempre lo stato dei test.
• Designazione dell’autore — approvazione dall’autore del PR. Soluzione: configurare Branch Protection contro l’autore.