Utilisation de Git

Pour mener à bien vos projets il est essentiel de bien utiliser les outils de gestion de version. Au ResEl nous utilisons git il a de nombreux avantages, mais ceux que nous allons retenir sont qu'il est Libre et très utilisé.

Vous trouverez des guides complets pour utiliser Git sur internet et une introduction dans les cours ResEl. Cependant pour 80% du travail vous n'avez qu'à connaitre les commandes suivantes : 

git clone
git status
git add
git commit
git push

Le bonnes pratiques Git

Simplement maitriser git n'est pas suffisant, c'est pourquoi vous devez aussi savoir bien utiliser l'outil, voici quelques conseils :

1: Les messages de commit doivent refléter l'intention

Vous devez toujours dire non seulement ce que vous avez fait, mais aussi pourquoi vous l'avez fait. C'est encore mieux si vous pouvez expliquez pourquoi vous avez fait ça plutôt qu'autre chose.

2: Utiliser des branches pour l'ajout de fonctionnalités, jamais aucun commit sur la branche master !

Avec Git, il faut créer une branche pour n'importe quel chose sur laquelle vous travaillez, pour qu'au final vous finissiez avec une revue de code avant de merger.

3: Tester tout les commits, pas seulement ceux sur master.

Certaines personnes configure l'intégration continue uniquement pour les commits mergés sur master. C'est trop tard pour un test ! Il faut voir uniquement des tets réussis sur master. Ça n'a aucun sens d'attendre de réussir les tests sur master avant de commencer à développer de nouvelles fonctionnalités par exemple. L'IC n'est pas compliquée à mettre en place, c'est donc la meilleur manière de faire.

4: Faites tourner les tests sur tout les commit (si vos tests durent plus que 5 minutes, faites les tourner en parallèle.

Si vous travaillez sur une branche feature et que vous ajoutez de nouveaux commits, faites tournez les tests. S'ils sont trop longs, essayez de les lancer en parallèle. Faites le du côté serveur dans les merges requests, en lançant la suite de tests complètes.

5: Faites de la revue de code AVANT de merger dans master, jamais après.

Ne testez pas tout à la fin de votre semaine. Faites le sur le moment, vous serez plus à même d'attraper des choses qui pourront posez des problèmes, et d'autres pourront alors travaillez sur une solution.

6: Les déploiements sont automatiques, basés sur des branches ou tags.

Si vous ne voulez pas déployez master à chaque fois, vous pouvez créer une branche de production; il n'y a aucune raison pour ne pas faire un script pour cela. Automatisez tout, selon une branche ou un tag qui active un déploiement en production.

7: Les tags sont choisis par les utilisateurs, pas par l'IC

Un utilisateur choisis un tag et, basé sur ça, l'IC fera l'action. Pas l'inverse. Il ne faut pas que l'IC modifie le dépôt. Si vous avez besoin de métriques détaillées, vous devez avoir un serveur de rapport qui détaille chaque nouvelle versions.

8: Les releases sont basées sur des tags.

Si vous taggez quelquechose, ça doit créer une nouvelle release.

9: Les commits pushés ne doivent jamais être rebasés.

Si vous pusher sur une branche public, vous ne devez pas rebase ! Cela rendra la revue de code très difficile, les résultats des tests obscurs, et ça casser les cherrypicking. Parfois on peut faire exception à la règle pour demander à un contributeur de squasher et rebase à la fin du process de revue de code pour avoir quelquechose de plus facile à revert. Mais, en général, le code doit être propre, l'historique doit être réaliste.

10: Tout le monde commence depuis master, et cible master.

Vous ne devez pas avoir de branche trop longues. Vous récuperez master, construisez votre feature, créez votre merge request et ciblez master. Vous devez faire une revue complète de votre code avant merge, et ne pas créer d'étapes intermédiaires.

11: Résoudre les bugs de master d'abord, puis des branches de releases ensuite.

Si vous trouvez un bug, la pire chose à faire est de le fixer dans la version tout juste sortie, et d'oubliez de le faire dans master. Pour éviter ça, vous devez toujours corriger le bug sur master, puis cherry-picker dans un branche re patch-release.

Ressources utiles