SC-3: Processo Pull Request

Descrizione

Il processo di pull request (o merge request) garantisce che tutte le modifiche al codice siano revisionate e validate prima di essere integrate nel branch principale. Tutte le modifiche DEVONO (MUST) passare attraverso questo processo.

Guida

Requisiti per le pull request

Tutte le modifiche DEVONO (MUST) essere merged tramite pull request (GitHub) o merge request (GitLab). Le pull request DEVONO (MUST):

Essere sottoposte a peer review: Almeno un altro sviluppatore deve revisionare e approvare la pull request
Superare tutti i check richiesti: Test automatizzati, linting, security scanning e altre validazioni devono passare prima del merge

Descrizione della pull request

Le pull request DOVREBBERO (SHOULD) includere:

Titolo chiaro: Descrizione concisa della modifica
Descrizione dettagliata: Spiegazione del perché della modifica, non solo del cosa
Link al work item: Riferimento al ticket Jira o GitHub Issue correlato
Test plan: Come è stata testata la modifica
Screenshot/demo: Se applicabile, per modifiche UI
Breaking changes: Evidenziare eventuali modifiche che rompono la compatibilità

Impostazioni raccomandate

I team DOVREBBERO (SHOULD) abilitare:

Eliminazione automatica dei branch merged: Per mantenere pulito il repository
Template per pull request: Per standardizzare le informazioni richieste

I team PUÒ (MAY) abilitare:

Auto-merge: Per merge automatico dopo approvazione e check superati
Rebase merging: Per mantenere una storia lineare
Squash merging: Per condensare i commit di una feature

Misurazione

Stato	Criteri
🟢 VERDE	Tutte le modifiche via PR con review e check, template utilizzato, processo documentato
🟡 AMBRA	Alcune bypass o review mancanti, check non sempre richiesti
🔴 ROSSO	Commit diretti al main, nessun processo di review