1.**feat:** un commit di _tipo_`feat` introduce una nuova funzionalità al codice (correlato al [`MINOR`](http://semver.org/#summary) in un versionamento semver).
1.**BREAKING CHANGE:** un commit che contiene il testo `BREAKING CHANGE:` all'inizio delle sezioni opzionali _corpo_ o _piè di pagina_, introduce una breaking API change (correlato al [`MAJOR`](http://semver.org/#summary) in un versionamento semver).
Una _breaking change_ può essere parte di un commit di qualsiasi _tipo_. Es: I tipi `fix:`, `feat:`&`chore:` sono tutti validi, cosí come qualsiasi altro _tipo_.
1. Extra: sono ammessi ulteriori _tipi_ oltre `fix:` e`feat:`, per esempio [commitlint-config-conventional](https://github.com/marionebl/commitlint/tree/master/%40commitlint/config-conventional) (che si basa sulla [convenzione Angular](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) raccomanda `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, ed altri.
Noi raccomandiamo anche `improvement` per commit che migliorano un'implementazione esistente senza aggiungere nuove funzionalità o risolvere un errore.
Notare che questi _tipi_ non sono mantenuti da questa specifica, e non hanno un effetto sul versionamento semver (a meno che non introducano una _BREAKING CHANGE_, il quale NON è raccomandato).
I test unitari vanno benissimo per le interazioni che i mantenitori open source conoscono, ma non fanno un ottimo lavoro nel catturare tutti i modi interessanti, spesso inaspettati, con i quali la comunità utilizza una libreria.
Solamente chi ha visto la propria applicazione restituire errori 500 dopo aver aggiornato una dipendenza ad una nuova versione patch, sa quanto sia importante una cronologia di commit facilmente leggibile (e nel migliore dei casi [un CHANGELOG ben mantenuto](http://keepachangelog.com/en/0.3.0/)) per il processo di investigazione che dovrà affrontare.
La specifica per commit convenzionali propone l'introduzione di una convenzione facilmente applicabile ai messaggi dei commit.
Questa convenzione legata al [SemVer](http://semver.org), chiede ai sviluppatori software di descrivere nei messaggi dei commit qualsiasi feature, fix e breaking change loro abbiano fatto.
Le parole “DEVE”, “NON DEVE”, “RICHIESTO”, “DOVRÀ”, “NON DOVRÀ”, “DOVREBBE”, “NON DOVREBBE”, “RACCOMANDATO”, “POTREBBE” e “OPZIONALE” devo essere interpretata come da specifica [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
1. Un _corpo_ del commit più lungo POTREBBE essere aggiunto dopo una breve _descrizione_, aggiungendo ulteriori informazioni contestuali riguardo le modifiche apportate al codice.
### Come dovrei comportarmi con i messaggi dei commit nella fase iniziale del progetto?
Raccomandiamo di procedere come se il tuo prodotto sia già stato rilasciato. Tipicamente *qualcuno*, anche i tuoi colleghi, stanno utilizzando il tuo software. Loro vorranno sapere cosa sia stato risolto, cosa si sia rotto etc.
### Cosa faccio se il tipo di commit è conforme a più di un tipo?
Torna indietro e dividi in più commit dove puoi. Parte del beneficio di usare Commit Convenzionali è quello di spingerti a fare commit e pull request organizzate meglio.
Commit Convenzionali ti incoraggia nel fare più di certi tipi di commit. Inoltre la flessibilità di Commit Convenzionali consente al tuo team di inventare i propri tipi e cambiarli nel tempo.
Se ancora devi creare il merge o il rilascio dell'errore, raccomandiamo l'utilizzo di `git rebase -i` per riscrivere la cronologia dei commit. Nel caso ti abbia già rilasciato questa correzione dipende dai tool e processi che usi.
Non è la fine del mondo se un commit non segue la specifica Commit Convenzionali. Semplicemente il commit verrà ignorato dai tool che sono basati su questa specifica.
No. Se usi un workflow basato sugli squash di Git, i mantenitori possono pulire i messaggi dei commit mentre vengono inseriti nel branch principale (merge), non aggiungendo alcun carico di lavoro ai committer occasionali. Un workflow comune è quello di unire (con lo squash) automaticamente i commit dalle pull request e far utilizzare un form ai mantenitori per riscrivere un messaggio più adeguato.
La specifica Commit Convenzionali è ispirata e fortemente basata su [Angular Commit Guidelines](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit).
La prima bozza di questa specifica è stata scritta in collaborazione con alcuni contributori di:
* [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog): un set di tool per analizzare messagi dei commit convenzionali dalla cronologia git.
* [unleash](https://github.com/netflix/unleash): un tool per automatizzare rilasci e cicli di pubblicazioni di un software.
* [lerna](https://github.com/lerna/lerna): un tool per la gestione di monorepos, nato del progetto Babel.
## Progetti che usano Commit Convenzionali
* [yargs](https://github.com/yargs/yargs): Parser di argomenti da CLI, a tema pirati.
* [istanbuljs](https://github.com/istanbuljs/istanbuljs): Una collezione di strumenti e librerie open source per aggiungere la coverage dei test JavaScript.
* [standard-version](https://github.com/conventional-changelog/standard-version): Automatizza il versionamento e la gestione del CHANGELOG utilizzando il nuovo pulsante squash di GitHub e il flusso di lavoro consigliato da Commit Convenzionali.
