Secondo la documentazione di Conventional Commits , i commit semantici sono una semplice convenzione da utilizzare nei messaggi di commit.
Questa convenzione stabilisce un insieme di regole per creare un registro dei commit esplicito, che facilita la creazione di strumenti automatizzati.
Questi commit aiuteranno te e il tuo team a capire facilmente quali modifiche sono state apportate alla sezione di codice che è stata committata.
Questa identificazione avviene attraverso una parola e un'emoji che identifica se quel commit riguarda una modifica del codice, un aggiornamento dei pacchetti, la documentazione, una modifica visuale, un test...
Il commit semantico ha i seguenti elementi strutturali (tipi), che indicano l'intenzione del tuo commit all'utilizzatore del tuo codice.
-
feat- I commit di tipo feat indicano che il pezzo di codice include una nuova funzionalità, (relativa al MINOR del versioning semantico). -
fix- I commit di tipo fix indicano che il pezzo di codice committato è una correzione di bug, (correlata alla PATCH del versioning semantico). -
docs- I commit di tipo docs indicano che ci sono state modifiche alla documentazione, per esempio nel Readme del repository (non include modifiche al codice). -
test- I commit di tipo test sono utilizzati quando vengono effettuate modifiche ai test, sia creando, modificando o eliminando test unitari. (Non include modifiche al codice) -
build- I commit di tipo build sono utilizzati quando vengono effettuate modifiche a file di build e dipendenze. -
perf- I commit di tipo perf servono per identificare eventuali modifiche al codice che riguardano la performance. -
style- I commit di tipo style indicano che sono state apportate modifiche a formati del codice, punti e virgola, spazi intermedi, lint... (non include modifiche al codice). (non include modifiche al codice). -
refactor- I commit di tipo refactor si riferiscono a modifiche dovute a un refactoring che non cambia la funzionalità, ad esempio un cambiamento nel modo in cui viene resa una certa parte dello schermo, ma che ha mantenuto la stessa funzionalità, o miglioramenti delle prestazioni dovuti a una revisione del codice. -
chore- I commit di tipo chore indicano aggiornamenti di task di compilazione, impostazioni dell'amministratore, pacchetti... come l'aggiunta di un pacchetto a gitignore. -
ci- I commit di tipo ci indicano modifiche relative a integrazione continua.
- Aggiungere un titolo coerente con il titolo del contenuto;
- Si raccomanda che la prima riga non sia più lunga di 4 parole;
- Per descrivere in dettaglio, usare la descrizione del commit;
- Utilizzare un emoji all'inizio del messaggio di commit che rappresenti il commit;
- Un link deve essere aggiunto nella sua forma più autentica, cioè senza accorciatori di link e link affiliati;
- Footer: Di solito un'informazione sul revisore e il numero di card di trello o jira Esempio: Reviewed-by: Angelo Bertozzi Refs #133
- Body: descrizioni più precise di ciò che è contenuto nel commit, presentando gli impatti e le ragioni per cui sono state apportate le modifiche al codice, nonché le istruzioni essenziali per gli interventi futuri. Esempio: see the issue for details on typos fixed.
- Descrizioni**: una breve descrizione della modifica.
- Esempio: correct minor typos in code
| Tipo di commit | Emojis | Parola chiave |
|---|---|---|
| Accessibilità | ♿ :wheelchair: |
|
| Aggiunta di un test | ✅ :white_check_mark: |
test |
| Aggiunta di una dipendenza | ➕ :heavy_plus_sign: |
build |
| Modifiche di revisione del codice | 👌 :ok_hand: |
style |
| Animazioni e transizioni | 💫 :dizzy: |
|
| Bugfix | 🐛 :bug: |
fix |
| Commenti | 💡 :bulb: |
docs |
| Primo commit | 🎉 :tada: |
init |
| Configurazione | 🔧 :wrench: |
chore |
| Deploy | 🚀 :rocket: |
|
| Documentazione | 📚 :books: |
docs |
| In corso | 🚧 :construction: |
|
| Stilizzazione dell'interfaccia | 💄 :lipstick: |
feat |
| Infrastruttura | 🧱 :bricks: |
ci |
| Elenco di idee (tasks) | 🔜 :soon: |
|
| Spostare/Rinominare | 🚚 :truck: |
chore |
| Nuova funzionalità | ✨ :sparkles: |
feat |
| Package.json in JS | 📦 :package: |
build |
| Prestazioni | ⚡ :zap: |
perf |
| Rifattorizzazione | ♻️ :recycle: |
refactor |
| Rimozione di un file | 🔥 :fire: |
|
| Rimozione di una dipendenza | ➖ :heavy_minus_sign: |
build |
| Reattività | 📱 :iphone: |
|
| disfare modifiche | 💥 :boom: |
fix |
| Sicurezza | 🔒️ :lock: |
|
| SEO | 🔍️ :mag: |
|
| Tag di versione | 🔖 :bookmark: |
|
| Test di approvazione | ✔️ :heavy_check_mark: |
test |
| Test | 🧪 :test_tube: |
test |
| Testo | 📝 :pencil: |
|
| Tipizzazione | 🏷️ :label: |
|
| Gestione degli errori | 🥅 :goal_net: |
| Comando git | Risultato su GitHub |
|---|---|
git commit -m ":tada: Commit iniziale"
|
🎉 Commit iniziale |
git commit -m ":books: docs: Aggiornamento del README"
|
📚 docs: Aggiornamento del README |
git commit -m ":bug: fix: Loop infinito alla riga 50"
|
🐛 fix: Loop infinito alla riga 50 |
git commit -m ":sparkles: feat: Pagina di login"
|
✨ feat: Pagina di login |
git commit -m ":bricks: ci: Modifica in Dockerfile"
|
🧱 ci: Modifica in Dockerfile |
git commit -m ":recycle: refactor: Conversione in arrow functions"
|
♻️ refactor: Conversione in arrow functions |
git commit -m ":zap: perf: Miglioramento del tempo di risposta"
|
⚡ perf: Miglioramento del tempo di risposta |
git commit -m ":boom: fix: disfare modifiche inefficienti"
|
💥 fix: disfare modifiche inefficienti |
git commit -m ":lipstick: feat: Stilizzazione CSS del modulo"
|
💄 feat: Stilizzazione CSS del modulo |
git commit -m ":test_tube: test: Creazione di un nuovo test"
|
🧪 test: Creazione di un nuovo test |
git commit -m ":bulb: docs: Commenti sulla funzione LoremIpsum( )"
|
💡 docs: Commenti sulla funzione LoremIpsum( ) |
Per implementarlo nel proprio progetto, è necessario installare gli strumenti necessari per facilitare l'uso dei commit convenzionali. Ci sono due opzioni popolari: Commitlint e Commitizen