conventionalcommits.org/content/v1.0.0/index.it.md

draft	aliases
false	/it/

Commit Convenzionali 1.0.0

Riepilogo

La specifica Conventional Commits è una convenzione semplice da implementare per i messaggi dei commit. Fornisce un insieme di semplici regole per la creazione di una cronologia di commit esplicita; il che rende più facile utilizzare strumenti per automare processi. Questa convenzione si completa con SemVer, descrivendo le funzionalità, la risoluzione di errori e l'introduzione di breaking changes fatte dei commit.

I messaggi dei commit dovrebbero seguire la seguente struttura:

---

<tipo>[contesto opzionale]: <descrizione>

[corpo opzionale]

[piè di pagina opzionali]

---

Il commit contiene i seguenti elementi strutturali, allo scopo di comunicare l'intento al consumatore della libreria:

1. fix: un commit di tipo fix risolve un errore nel codice (correlato al PATCH in un versionamento Semver).
2. feat: un commit di tipo feat introduce una nuova funzionalità al codice (correlato al MINOR in un versionamento Semver).
3. BREAKING CHANGE: un commit che contiene in un piè di pagina BREAKING CHANGE:, o aggiunge un ! subito dopo il tipo/contesto, all'inizio delle sezioni opzionali corpo o piè di pagina, introduce una breaking API change (correlato al MAJOR in un versionamento Semver). Una BREAKING CHANGE può essere parte di un commit di qualsiasi tipo.
4. Sono ammessi ulteriori tipi oltre fix: efeat:, per esempio commitlint-config-conventional (che si basa sulla convenzione Angular) raccomanda build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, ed altri.
5. Altri piè di pagina oltre BREAKING CHANGE: <description> possono essere utilizzati e seguono ua specifica simile a git trailer format.

Altri tipi non sono mantenuti da questa specifica, e non hanno un effetto sul versionamento semver (a meno che non introducano una BREAKING CHANGE).
Un contesto potrebbe essere aggiunto al tipo di commit, al fine di offrire ulteriori informazioni contestuali. Da aggiungere tra delle parentesi tonde, Es: feat(parser): add ability to parse arrays.

Esempi

Messaggio di un commit con una descrizione e una breaking change nel piè di pagina

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

Messaggio di un commit con un ! per attirare l'attenzione su una breaking change

refactor!: drop support for Node 6

Messaggio di un commit con uno contesto e ! per attirare attenzione ad una breaking change

refactor(runtime)!: drop support for Node 6

Messaggio di un commit con entrambe ! e BREAKING CHANGE a piè di pagina

refactor!: drop support for Node 6

BREAKING CHANGE: dropping Node 6 which hits end of life in April

Messaggio di un commit senza una descrizione

docs: correct spelling of CHANGELOG

Messaggio di un commit con uno contesto

feat(lang): added polish language

Messaggio di un commit per un fix utilizzando il numero della issue (opzionale)

fix: minor typos in code

see the issue for details on the typos fixed

Reviewed-by: Z
Refs #133

Specifica

Le parole “DEVE”, “NON DEVE”, “RICHIESTO”, “DOVRÀ”, “NON DOVRÀ”, “DOVREBBE”, “NON DOVREBBE”, “RACCOMANDATO”, “POTREBBE” e “OPZIONALE” devo essere interpretata come da specifica RFC 2119.

1. Un commit DEVE iniziare con un tipo, il quale consiste in un sostantivo, feat, fix, etc., seguito da un OPZIOANLE !, e DEVE essere seguito dai due punti ed uno spazio.
2. Il tipo feat DEVE essere usato quando un commit aggiunge una funzionalità all'applicazione o libreria.
3. Il tipo fix DEVE essere usato quando un commit corregge un errore all'applicazione o libreria.
4. Un contesto opzionale POTREBBE essere fornito dopo il tipo. Un contesto rappresenta una sezione dell'applicazione o della libreria, il contenuto va racchiuso tra parentesi. Es: fix(parser):
5. Una descrizione DEVE seguire immediatamente i due punti dopo il tipo (con eventuale contesto). Per descrizione si intende una breve spiegazione riguardo la modifica al codice. Es: fix: array parsing issue when multiple spaces were contained in string.
6. Un corpo del commit più lungo POTREBBE essere aggiunto dopo una breve descrizione, aggiungendo ulteriori informazioni contestuali riguardo le modifiche apportate al codice. Il corpo DEVE iniziare dopo una linea vuota dalla descrizione.
7. Un corpo può contenere qualsiasi contenuto e POTREBBE essere formato da qualsiasi numero di linee separate.
8. Uno o più pié di pagina POTREBBERO essere usati dopo una linea vuota dallo spazio. Ogni piè di pagina DEVE avere una parola chiave seguita da :<space> o <space>#, poi seguita da un token(ispirato a git trailer convention).
9. Un token DEVE usare - al posto degli spazi, ad esempio, Acked-by (questo serve a distinguere piè di pagina e corpo). Un eccezione è fatta per BREAKING CHANGE, ch POTREBBE essere utilizzata come token.
10. Un piè di pagina POTREBBE contenere spazi e linee vuote, and DEVE finire quando si incontra il token.
11. Una breaking changes DEVE essere indicata dopo il tipo/contesto come !, all'inizio delle sezioni piè di pagina o del corpo del commit. Una breaking change DEVE essere scritta in maiuscolo BREAKING CHANGE, seguita dai due punti ed uno spazio.
12. Una descrizione DEVE essere aggiunta dopo il testo BREAKING CHANGE: , descrivendo il cambiamento delle API. Es: BREAKING CHANGE: environment variables now take precedence over config files.
13. Un ! POTREBBE essere aggiunti prima del prefisso: nel tipo/contesto, per attirare notificare l'introduzione di una breaking change. BREAKING CHANGE: description DEVE essere aggiungto nel copro o piè di pagina se un ! è presente.
14. Un commit POTREBBE utilizzare altri tipi al di fuori di feat e fix nel messaggio.
15. La convenzione NON DEVE tener conto del maiuscolo o minuscolo, ad eccezione di BREAKING CHANGE che DEVE sempre essere maiuscolo.
16. BREAKING-CHANGE equivale a BREAKING CHANGE

Perchè utilizzare commit convenzionali

• CHANGELOG generati automaticamente.
• Determina automaticamente l'incremento di un versionamento semver (basandosi sui tipi di commit utilizzati).
• Comunica la natura dei cambiamenti a colleghi, pubblico, o altri parti interessate.
• Attiva build e processi di rilascio.
• Rendi più semplice alle persone contribuire al tuo progetto, dando la possibilità di esplorare una cronologia di commit più strutturata.

FAQ

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.

I tipi devono essere in maiuscolo o minuscoli?

Si possono utilizzare entrambi, ma si raccomanda di essere consistenti ed utilizzarne solamente uno.

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.

Non scoraggia sviluppo ed iterazioni rapidi?

Scoraggia a farlo in una maniere disorganizzata. Inoltre ti aiuterà a muoverti più velocemente su più progetti con diversi contributori.

Potrebbe Commit Convenzionali limitare gli sviluppatori a fare solamente alcuni tipi commit perchè penseranno nei tipi forniti dalla specifica?

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.

Come si collega a SemVer?

I commit di tipo fix dovrebbero essere traducibili ai rilasci PATCH. I commit di tipo feat dovrebbero essere traducibili ai rilasci MINOR. I commit con BREAKING CHANGE, indipendentemente dal tipo, dovrebbero essere traducibili ai rilasci MAJOR.

Come dovrei versionare le mie estensioni per la specifica Commit Convenzionali? (Es: @jameswomack/conventional-commit-spec)

Raccomandiamo l'utilizzo di SemVer per rilasciare la tua estensione (crea delle estensioni!)

Cosa faccio se accidentalmente utilizzo un tipo di commit sbagliato?

Quando usi un tipo della specifica ma non quello giusto (Es: fix invece di feat)

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.

Quando usi un tipo non della specifica (Es: feet invece di feat)

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.

Devono tutti i contributori seguire la specifica Commit Convenzionali?

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.