Git - Bonnes pratiques
Voici quelques temps que je travaille avec plusieurs développeurs dans mon équipe. Ils sont tous connectés sur un dépôt GIT (TFS ou VSTS) et ils me demandent régulièrement quand et comment créer un Pull Request efficacement.
Après plusieurs articles sur le sujet et plusieurs semaines d’utilisations, voici mes conclusions.
Règles du Commit
- Commiter le plus souvent possible.
- Au moins une fois par jour
- Veuillez vérifier que le code compile correctement.
- Commiter uniquement le code source.
- .cs, .ts, .xaml, .html, resources, ...
- Utiliser le fichier .gitignore pour vous aider
- Ne remonter par vos résultats de compilation, de paquets Nuget ou NPM
- Ecrire un commentaire clair et explicite.
- Rapide pour la relecture du code (Code Review)
- Pour aider à l'écriture des Release Notes
- Pour faciliter la maintenance ultérieure.
- Débuter votre commentaire par Fix, Add ou Change
- Utiliser des commentaires courts (maximum 80 caractères)
- Référencer les Work Items associés via le #
Branches
Dès que vous commencez à écrire une nouvelle fonctionnalités, créer une branche qui respecte les conventions claires :
- master contient le code correspondant à la version actuellement en production.
- develop contient le code commun à tous les développeurs.
- releases/[version] contient les codes de tous les déploiements déjà effectués.
- features/[feature-name]
- features/[feature-area]/[feature-name]
- users/[username]/[description]
- hotfix/[description]
Exemples: users/dvoituron/addhelpdocumentation, features/loginscreen, hotfix/statperformance
La branche 'develop'
Cette branche contient le code commun à tous les développeurs. Il est donc important que son contenu soit correct et que les autres développeurs puissent s’y retrouver facilement. Pour cela, nous fusionnerons le code en cours d’écriture, via le processus de Pull Request (voir ci-dessous).
Comme plusieurs développeurs mettent à jour régulièrement cette branche develop, il est intéressant d’être averti d’une mise à jour. VSTS permet de définir des notifications pour recevoir un email lorsqu’un développeur à modifier la branche ‘develop’. Dans ce cas, il est conseillé d’exécuter un rebase de ‘develop’ vers votre branche pour régler au plus tôt les conflits éventuels (et pour disposer rapidement des derniers changements).
Pull Request
Une fois que le code est correctement écrit dans sa branche, il est temps de créer un Pull Request qui sera vérifié et finalement validé pour être fusionné à la branche develop. Pour éviter des problèmes de conflits, il est conseillé de mettre à jour régulièrement sa branche de travail avec les nouveaux codes écrits dans ‘develop’ (voir ci-dessus).
Le processus de Pull Request est assez simple, et se fait principalement online :
- Fusionner (merge ou rebase) une dernière fois le code de develop vers votre branche, pour éviter des conflits.
- Compiler localement votre code et exécuter tous les tests unitaires.
- Initier le processus de Pull Request (via VSTS ou TFS) : cliquer sur le bouton [Pull Request] et choisissez de fusionner votre branche vers develop.
- Donner un titre précis au Pull Request. Il correspond à la fonctionnalité en cours de développement.
- Décrivez en détail le contenu de la demande. Cette zone Description et les références aux Work Items pourront être utilisée pour rédiger les Release Notes.
- Vérifier ou préciser des Code Reviewers.
- La requête est en attente, le temps que des Reviewers vérifient la qualité du code. Si nécessaire, ils peuvent ajouter des commentaires ou adapter le code et commiter le Pull Request qui sera alors mis à jour.
- Une fois le processus de revue terminé, le dernier Reviewer (ou le responsable) approuve le Pull Request :
- Fusionner en mode Squash pour compresser tous les commits en un seul commit dans 'develop'. Cela rend l'historique de 'develop' beaucoup plus lisible.
- Supprimer la branche de travail, devenue inutile. L'historique de travail et des commits sont conservés dans les Completed Pull Request.
Demo
Une démo de 5 minutes est disponible ici.