Git workflow professionale: branching strategy e PR best practice

Dopo 5 anni in team, ho consolidato un workflow Git che funziona davvero. Branching strategy (GitFlow semplificato): - main: solo codice pronto per produzione - develop: integrazione continua - feature/nome: ogni nuova funzione - fix/descrizione: hotfix - release/v1.x.x: preparazione release Regole fondamentali: 1. Mai commit diretto su main o develop 2. Ogni feature = branch separato 3. PR obbligatoria con almeno 1 reviewer 4. CI deve passare prima del merge Voi che workflow usate?

Conventional commits rendono la history leggibile e automatizzano il changelog: ``` feat: aggiungi autenticazione OAuth2 fix: correggi timeout connessione DB docs: aggiorna README Docker refactor: estrai logica validazione in servizio test: aggiungi unit test UserService chore: aggiorna dipendenze patch ``` Con semantic-release il versionamento diventa automatico.

Git hooks per prevenire commit di segreti: ```bash # .git/hooks/pre-commit #!/bin/bash if git diff --cached | grep -E '(password|secret|api_key|token)\s*=' ; then echo 'ERRORE: possibile secret nel commit!' exit 1 fi ``` Oppure gitleaks in CI: ```yaml # GitHub Actions - uses: gitleaks/gitleaks-action@v2 ```

Per progetti personali o team piccoli, Trunk-Based Development e spesso migliore di GitFlow: - Branch unico (main) - Feature flag per codice non pronto - Deploy frequenti (piu volte al giorno) - Integrazione continua vera GitFlow va bene per software con release cicliche. Per web app con deploy continuo, trunk-based e piu efficiente.