Git Commit Linter
Valida i tuoi commit message contro Conventional Commits e altre convenzioni.
Valida il tuo commit message
Supporta messaggi multi-riga: usa la seconda riga vuota per separare il body.
Inserisci un commit message per avviare la validazione in tempo reale.
Come utilizzare Git Commit Linter
1. Scegli la convenzione
Seleziona Conventional Commits, Angular Style o Gitmoji: cambia il set di regole applicate e i tipi ammessi (feat, fix, docs, ...).
2. Incolla il commit message
Scrivi o incolla il messaggio nel campo di testo. Supporta commit multi-riga: header, riga vuota, body e footer (es. BREAKING CHANGE).
3. Leggi il punteggio e le regole
La validazione e' live: ogni modifica ricalcola score percentuale e lista di regole rispettate/fallite, con dettaglio dell'errore per ognuna.
4. Applica il suggerimento corretto
Quando disponibile, usa "Applica" per sostituire il messaggio con la versione corretta automaticamente (punto finale, minuscolo, scope senza spazi) o "Copia" per incollarla altrove.
Suggerimenti
- Usa "Esempio errato" per vedere subito quali regole vengono violate piu' spesso e capire come evitarle.
- Configura un git hook (commit-msg) con Commitlint per applicare queste stesse regole automaticamente ad ogni commit.
- Mantieni la prima riga entro 72 caratteri: e' il limite raccomandato per una leggibilita' ottimale in git log --oneline.
Domande frequenti
Che differenza c'e' tra Conventional Commits e Angular Style?
Angular Style e' un superset di Conventional Commits: usa lo stesso formato type(scope): description ma aggiunge il tipo "release" ai tipi ammessi (feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert). Le altre regole (lunghezza riga, punto finale, minuscolo) sono identiche.
Cosa vuol dire che una regola e' "fixable"?
Le regole con badge "fixable" (es. punto finale, minuscolo, riga vuota prima del body, scope senza spazi) possono essere corrette automaticamente dal tool nel box "Suggerimento corretto". Le regole non fixable (es. tipo non valido, header malformato) richiedono una riscrittura manuale.
Come indico un breaking change nel commit?
In Conventional Commits e Angular Style puoi usare il punto esclamativo dopo tipo/scope (es. feat!: o feat(auth)!:) oppure aggiungere BREAKING CHANGE: descrizione nel footer, separato dal body da una riga vuota. Il linter verifica che almeno uno dei due formati sia presente e corretto.
Perche' il mio commit Gitmoji fallisce la regola "no-conventional-mix"?
Lo stile Gitmoji prevede che il messaggio inizi con un'emoji, non con un prefisso type: description. Se il tool rileva un pattern tipo "feat: descrizione" senza emoji iniziale mentre hai selezionato la convenzione Gitmoji, segnala il mix di stili: scegli uno stile solo per commit.
Il commit message viene inviato a un server per la validazione?
No, tutto il parsing e la validazione avvengono in JavaScript nel browser, senza dipendenze npm ne' chiamate di rete: puoi usarlo anche per validare commit contenenti informazioni sensibili prima del push.