Écrire de bons messages de commit avec Git

De Ensiwiki
Révision de 5 décembre 2013 à 20:08 par Moym (discussion | contributions) (catégories)

Aller à : navigation, rechercher

Git conserve l'historique de toutes les révisions d'un projet. C'est entre autre ce qui permet de faire des fusions automatiques, et une utilisation évidente de l'historique est de pouvoir rattraper des bêtises a posteriori (« j'ai effacé la fonction f() la semaine dernière, je me rends compte aujourd'hui que j'en avais besoin, comment la récupérer ? »). Mais c'est loin d'être le seul intérêt :

  1. Il arrive parfois qu'on se demande pourquoi, et dans quelles conditions une ligne de code a été introduite. La commande git blame permet de trouver le commit qui a introduit chaque ligne d'un fichier, et on peut donc savoir quand et par qui la ligne a été introduite. Si le commit a été fait proprement, il est accompagné d'un message explicatif (message de commit, ou message de log).
  1. Quand une régression est détectée dans un projet (un bug présent mais qui n'existait pas avant), on peut remonter dans l'historique pour trouver quel commit a introduit le bug (la commande git bisect permet même de le faire automatiquement). Une fois le commit identifié, on peut regarder ce qu'il contient pour comprendre l'origine du bug.

Dans les deux cas, on apprécie d'avoir un message de commit détaillé. Ces messages sont presque aussi importants que les commentaires dans le code (certains diraient même « plus importants »). Cet article donne quelques pistes pour écrire de bons messages de commits.

Sur le fond : répondre à la question « Pourquoi ? »

Sur la forme : sommaire, et corps du message