Messaggi di commit in Git


Lezione 50 / 53

Messaggi di commit in Git

Di Luca Ferretti


git guida git guida git italiano

Sebbene nel tempo si siano identificati con “git workflow” una serie di indicazioni relative all’uso di branch e strategie per il merge, non bisogna dimenticare che contribuiscono a un uso produttivo di Git anche strategie e convenzioni legati all’uso dei messaggi di commit e all’uso dei tag per il versionamento. Anche su tale aspetto Git non è prescrittivo, lasciando ai singoli scegliere il modo più adeguato.
 

Messaggi di commit in Git

Per quanto riguarda i messaggi di commit, è importante ricordare che Git permette di inserire un messaggio di commit formato di più righe, usando poi la prima riga del messaggio come “subject” (indicativo da questo punto è la differenza tra git log e git log --oneline).

Un messaggio di commit per l’aggiunta di questa sezione potrebbe essere simile al seguente:

Add commit message section in workflow chapter

More specific info about how to write a commit message and some
guidelines about why it is important to keep them consistent.

We opted to suggest the following:

- use short first line as summary (less than 72 chars, 50 is best)
- wrap body lines to 72 chars (useful to read log on terminal)
- use imperative form for first summary line: "Fix bug", not "Fixed
  bug" or "Fixes bug"
- do the best to format body part to make it readable
- use body part to describe how and why for the commit, as well as
  references to other commits, issues, ...
- think if, in 6 months, you'll be able to understand the change just
  reading the commit message ;-)

Complete and close issue #12 

In breve:

  • la prima riga del messaggio è la più importante
  • le altre righe possono essere usate per chiarire riferimenti, motivazioni e limitazioni legate alle modifiche salvate nel commit, che magari non era necessario o possibile aggiungere direttamente nei file di progetto modificati
  • è utile uniformarsi a uno stile comune e coerente per sapere cosa e come trovare informazioni nei messaggi di commit

Una convenzione sui messaggi di commit abbastanza condivisa nel mondo dello sviluppo è quella che prende il nome di Conventional Commit (o Semantic Commit). Questa convenzione indica alcune semplici regole per creare una history dei commit esplicita (che tipo di modifica ho fatto con quel commit?) e interpretabile da script/automatizzazioni.

Un messaggio di commit in linea con la specifica Conventional Commit è strutturato nella seguente forma:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

e segue le seguenti regole:

  • il <type> deve essere fix per quei commit che correggono un bug
  • il <type> deve essere feat se il commit introduce una nuova funzione
  • <type> diversi fix e feat sono consentiti, suggerendone alcuni (build, chore, ci, docs, style, refactor, perf, test), ma lasciando anche al team di definirne eventualmente di propri
  • se il commit introduce breaking change, questi vanno segnalati iniziando il footer con BREAKING CHANGE: oppure inserendo ! dopo il type/scope nella prima riga.

Se volessimo riscrivere il messaggio di commit d’esempio precedente con queste guideline, potremmo, per esempio, avere qualcosa di simile al seguente:

feat(workflows): add commit messages section

More specific info about how to write a commit message and some
guidelines about why it is important to keep them consistent.

- basic sane guidelines for commit messages
- reference to conventional commit guidelines

Refs: #2472
Reviewed-by: myself

La scelta di scope e delle alte parti opzionali della convezioni sono ovviamente demandate al team, che può regolarsi secondo le proprie necessità.

Per maggiori informazioni rimandiamo al sito ConventionalCommits.

Guida Git in italiano 1 Che cos'è Git? 2 Nascita di Git 3 Principali caratteristiche di Git 4 Riga di comando e UI in Git 5 Come Installare Git 6 5 comandi Git per sviluppatori singoli 7 5 comandi Git per sviluppare collaborando 8 Repository in Git 9 Commit in Git 10 Working Copy in Git 11 Staging Area in Git 12 Branch in Git 13 Remote in Git 14 Inizializzare un nuovo repository con git init 15 Creare una copia di un repository remoto in Git con git clone 16 Configurare le opzioni di Git con git config 17 Il comando Git add in Git 18 Il comando Git commit in Git 19 Il comando Git diff in Git 20 Il comando Git stash in Git 21 .gitignore : i file ignored in Git 22 Il comando Git status in Git 23 il comando Git log in Git 24 Il comando Git tag in Git 25 Il comando Git blame in Git 26 Il comando Git checkout in Git 27 Il comando Git revert in Git 28 Il comando Git reset in Git 29 Il comando Git rm in Git 30 L'opzione Git commit –amend in Git 31 Git rebase –interactive in Git 32 Scorciatoie per comandi frequenti in Git 33 Repository condiviso in Git 34 Il modello Fork & pull 35 Il comando Git remote in Git 36 I principali repository remote di Git: Github, Gitlab e Bitbucket 37 Il comando Git fetch in Git 38 Il comando Git push in Git 39 Il comando Git pull in Git 40 Il comando Git branch in Git 41 Il comando Git checkout in Git 42 Il comando Git merge in Git 43 Risolvere un merge conflict in Git 44 Capire meglio il contenuto dei commit durante un conflitto di merge in Git 45 Workflow Git centralizzato 46 Workflow Git feature branching 47 Workflow Git trunk-based 48 Approccio “forking” in Git 49 Gitflow in Git 50 Messaggi di commit in Git 51 Tagging & Versioning in Git 52 L’opzione merge in Git 53 L’opzione rebase in Git
Scopri i corsi

Le nostre guide possono essere molto utili per muovere i primi passi nel mondo della programmazione, ma se vuoi iniziare una nuova carriera in ambito digital & tech con il supporto costante dei docenti e tantissime esercitazioni pratiche, ti consigliamo di frequentare uno dei corsi della nostra Hackademy!

Scopri i corsi