Git, les bonnes pratiques
Petit rappel de ce qu’est git. C’est un logiciel de gestion de versions décentralisées inventé en 2005 par Linus Torvalds (auteur du noyau Linux).
Très utilisé dans le développement informatique, il permet de gérer l’évolution de votre code dans une arborescence.
Maintenant, on va parler bonnes pratiques et choses à éviter. Une bonne utilisation de Git repose sur un petit nombre de pratiques à respecter pour éviter de s’énerver pour rien 😃
Que ce soit sur le moment ou quand tu reviendras sur d’anciens commits.
Créer de petits commits
La première règle est de ne pas garder un énorme tas de code non commit. Pourquoi ? La réponse est simple. Au bout d’un moment, tu ne sauras plus ce que tu as créé au début de ta fonctionnalité. De plus, si tu n’as rien poussé sur un hébergeur git distant, prie pour ne pas avoir de problème…
Pour faire simple, oublie tout ce qu’on a pu te dire, la taille ça compte.
Faire des petits commits t’aideras sur plusieurs points. Ceux-ci seront bien plus lisibles et compréhensibles. Ils contiendront peu de modifications.
Ça te facilitera aussi la tâche si tu veux revenir sur un point ou changer quelques fichiers. Ça sera plus simple que dans un immense commit.
Ça t’aideras notamment lors des merge ou pull request. En effet, tu auras moins de code à vérifier et donc moins de conflits potentiels à gérer.
Tu augmenteras ton nombre de commits et en même temps, tu augmenteras ta satisfaction personnelle 😛
C’est un remède contre la perte de cheveux et chaque commit fait naître un bébé licorne.
Des messages de commit clairs
Cette pratique te semble plutôt logique non ? Et pourtant, on trouve trop souvent des commits nommés (bug fix, big code update, …).
Avec ce genre de commits, tu te feras maudire par tes collègues.
Rentre toi bien ça dans le crâne ! Détaille ton message de commit. Décrit la fonctionnalité que tu as créé, le bug que tu as corrigé, etc.
Une chose que tu peux également mettre en place, ce sont de petits tags au début de ton message. Par exemple, j’utilise ceux-ci :
- [func] mon commentaire pour l’ajout d’une fonctionnalité
- [edit] pour la modification d’une fonctionnalité
- [del] pour la suppression d’une fonctionnalité ou fichier
- [fix] pour la correction d’un bug
- [refa] pour du refactor de code
- [misc] quand aucun des tags précédant ne correspond à la tâche
Cela te permettras, en un coup d’œil, de voir ce que contient le commit. Si tu utilises un gestionnaire de tâche (genre taskworld) tu peux ajouter l’identifiant de la tâche pour qu’un autre développeur comprenne plus facilement ton travail.
Par exemple :
[2512][edit] modification du formulaire de création d’utilisateur pour y ajouter son adresse.
Bien organiser ses branches
La première des grandes règles de git à noter, est qu’il ne faut jamais faire des commits en cours de développement sur master. Master c’est la production donc on ne touche pas cette branche.
Sur git, tu n’es pas obligé de n’avoir qu’une seule branche. Tu peux en avoir plusieurs en même temps. Il y a différentes méthodes d’organisation, la plus connue étant Git Flow.
Ce que tu retrouveras souvent, et je te le conseille, c’est d’avoir en plus de master une branche dev. C’est ta branche avec tous les commits en cours de développement et qui recevra des merges d’autres branches.
En plus de dev, l’idéal et de créer une branche par fonctionnalité. Une fois que cette fonctionnalité est opérationnelle, tu peux la fusionner dans la branche dev.
C’est en gros du git flow avec les normes de nommage en moins.
Une fois que dev atteint un certain niveau d’avancement, et que celle-ci est testée et stable, tu peux la merge sur master. Ensuite tu peux prévoir une mise en production.
Pour les bugs rencontrés en production, tu peux créer une branche à partir de master. Corriger le ou les bugs et ensuite merge le correctif sur master et dev pour qu’il soit corrigé sur les différents environnements.
Pour terminer
Garde toujours à l’esprit que git doit être ton meilleur ami. Il te permet de sauvegarder ton travail à un instant donné et de pouvoir le partager facilement avec tes collègues.
Si tu suis les différents conseils que je t’ai donné, normalement, tout devrait bien se passer pour toi avec git !
Et pour la route je t’en donne un dernier, ne pas utiliser la force tu dois !
Le git push — force est à proscrire sauf si tu sais vraiment ce que tu fais. C’est le meilleur moyen de se faire des ennemis en écrasant leur code par inadvertance.
Sur ces bonnes paroles, vas et push mais reste loin de la force 😉
