Docs
Collaborazione
Conventional Commits

Conventional Commits

Ah, i Conventional Commits! La salvezza di chi è stanco di leggere commit del tipo “fix stuff” o il classico “piccole modifiche” (sappiamo tutti che non sono mai piccole). Questa specifica aggiunge significato semantico ai messaggi dei commit, trasformando la storia del progetto da un romanzo horror a un documentario ben strutturato.

🏗️ Struttura Base

Se pensavi che scrivere commit fosse noioso, aspetta di vedere questa elegante struttura (sì, è ironia, ma ti ci abituerai):

<tipo>[scope opzionale]: <descrizione>

[corpo opzionale]

[footer opzionale]

🎯 Tipi principali (aka “Come Non Perdere la Testa”)

  • feat ✨: nuova funzionalità (quando finalmente aggiungi quella feature che il cliente chiede da mesi)
  • fix 🐛: correzione di un bug (ops!)
  • docs 📚: modifiche alla documentazione (sì, anche questa è importante)
  • style 💅: modifiche di formattazione (perché gli spazi sono importanti)
  • refactor 🔧: refactoring del codice (quando fai pulizia senza che nessuno se ne accorga)
  • test 🧪: aggiunta o modifica di test (meglio tardi che mai)
  • chore 🧹: modifiche a build, tool, config, etc. (il lavoro sporco che nessuno vuole fare)

🔄 Integrazione con Jira

Perché non far parlare i tuoi commit direttamente con Jira? È come avere un interprete personale:

1
2
3
4

feat(auth): implementa login OAuth2

[PROJ-123] Aggiunta autenticazione OAuth2 con Google
# No, non è magia, è solo organizzazione! 🎩

Questo permette di:

  • Tracciare facilmente i commit relativi a specifici ticket
  • Generare automaticamente changelog
  • Mantenere una chiara relazione tra codice e task

🛠️ Validazione con Cocogitto

Cocogitto è come avere un severo ma giusto professore che controlla i tuoi commit. Per MacOS (gli altri sistemi sono nel manuale, non facciamo favoritismi 😉):

brew install cocogitto

Per altri sistemi operativi, fare riferimento alla documentazione ufficiale.

Configurazione Base

Creare un file .cog.toml nella root del progetto:

1
2
3

from_latest_tag = true
ignore_merge_commits = true
branch_whitelist = ["main", "master"]

🪝 Git Hooks per la Validazione

Perché fidarsi dell’autocontrollo quando puoi forzare le buone abitudini? Ecco come:

Creare una directory .githooks nella root del progetto:

1

mkdir .githooks

Creare il file .githooks/commit-msg:

1
2
3

#!/bin/sh
MESSAGE=$(cat "$1")
cog verify "$MESSAGE"

Renderlo eseguibile:

1

chmod +x .githooks/commit-msg

Configurare Git per utilizzare la nuova directory degli hook:

1

git config core.hooksPath .githooks

Questo approccio permette di:

  • Versionare gli hook insieme al codice
  • Condividere gli hook con il team
  • Mantenere gli script separati dalla directory .git

✨ Benefici (o “Perché Non Dovresti Ignorare Tutto Questo”)

DevEx Migliorata 🚀:

  • Ricerca facilitata nella storia dei commit
  • Generazione automatica di changelog
  • Versionamento semantico automatico

Conformità ✅:

  • Standard condiviso nel team
  • Validazione automatica
  • Integrazione con strumenti CI/CD

Tracciabilità 🔍:

  • Correlazione diretta con i ticket
  • Storia del progetto chiara e strutturata
  • Facilità nel review process

💡 Best Practices (aka “Regole d’Oro”)

  1. La brevità è l’anima dei commit (max 50 caratteri, non il tuo romanzo)
  2. Usa l’imperativo presente (come se stessi dando ordini al codice)
  3. Riferimento al ticket = karma positivo
  4. Il corpo del commit è come un diario, ma professionale
Ultimo aggiornamento il
Repository docs