Ce bref article s’adresse aux personnes qui utilisent déjà Git, ou qui aimeraient l’utiliser. Pour faire simple, Git vous permet de versionner votre code et de travailler tous ensemble sur un même projet (et potentiellement sur un même fichier). Git apporte tout un tas de commandes complémentaires qui s’adaptent à nos besoins de tous les jours.
Je vais commencer par vous parler du commit. Il s’agit d’une commande Git qui permet de cibler les fichiers à enregistrer / versionner sur un serveur Git. Et de leur assigner un message sur ce qui a été fait par le développeur.
L’objectif de cet article ? Lancer des scripts en amont du commit pour valider le code du développeur, avant de le pousser sur le serveur commun. Car si un code bugué arrive sur le serveur commun, cela risque d’embêter d’autres développeurs. En effet, ceux-ci risquent d’être bloqués dans leurs développements. On pourrait aussi lancer d’autres scripts, en amont du commit, pour mettre à jour des informations sur un serveur distant. En fait, vous pouvez imaginez ce que vous voulez avec des scripts.
Lancer des tests ou des scripts pour valider un Git Commit
Vous devez vous rendre sur un projet versionné avec git et exécuter ces différentes lignes de commandes :
touch .git/hooks/pre-commit #création du fichier qui va accueillir les scripts chmod +x .git/hooks/pre-commit #permettre l’exécution du script nano .git/hooks/pre-commit #ajouter des commandes dans le fichier
Pour notre exemple, nous allons faire un simple echo pour afficher du texte lors d’un commit. Vous pourrez mettre ce que vous voulez après avoir testé ce processus.
Une fois votre modification sauvegardée, il vous suffit de faire un git commit pour vérifier si ça fonctionne.
Vous pouvez constater que lorsque j’ai effectué mon commit, le message pre-script s’est affiché. Ceci prouve donc que vous pouvez exécuter des tests avant le commit. Si votre programme de test rencontre des erreurs, le commit ne passera pas.
J’ai été un peu extrême sur mon test, en inscrivant une commande qui n’existe pas. Mais je voulais vous montrer que s’il y a la moindre erreur, le moindre problème, alors le développeur devra les corriger pour pouvoir pousser son code sur le serveur commun.
Ce qui conclut cet article ; Si vous êtes optimiser votre temps sur Git, l’article suivant est fait pour vous :
Astuces de Git n°2 : des commandes plus courtes avec git alias
