mirrors/conventionalcommits.org
0
0
Fork 0
mirror of https://github.com/conventional-commits/conventionalcommits.org.git synced 2025-08-22 13:58:35 +00:00
Code

docs(it): fix italian translation

Browse Source
This commit is contained in:
Giuseppe Catillo 2025-04-30 01:13:32 +02:00 committed by GitHub
parent 5fbee8281e
commit 4e893a1316
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 87 additions and 74 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

161
content/v1.0.0/index.it.md
View File

@ -11,10 +11,10 @@ La specifica Conventional Commits è una convenzione semplice da implementare pe
Fornisce un insieme di semplici regole per la creazione di una cronologia di commit esplicita;
il che rende più facile utilizzare strumenti per automatizzare processi.
Questa convenzione si completa con [SemVer](http://semver.org/lang/it/),
descrivendo le funzionalità, la risoluzione di errori e l'introduzione di breaking changes fatte dei commit.
descrivendo le funzionalità, la risoluzione di errori e l'introduzione di breaking changes fatte dei messaggi dei commit.
I messaggi dei commit dovrebbero seguire la seguente struttura:
Il messaggio del commit dovrebbe seguire la seguente struttura:
---
@ -28,24 +28,22 @@ I messaggi dei commit dovrebbero seguire la seguente struttura:
---
<br />
Il commit contiene i seguenti elementi strutturali, allo scopo di comunicare l'intento al consumatore della libreria:
Il commit contiene i seguenti elementi strutturali, allo scopo di comunicare l'intento al consumatore della tua libreria:
1. **fix:** un commit di _tipo_ `fix` risolve un errore nel codice (correlato al [`PATCH`](http://semver.org/#summary) in un versionamento Semver).
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 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`](http://semver.org/#summary) in un versionamento Semver).
Una _BREAKING CHANGE_ può essere parte di un commit di qualsiasi _tipo_.
1. Sono ammessi ulteriori _tipi_ oltre `fix:` e`feat:`, per esempio [commitlint-config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (che si basa sulla [convenzione Angular](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines))
1. **fix:** un commit di _tipo_ `fix` risolve un errore nel codice (correlato al [`PATCH`](http://semver.org/#summary) in un Versionamento Semantico).
1. **feat:** un commit di _tipo_ `feat` introduce una nuova funzionalità al codice (correlato al [`MINOR`](http://semver.org/#summary) in un Versionamento Semantico).
1. **BREAKING CHANGE:** un commit che contiene in un _piè di pagina_ `BREAKING CHANGE:`, o aggiunge un `!` subito dopo il _tipo_/_contesto_, introduce una breaking API change (correlato al [`MAJOR`](http://semver.org/#summary) in un Versionamento Semantico). Una _BREAKING CHANGE_ può essere parte di commit di qualsiasi _tipo_.
1. Sono ammessi ulteriori _tipi_ oltre `fix:` e `feat:`, per esempio [commitlint-config-conventional](https://github.com/conventional-changelog/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 `build:`, `chore:`, `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, ed altri.
1. Altri _piè di pagina_ oltre `BREAKING CHANGE: <description>` possono essere utilizzati e seguono ua specifica simile a [git trailer format](https://git-scm.com/docs/git-interpret-trailers).
1. Altri _piè di pagina_ oltre `BREAKING CHANGE: <description>` possono essere utilizzati e seguono una specifica simile a [git trailer format](https://git-scm.com/docs/git-interpret-trailers).
Altri _tipi_ non sono mantenuti da questa specifica, e non hanno un effetto sul versionamento semver (a meno che non introducano una _BREAKING CHANGE_).
Altri _tipi_ non sono mantenuti da questa specifica, e non hanno un effetto sul Versionamento Semantico (a meno che non introducano una _BREAKING CHANGE_).
<br />
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`.
Un _contesto_ potrebbe essere aggiunto al _tipo_ di commit, al fine di offrire informazioni contestuali aggiuntive ed è contenuto tra parentesi, es. `feat(parser): add ability to parse arrays`.
## Esempi
### Messaggio di un commit con una _descrizione_ e una breaking change nel _piè di pagina_
### Messaggio di un commit con una descrizione e una breaking change nel piè di pagina
```
feat: allow provided config object to extend other configs
@ -57,33 +55,37 @@ BREAKING CHANGE: `extends` key in config file is now used for extending other co
feat!: send an email to the customer when a product is shipped
```
### Messaggio di un commit con uno contesto e `!` per attirare attenzione ad una breaking change
### Messaggio di un commit con un contesto e `!` per attirare l'attenzione su una breaking change
```
feat(api)!: send an email to the customer when a product is shipped
```
### Messaggio di un commit con entrambe `!` e _BREAKING CHANGE_ a piè di pagina
### Messaggio di un commit con entrambe `!` e BREAKING CHANGE a piè di pagina
```
feat!: send an email to the customer when a product is shipped
chore!: drop support for Node 6
BREAKING CHANGE: dropping Node 6 which hits end of life in April
BREAKING CHANGE: use JavaScript features not available in Node 6.
```
### Messaggio di un commit senza una _descrizione_
### Messaggio di un commit senza una descrizione
```
docs: correct spelling of CHANGELOG
```
### Messaggio di un commit con uno _contesto_
### Messaggio di un commit con un contesto
```
feat(lang): added polish language
feat(lang): add Polish language
```
### Messaggio di un commit per un `fix` utilizzando il numero della issue (opzionale)
### Messaggio di un commit con una descrizione multi-paragrafo e piè di pagina multipli
```
fix: minor typos in code
fix: prevent racing of requests
see the issue for details on the typos fixed
Introduce a request id and a reference to latest request. Dismiss
incoming responses other than from latest request.
Remove timeouts which were used to mitigate the racing issue but are
obsolete now.
Reviewed-by: Z
Refs: #133
@ -91,50 +93,46 @@ 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](https://www.ietf.org/rfc/rfc2119.txt).
Le parole chiave “DEVE”, “NON DEVE”, “RICHIESTO”, “DOVRÀ”, “NON DOVRÀ”, “DOVREBBE”, “NON DOVREBBE”, “RACCOMANDATO”, “POTREBBE” e “OPZIONALE” vanno interpretate come descritto in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
1. Un commit DEVE iniziare con un _tipo_, il quale consiste in un sostantivo, `feat`, `fix`, etc., seguito da un OPZIONALE `!`, e DEVE essere seguito dai due punti ed uno spazio.
1. Il _tipo_ `feat` DEVE essere usato quando un commit aggiunge una funzionalità all'applicazione o libreria.
1. Il _tipo_ `fix` DEVE essere usato quando un commit corregge un errore all'applicazione o libreria.
1. 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):`
1. 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_.
1. 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_.
1. Un _corpo_ può contenere qualsiasi contenuto e POTREBBE essere formato da qualsiasi numero di linee separate.
1. 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
1. I commit DEVONO essere preceduti da un _tipo_, il quale consiste in un sostantivo, `feat`, `fix`, etc., seguito dal _contesto_ OPZIONALE, dal `!` OPZIONALE, e dai due punti ed uno spazio RICHIESTI.
1. Il _tipo_ `feat` DEVE essere usato quando un commit aggiunge una nuova funzionalità alla tua applicazione o libreria.
1. Il _tipo_ `fix` DEVE essere usato quando un commit corregge un errore per tua applicazione o libreria.
1. Un _contesto_ POTREBBE essere fornito dopo un _tipo_.
Un _contesto_ DEVE consistere in un sostantivo che descrive una sezione dell'applicazione o della libreria, racchiuso tra parentesi, es. `fix(parser):`
1. Una _descrizione_ DEVE seguire immediatamente i due punti e lo spazio dopo il prefisso _tipo_/_contesto_.
La _descrizione_ è un breve riassunto delle modifiche al codice, es. _fix: array parsing issue when multiple spaces were contained in string_.
1. Un _corpo_ del commit più lungo POTREBBE essere aggiunto dopo la breve _descrizione_, fornendo informazioni contestuali aggiuntive riguardo le modifiche apportate al codice.
Il _corpo_ DEVE iniziare con una riga vuota dopo la _descrizione_.
1. Un _corpo_ può contenere qualsiasi contenuto e POTREBBE essere formato da qualsiasi numero di paragrafi separati da una nuova riga.
1. Uno o più _pié di pagina_ POTREBBERO essere forniti con una riga vuota dopo il _corpo_.
Ogni _piè di pagina_ DEVE avere una parola chiave, seguita da un _separatore_ `:<space>` o `<space>#`, a sua volta seguito da un _token_ (ispirato a
[git trailer convention](https://git-scm.com/docs/git-interpret-trailers)).
1. 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_.
1. Un _piè di pagina_ POTREBBE contenere spazi e linee vuote, and DEVE finire quando si incontra il _token_.
1. 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.
1. 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._
1. 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.
1. Un commit POTREBBE utilizzare altri _tipi_ al di fuori di `feat` e `fix` nel messaggio.
1. La convenzione NON DEVE tener conto del maiuscolo o minuscolo, ad eccezione di `BREAKING CHANGE` che DEVE sempre essere maiuscolo.
1. `BREAKING-CHANGE` equivale a `BREAKING CHANGE`
1. Il _token_ di un _piè di pagina_ DEVE usare `-` al posto degli spazi bianchi, es. `Acked-by` (questo aiuta a distinguere la sezione del _piè di pagina_ da un _corpo_ multiparagrafo).
Un'eccezione è fatta per `BREAKING CHANGE`, che POTREBBE essere utilizzato anche come _token_.
1. Il valore di un _piè di pagina_ POTREBBE contenere spazi e linee vuote, e il parsing DEVE finire quando si osserva la prossima coppia _token_/_separatore_ di _piè di pagina_ valida.
1. Eventuali _breaking changes_ DEVONO essere indicate nel prefisso _tipo_/_contesto_ di un commit, o come voce nel _piè di pagina_.
1. Se inclusa nel _piè di pagina_, una _breaking change_ DEVE consistere nel testo maiuscolo `BREAKING CHANGE`, seguito dai due punti, spazio e descrizione, es. _BREAKING CHANGE: environment variables now take precedence over config files_.
1. Se inclusa nel prefisso _tipo_/_contesto_, una _breaking change_ DEVE essere indicata con un `!` immediatamente prima del `:`. Se viene usato `!`, `BREAKING CHANGE:` POTREBBE essere omesso dal _piè di pagina_, e la descrizione del commit DOVRÀ essere utilizzata per descrivere la _breaking change_.
1. Altri _tipi_ al di fuori di `feat` e `fix` POTREBBERO essere utilizzati nei tuoi messaggi di commit, es. _docs: update ref docs_.
1. Gli implementatori NON DEVONO tener conto del maiuscolo o minuscolo per le unità di informazione che compongono i Commit Convenzionali, ad eccezione di `BREAKING CHANGE` che DEVE essere maiuscolo.
1. `BREAKING-CHANGE` DEVE essere sinonimo di `BREAKING CHANGE`, quando usato come token in un _piè di pagina_.
## Perchè utilizzare commit convenzionali
## Perchè utilizzare i 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.
* Generazione automatica dei CHANGELOG.
* Determinazione automatica di un incremento di versione semantica (basata sui tipi di commit effettuati).
* Comunicazione della natura dei cambiamenti ai membri del team, al pubblico e altre parti interessate.
* Attivazione dei processi di build e rilascio.
* Facilitazione del contributo ai tuoi progetti, dando la possibilità alle persone di esplorare una cronologia dei commit più strutturata.
## FAQ
### Come dovrei comportarmi con i messaggi dei commit nella fase iniziale del progetto?
### Come dovrei gestire i messaggi di commit nella fase iniziale di sviluppo?
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.
Raccomandiamo di procedere come se il tuo prodotto sia già stato rilasciato. Tipicamente *qualcuno*, anche solo i tuoi colleghi sviluppatori, sta già utilizzando il tuo software. Loro vorranno sapere cosa è stato risolto, cosa si è rotto etc.
### I _tipi_ devono essere in maiuscolo o minuscoli?
### I tipi nel titolo del commit devono essere in maiuscolo o minuscolo?
Si possono utilizzare entrambi, ma si raccomanda di essere consistenti ed utilizzarne solamente uno.
@ -142,34 +140,49 @@ Si possono utilizzare entrambi, ma si raccomanda di essere consistenti ed utiliz
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?
### Questo non scoraggia lo sviluppo rapido ed iterativo?
Scoraggia a farlo in una maniere disorganizzata. Inoltre ti aiuterà a muoverti più velocemente su più progetti con diversi contributori.
Scoraggia a farlo in una maniera disorganizzata. Sul lungo termine, aiuta a muoversi rapidamente 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?
### I Commit Convenzionali potrebbero limitare gli sviluppatori a fare solamente alcuni tipi commit perchè penseranno solo ai 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.
I Commit Convenzionali ci incoraggiano a fare più commit di certi tipi, come le correzioni. A parte questo, la flessibilità dei Commit Convenzionali consente al tuo team di inventare i propri tipi e di 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`.
I commit di tipo `fix` dovrebbero essere tradotti in rilasci di tipo `PATCH`.
I commit di tipo `feat` dovrebbero essere tradotti in rilasci di tipo `MINOR`.
I commit con `BREAKING CHANGE`, indipendentemente dal tipo, dovrebbero essere tradotti in rilasci di tipo `MAJOR`.
### Come dovrei versionare le mie estensioni per la specifica Commit Convenzionali? (Es: `@jameswomack/conventional-commit-spec`)
### Come dovrei versionare le mie estensioni per la specifica dei Commit Convenzionali, es. `@jameswomack/conventional-commit-spec`?
Raccomandiamo l'utilizzo di SemVer per rilasciare la tua estensione (crea delle estensioni!)
Raccomandiamo l'utilizzo di SemVer per rilasciare le tue estensioni (e ti incoraggiamo a creare queste estensioni!)
### Cosa faccio se accidentalmente utilizzo un tipo di commit sbagliato?
### Cosa faccio se utilizzo accidentalmente il tipo di commit sbagliato?
#### Quando usi un tipo della specifica ma non quello giusto (Es: `fix` invece di `feat`)
#### Quando hai utilizzato un tipo previsto dalla 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.
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 tu abbia già rilasciato questa correzione, dipende dai tool e dai processi che usi.
#### Quando usi un tipo *non* della specifica (Es: `feet` invece di `feat`)
#### Quando hai utilizzato un tipo *non* previsto dalla 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.
Nel peggiore dei casi, non è la fine del mondo se un commit non segue la specifica dei Commit Convenzionali. Significa semplicemente che il commit verrà ignorato dai tool che sono basati su tale specifica.
### Devono tutti i contributori seguire la specifica Commit Convenzionali?
### Tutti i miei collaboratori devono usare la specifica dei 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.
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), senza aggiungere alcun carico di lavoro ai committer occasionali. Un workflow comune è quello di unire (con lo squash) automaticamente i commit da una pull request e far utilizzare un form ai mantenitori per riscrivere un messaggio di commit più adeguato.
### In che modo i Commit Convenzionali gestiscono i commit di revert?
Il revert del codice può essere complicato: stai ripristinando più commit? se ripristini una funzionalità, la prossima release dovrebbe essere una patch?
I Conventional Commits non fanno uno sforzo esplicito per definire il comportamento del revert.
Lasciano invece agli autori dei tool la libertà di usare i _tipi_ e i _piè di pagina_ per sviluppare la loro logica di gestione dei revert.
Una raccomandazione è usare il tipo `revert` e un _piè di pagina_ che faccia riferimento agli SHA dei commit ripristinati:
```
revert: let us never again speak of the noodle incident
Refs: 676104e, a215868
```