Modelli di messaggio di commit Git

Modelli di messaggio riutilizzabili in stile Conventional Commits e pronti per le PR che si espandono nel tuo terminale ed editor.

Panoramica della categoria dei modelli

Messaggi di commit coerenti rendono leggibile la storia di un repository, abilitano changelog automatici e velocizzano la revisione del codice — ma digitare a mano un Conventional Commit ben strutturato ogni volta è abbastanza noioso da far ripiegare la maggior parte degli sviluppatori su riassunti di una riga. Un espansore di testo lo risolve trasformando un trigger breve in un'impalcatura di commit completa con tipo, scope, riassunto, corpo e footer già disposti, così riempi i dettagli invece di ricordare il formato. Poiché Lightning Assist funziona a livello di sistema — incluso il terminale, dove avviene la maggior parte dei commit, e la casella di commit di VS Code — gli stessi modelli funzionano sia che tu committi dalla riga di comando, dal tuo IDE o da una GUI Git. La voce Push-to-Talk può persino dettare il paragrafo più lungo del corpo quando hai le mani lontane dalla tastiera a metà di un debug.

Quando utilizzare questi modelli

Usa i modelli di messaggio di commit a ogni commit, ma rendono di più sui commit che contano in seguito: le correzioni di bug che rivedrai, i breaking change che toccano altri team e qualsiasi commit in un repo che genera automaticamente release o changelog dalla storia. Se il tuo progetto usa Conventional Commits, semantic-release o qualsiasi automazione di changelog, un'impalcatura coerente non è solo ordine — è ciò che fa funzionare la tooling. Anche su progetti in solitaria, un git log leggibile scritto in un formato coerente fa risparmiare tempo reale quando fai il bisect di una regressione o cerchi di ricordare perché un cambiamento è stato fatto sei mesi fa.

Modelli di esempio in questa categoria

Impalcatura di Conventional Commit: tipo, scope opzionale, riassunto, corpo e footer con riferimento al ticket.
Commit di fix con contesto del bug: cosa si è rotto, la correzione e l'issue che chiude.
Commit di breaking change: la modifica più un footer BREAKING CHANGE chiaramente marcato per la tooling di release.

Modelli di esempio nella pratica

Impalcatura di Conventional Commit

Il modello di tutti i giorni per qualsiasi commit, secondo la specifica Conventional Commits che alimenta gli strumenti di versionamento e changelog automatici. La struttura è un tipo (feat, fix, chore, docs, refactor, test, ecc.), uno scope opzionale tra parentesi, un riassunto conciso all'imperativo sotto circa cinquanta caratteri, una riga vuota, poi un corpo che spiega il perché e un footer per i riferimenti ai ticket. Tieni questo su un trigger breve come ;cc così si espande nel terminale prima che tu scriva il messaggio. Riempire un'impalcatura coerente ogni volta è ciò che rende un git log davvero utile mesi dopo, ed è la differenza tra uno strumento di release che può generare un changelog automaticamente e uno che non può.

[#type#]([#scope#]): [#summary#]

[#why this change was made#]

Refs: [#ticket#]

Commit di fix con contesto del bug

I commit di correzione bug sono quelli che il tuo io futuro ha più bisogno di capire, quindi meritano più di «fix bug». Cattura tre cose: cosa si è rotto (il sintomo osservabile), cosa fa la correzione e quale issue chiude così che il tracker si aggiorni automaticamente. Il footer «Closes #» è ciò che collega il commit al tuo issue tracker e chiude il ticket al merge sulla maggior parte delle piattaforme. Tieni questo su un trigger come ;fix. Quando sei immerso in una sessione di debug e vuoi registrare la causa radice in linguaggio chiaro, la voce Push-to-Talk ti lascia dettare il corpo senza rompere il flusso, e AI Enhance può stringere una spiegazione dettata e prolissa in un paragrafo pulito.

fix([#scope#]): [#what was broken#]

[#root cause and what the fix does#]

Closes #[#issue#]

Commit di breaking change

Quando un commit cambia un'API, un formato di configurazione o qualsiasi contratto da cui dipende altro codice, il breaking change deve essere marcato esplicitamente così che la tooling di release attivi un salto di versione major e il changelog avvisi gli utenti. Lo standard Conventional Commits usa un footer BREAKING CHANGE: (o un ! dopo il tipo) proprio per questo. Specifica cosa si è rotto e, soprattutto, cosa devono fare i consumatori per migrare — un breaking change senza nota di migrazione si trasforma in un'ondata di domande di supporto. Tieni questo su un trigger deliberato come ;ccbreak così vi ricorri solo quando lo intendi davvero, poiché etichettare male un breaking change è peggio che non etichettarlo.

[#type#]([#scope#])!: [#summary#]

[#what changed#]

BREAKING CHANGE: [#what consumers must change to migrate#]

Refs: [#ticket#]

Come iniziare

Inizia con l'impalcatura generale di Conventional Commit su un trigger breve come ;cc, con segnaposto per tipo, scope, riassunto, corpo e ticket. Aggiungi una variante ;fix precompilata con il tipo fix e un footer «Closes #», e una variante ;ccbreak con il footer BREAKING CHANGE per i rari ma importanti commit che rompono la compatibilità. Digita il trigger nel tuo terminale o nella casella di commit del tuo editor e si espande in linea mentre scrivi — senza scorciatoia, e funziona uguale in entrambi perché l'espansione è a livello di sistema. Quando le impalcature ti vengono naturali, aggiungi modelli di descrizione PR e di risposta di revisione del codice così che tutto il flusso di invio modifiche sia coerente.

Suggerimenti professionali

Tieni la riga di riassunto sotto i ~50 caratteri e all'imperativo («add», non «added») — la maggior parte della tooling git e dei revisori si aspetta questa convenzione.
Usa un footer «Closes #[issue]» sui commit di fix così che il merge della modifica chiuda automaticamente il ticket collegato nel tuo tracker.
Riserva il modello di breaking change ai veri cambiamenti di contratto e includi sempre il passo di migrazione — una nota di rottura senza di esso crea solo carico di supporto.
Detta il corpo del commit con Push-to-Talk quando hai le mani lontane dalla tastiera a metà di un debug, poi stringi la formulazione con AI Enhance.

Usa questi modelli in qualsiasi app

Crea snippet riutilizzabili da questi esempi ed eseguili con accesso rapido, scorciatoie di attivazione o miglioramenti dell'intelligenza artificiale.

Inizia la prova gratuita