Linee guida commit

Convenzioni Git

Perché scrivere buoni commit ripaga

I messaggi di commit scritti bene servono ad almeno tre scopi:

• velocizzare il processo di review.
• ci aiutano a scrivere dei buoni changelog.
• aiutano nella manutenzione. Chi si ricorda perché ha fatto una modifica al codice due anni fa?

Il commit non è un contenitore dove buttare dentro ogni modifica. Suddividiamoli con logica; almeno finché non li tasseranno.

Consigli

1. Se hai difficoltà a riassumere le modifiche in modo conciso, forse è perché include cambiamenti o bugfix diversi che andrebbero separati.

Errori comuni

Ecco alcuni esempi negativi da evitare:

• Non pushare un commit contenente tutte le modifiche fatte durante la giornata. Git non è un sistema di backup.
• Un commit per ciascun file: una modifica che interessa più file non dovrebbe essere divisa tra più commit.
• Messaggi di commit con etichette imprecise e/o pigri.
• Commit che raggruppano modifiche autonome, che dovrebbero avere ciascuna il proprio commit. Ad esempio: "Fixed bug 2345 and renamed all files" non ha senso di esistere e complica la vita quando è ora di stanare un bug.
• Modifiche ai caratteri di spaziatura e tabulazione vanno in un commit a parte.
• Code drop: copia-incolla di centinaia di linee di codice che sovrascrivono l'intero contenuto del file. Bello, ma non si fa perché le modifiche devono avvenire gradualmente.

Riferimenti alle linee guida

• git-scm.com.
• On commit messages.
• A Note About Git Commit Messages.
• How to write a git commit message.