Le dossier

• Partie 1 : Interpréteur et dépendances
• Partie 2 : Environnements et configuration
• Partie 3 : Code styling
• Partie 4 : Code linting
• Partie 5 : Tests unitaires
• Partie 6 : Fixtures et Mocks
• Partie 7 : Factories
• Partie 8 : Debugging
• Partie 9 : Versionning

Rappel du contexte

Cet article fait partie d'une série d'articles visant à énumérer les différents éléments de qualité à mettre en place au démarrage d'un projet.

Introduction

Dans le monde du développement de logiciels, le versionning est un élément essentiel pour gérer les différentes versions et le cycle de vie d'un projet. Il s'agit d'un logiciel qui permet de garder une trace des modifications apportées à un code source, de travailler en équipe sur un même projet, de revenir à une version antérieure en cas de besoin, et bien plus encore.

Git est certainement devenu le logiciel de versionning le plus populaire, il est utilisé par la plupart des équipes et développeurs individuels. Dans cet article, je vais expliquer pourquoi utiliser Git, ce qu'est une stratégie de gestion de branche, et quelles sont les stratégies de versionning les plus populaires.

Pourquoi utiliser un logiciel de versionning

Si vous interrogez des développeurs suffisamment anciens, ils vous parleront peut-être de l'époque où on se partageait le code par FTP, et où on détaillait les modifications dans l'en-tête du fichier, en ajoutant une date et un commentaire.

/****************************
 * Index.php - Intraner de la société
 *
 * 12/04/2004 - Création de l'intranet - jean.roger@super-entreprise-2000.tld
 * 27/06/2004 - Ajout de l'authentification - jean.roger@super-entreprise-2000.tld
 * 28/06/2004 - Correction du mot de passe - jean.roger@super-entreprise-2000.tld
 * 09/01/2006 - Correction des bugs - bugs.bunny@super-entreprise-2000.tld
 ****************************/

J'ai connu ce genre de système. Il posait plusieurs problèmes :

• On pouvait très facilement oublier de noter les modifications qu'on avait effectué. L'historique n'était pas très sûr.
• On n'a pas le détail de ce qui a été changé, à quel moment. Impossible de revenir en arrière
• Deux personnes pouvaient travailler en même temps sur le même fichier. La seconde personne à enregistrer le fichier écrasait alors les modifications de la première.

C'est pour répondre à tout ces problèmes qu'on a inventé les logiciels de gestion de versions, et que ces logiciels sont devenus très populaires. Chaque modification sur le code est historisée dans ce qu'on appelle un commit. Un commit est un ensemble de modifications sur un ou plusieurs fichiers. On enregistre donc tout l'historique de modification des fichiers, et les logiciels sont capables de gérer le fait que deux personnes aient fait des modifications sur le même fichier le même jour (on appelle ça un conflit).
Cet historique est essentiel pour comprendre les changements et pour suivre l'évolution d'un projet. Cela permet gérer et de livrer des versions précises, éventuellement de faire des retours en arrière, de ne rien perdre.

Avec Git, vous allez pouvoir retrouver l'ensemble de vos modifications en une seule commande :

$ git log

commit f6b82ce18a97ba50d5c1ecf82d47faa8d54d3421 (HEAD -> master)
Author: John Doe 
Date: Sun Mar 27 14:00:12 2023 -0400

    Ajout de la fonctionnalité de recherche par catégorie de produits

commit e9a1036840c031a482aaf31c46340d327e0a8a0f
Author: Jane Smith 
Date: Sat Mar 26 10:23:57 2023 -0400

    Correction du bug d'affichage sur la page panier

commit 8908a147f2ce68e30306f04a68c8af3f6d26decc
Author: Mark Johnson 
Date: Fri Mar 25 19:13:08 2023 -0400

    Ajout de la fonctionnalité de paiement en ligne

Encore une fois, il n'est pas question ici d'un guide d'utilisation avancé de Git. En voilà un.

Pourquoi adopter une stratégie de gestion de branche

Une branche est une ligne de développement indépendante qui permet de travailler sur une fonctionnalité, une tâche ou une correction de bug spécifique sans affecter la branche principale du projet. C'est l'une des principales fonctionnalité offerte par Git, bien que l'ont puisse totalement s'en passer.

On peut s'appuyer sur les branches pour préparer des nouvelles fonctionnalités d'un côté, tout en maintenant la version en production de l'autre (pour corriger les bugs en production sans attendre par exemple). La gestion de branche peut également faciliter la collaboration entre les membres de l'équipe, en permettant à plusieurs développeurs de travailler sur des fonctionnalités différentes en même temps.

Quelles sont les stratégies les plus populaires

Il existe de nombreuses stratégies de versionning qui peuvent être utilisées avec Git. Voici quelques-unes des plus populaires :

• Le modèle Git Flow : souvent décriée, toujours ma préférée, cette stratégie est basée sur le principe suivant : une fonctionnalité, une branche. Les fonctionnalités alimentent la branche de développement, qui contient le code de la future version, pendant que le code de production est sur la branche de production, de façon à pouvoir créer des branches de correction de bug.
• GitHub Flow : présenté comme un workflow léger. Tout part de la branche master. On merge dans master quand c'est prêt. C'est idéal si on maintient une seule version de son logiciel.
• La stratégie GitLab Flow : cette stratégie est basée sur le modèle Git Flow, mais avec quelques améliorations. Elle propose notamment de supprimer la branche de développement et de travailler directement sur la branche principale du projet. Elle permet également de limiter les branches de fonctionnalités à une seule branche par développeur, afin de faciliter la gestion des conflits et de simplifier le processus de fusion. Cela en fait une stratégie idéale pour les projets avec de nombreux contributeurs.

Quelques bonnes pratiques

• Réécrivez votre historique : 1 commit doit correspondre à un incrément produit, potentiellement livrable. Pensez à utiliser --amend
• Utilisez le rebasage plutôt que le merge : évitez les commits de merge qui polluent l'historique
• Écrivez des messages de commit clairs et informatifs, qui expliquent les modifications apportées et leur objectif. Évitez les messages vagues ou génériques comme "correction de bugs" ou "mise à jour du code". Ou "no message" 😉
• Évitez d'utiliser des noms de branches génériques comme "dev" ou "feature". Utilisez des noms spécifiques et descriptifs pour chaque branche, qui indiquent clairement son objectif ou sa fonctionnalité.
• Utilisez git diff pour visualiser vos modifications avant de commiter.

Conclusion

Git est un outil incontournable, utilisez le dès le début de votre projet. Même seul, il vous permettra d'avoir une meilleure vision de vos ajouts dans votre projet.

La prochaine fois, nous parlerons des hooks de pre-commit. J'ai hâte. Ca va être marrant.