Ainsi que nous l’avions annoncé dans un précédent post, nous désirons que nos messages de commit suivent les standards de rédaction classiques. Afin de limiter les risques de contrevenir par mégarde à ces règles, plusieurs options s’offrent à nous.
L’option GitLab
Le dépôt distant central, hébergé à Télécom, est un GitLab Community Edition. Gitlab permet de configurer des Push Rules, qui ressemblent à des hooks Git configurables graphiquement et qui nous permettraient de rejeter, lors du push, tout commit ne respectant les règles que nous nous sommes fixées. Malheureusement, la version de Gitlab en place est la version gratuite, qui ne permet pas l’utilisation de cette fonctionnalité. Les hooks classiques peuvent toutefois être configurés, mais cela nécessite un accès administrateur à la machine sur laquelle repose Gitlab (ou du moins à son système de fichiers), ce dont nous ne disposons pas.
Hook local
Après un avoir traversé un court, mais intense, moment de frustration, nous avons décidé de nous rabattre sur une solution alternative : configurer le hook sur nos dépôt locaux. Cette solution permet de rejeter les commits si les messages ne correspondent pas aux règles (ou du moins à certaines) que nous avons fixées.
Cette solution présente quelques petits inconvénients :
- Il faut compter sur chaque développeur pour configurer le hook en question. Comme nous ne sommes que deux, et si nous partons du principe que nous ne réinstallerons pas nos dépôts tous les 4 matins, cela ne devrait pas poser problème. De toute façon, il est plus agréable que le hook se déclenche au commit plutôt qu’uniquement au push : dans le cas contraire, le développeur est forcé de revenir sur son commit et de modifier son message avant d’espérer que son push soit accepté.
- Certaines actions, en particulier les fusions, peuvent parfois se dérouler via l’interface graphique fournie par Gitlab, très confortable et pratique pour cela. Lors de la validation d’un commit de fusion via cette interface, les règles correspondant à nos hooks locaux ne seront pas vérifiées. Il faudra être particulièrement vigilant dans ces cas là.
Script retenu
Après quelques recherches, nous avons décidé de tester git-good-commit. Ce dernier a le bon goût de ne pas nécessiter l’installation d’outils supplémentaires. Le script s’assure que les règles basiques (longueur des différentes parties du message, ponctuation) sont respectées, et embarque une liste de mots à bannir : quelques verbes anglais courants au prétérit et à la troisième personne du singulier. Comme nous avons choisi de rédiger nos messages de commit en anglais, cette liste nous permettra d’éviter les erreurs les plus classiques.
Installation
Il suffit de télécharger le script et de le définir comme hook commit-msg (dernier hook déclenché lors de la constitution d’un commit, lorsque l’éditeur du message se ferme) :
curl https://cdn.rawgit.com/tommarshall/git-good-commit/v0.6.1/hook.sh > .git/hooks/commit-msg
chmod +x .git/hooks/commit-msgÀ partir de là, après la rédaction d’un message de commit ne correspondant pas aux standards, et si le script peut le détecter, un prompt proposera d’éditer le message, de l’abandonner ou de le forcer tel quel.