Come di solito fai i commit del codice?

Utilizzo un formato di commit standardizzato, spesso basato su Conventional Commits. Questo garantisce coerenza e automatizza alcuni processi, come la generazione del registro delle modifiche.

Formato tipico di commit:

<tipo>[(area)]: <descrizione>

[<corpo>]

[<nota>]

• <tipo>: Obbligatorio. Definisce il tipo di modifica (ad esempio, feat per nuove funzionalità, fix per correzioni, docs per modifiche alla documentazione, style per formattazione, refactor per refactoring, test per aggiunta di test, ci per modifiche a CI/CD).
• (area): Opzionale. Indica l'area dell'applicazione interessata dalla modifica (ad esempio, (componente: pulsante), (servizio: autenticazione)).
• <descrizione>: Obbligatorio. Breve e precisa descrizione delle modifiche in modo imperativo (ad esempio, "aggiungi pulsante", "correggi errore di validazione").
• <corpo>: Opzionale. Spiegazione più dettagliata delle modifiche, motivi e contesto. Separato da una riga vuota dalla descrizione.
• <nota>: Opzionale. Usato generalmente per indicare BREAKING CHANGE con descrizione del motivo per cui rompe la compatibilità, o link a task (ad esempio, Closes #123).

Esempi:

feat: aggiungi componente finestra modale

fix(validazione): correggi errore di validazione email nel modulo di registrazione

Ora l'email viene validata correttamente secondo lo standard RFC 5322.

Closes #45

refactor(componente: pulsante): aggiorna stili e migliora accessibilità

Refactoring degli stili del pulsante per conformarsi al sistema di design.
Migliorata l'accessibilità aggiungendo attributi ARIA.

Questo aiuta il team a comprendere meglio la storia delle modifiche, accelera la revisione del codice e semplifica i processi automatizzati.