Fusion, Tag et Release : Suivre ce qui part en production

Vous venez de terminer la revue d'une pull request. Le code est bon, les tests passent, et votre collègue a approuvé les modifications. Et maintenant ?

La plupart des équipes savent qu'il faut fusionner les changements dans la branche principale. Mais la manière dont vous fusionnez, les traces que vous laissez, et la façon dont vous marquez ce qui est en production déterminent si votre équipe pourra répondre à une question simple six mois plus tard : "Quel code était réellement déployé à cette date ?"

Le Merge Commit est votre piste papier

Il existe plusieurs façons de combiner les changements d'une branche de fonctionnalité dans votre branche principale. L'approche la plus courante consiste à créer un merge commit.

Un merge commit fait plus que simplement déplacer du code. Il enregistre deux informations : la branche d'où viennent les changements et la branche dans laquelle ils sont intégrés. Cela crée une entrée claire dans votre historique de commits qui dit : "Quelque chose a été fusionné ici."

Comparez cela avec un fast-forward merge, où Git déplace simplement le pointeur vers l'avant sans créer de nouveau commit. Les fast-forward merges gardent un historique linéaire, mais ils perdent le contexte qu'une fusion a eu lieu. Si vous devez plus tard tracer un bug jusqu'à sa source, un merge commit vous donne un lien direct vers la discussion de la pull request, les commentaires de revue, et les changements exacts qui ont été rassemblés.

Quand vous utilisez des merge commits, votre git log raconte une histoire. Vous pouvez voir que feature-x a été fusionnée dans main mardi, et feature-y mercredi. Si quelque chose casse jeudi, vous savez exactement quelle fusion investiguer en premier.

Le diagramme suivant montre comment chaque étape se connecte pour créer une piste papier claire :

Voici la séquence exacte de commandes à suivre après l'approbation d'une pull request :

# 1. Fusionner avec un merge commit non fast-forward
git checkout main
git merge --no-ff feature-x -m "Fusion de feature-x dans main"

# 2. Tagger la release sur le commit de fusion
git tag -a v1.2.3 -m "Release v1.2.3"

# 3. Pousser main et le nouveau tag vers le dépôt distant
git push origin main --tags

# 4. Supprimer la branche de fonctionnalité localement et à distance
git branch -d feature-x
git push origin --delete feature-x

Nettoyer après la fusion

Une fois la fusion terminée, la branche de fonctionnalité a rempli son rôle. La supprimer garde votre dépôt propre et évite que les anciennes branches n'encombrent la liste quand quelqu'un doit en créer une nouvelle.

Certaines équipes suppriment les branches immédiatement après la fusion. D'autres attendent que la nouvelle version tourne en production depuis un jour ou deux, au cas où elles auraient besoin de créer une branche de correctif depuis le même point. Les deux approches fonctionnent, tant que vous avez une pratique cohérente.

Avant de supprimer, assurez-vous que tous les changements de cette branche sont bien dans la branche principale. Un petit contrôle : si la branche a été fusionnée via pull request, la plupart des plateformes d'hébergement Git l'affichent comme "fusionnée" et permettent une suppression en un clic.

Tags : donner des noms aux versions

Votre branche principale contient maintenant le dernier code. Mais comment savoir exactement quel commit tourne en production en ce moment ? La branche principale continue d'avancer au fur et à mesure que de nouveaux changements arrivent. Sans point de référence fixe, vous devinez.

C'est là que les tags entrent en jeu. Un tag est une étiquette attachée à un commit spécifique. Contrairement aux branches, les tags ne bougent pas. Une fois que vous créez un tag, il pointe vers ce commit exact pour toujours.

Les équipes créent généralement des tags lorsqu'elles publient une nouvelle version. Par exemple, après la fin des tests et quand l'équipe est prête à déployer en production, elle crée un tag comme v1.2.0 sur le dernier commit de la branche principale. Ce tag devient une référence permanente. Six mois plus tard, si quelqu'un demande quel code tournait à cette date, vous vérifiez le tag.

Nommer vos tags de manière cohérente

Les noms de tags doivent suivre une convention que toute l'équipe comprend. Le versionnage sémantique est un choix populaire : v1.2.3 où :

• Le premier nombre change pour les versions majeures qui cassent la rétrocompatibilité
• Le deuxième nombre change pour les nouvelles fonctionnalités
• Le troisième nombre change pour les corrections de bugs et les petites améliorations

Mais le versionnage sémantique n'est pas la seule option. Certaines équipes utilisent des dates : release-2024-11-15. D'autres utilisent des numéros de build : build-142. L'important est la cohérence. Choisissez un format, documentez-le, et utilisez-le pour chaque release.

Quel que soit le format choisi, assurez-vous que le tag est créé à partir du commit exact qui a été déployé. Si vous taguez un commit différent, le tag perd sa valeur en tant que point de référence fiable.

Notes de version : ce qui a changé et pourquoi

Après avoir créé un tag, la plupart des équipes rédigent des notes de version. Une note de version est un court résumé de ce qui a changé dans cette version. Elle n'a pas besoin d'être longue ou détaillée. Elle doit juste répondre à la question : "Dois-je me soucier de cette release ?"

Les bonnes notes de version incluent :

• Les nouvelles fonctionnalités que les utilisateurs remarqueront
• Les corrections de bugs qui résolvent des problèmes connus
• Les changements cassants qui nécessitent une action des autres équipes ou utilisateurs
• Les problèmes connus ou limitations de cette version

Les notes de version n'ont pas besoin d'être écrites de zéro. De nombreuses équipes les génèrent à partir des titres de pull request ou des messages de commit entre le dernier tag et le tag actuel. Une rapide relecture pour supprimer les détails techniques et ajouter du contexte orienté utilisateur est généralement suffisante.

Le pont entre le développement et la production

La fusion et le tag forment le pont entre l'écriture du code et son exécution en production. La fusion garantit que les changements revus entrent dans la base de code partagée. Le tag garantit que vous pouvez pointer vers un commit spécifique et dire : "C'est la version qui tourne en ce moment."

Sans tags, vous avez un long historique de commits et aucun moyen de savoir quels commits ont réellement été publiés. Vous finissez par deviner, vérifier les logs de déploiement, ou demander à des collègues qui ne se souviennent peut-être pas. Les tags éliminent cette incertitude.

Liste de contrôle pratique

Avant votre prochaine release, parcourez ces étapes :

• Fusionnez la pull request avec un merge commit, pas en fast-forward
• Supprimez la branche de fonctionnalité après avoir confirmé la fusion
• Créez un tag sur le commit exact qui sera déployé
• Rédigez des notes de version couvrant ce qui a changé et pourquoi c'est important
• Confirmez que le tag est poussé vers le dépôt distant pour que toute l'équipe puisse le voir

Ce que cela signifie pour votre équipe

La prochaine fois que vous fusionnerez une pull request, pensez à ce que vous laissez derrière vous. Un merge commit et un tag sont de petites actions, mais elles créent un historique dont votre futur moi vous remerciera. Quand quelque chose tourne mal à 2 heures du matin et que vous devez savoir ce qui a changé, vous n'aurez pas à deviner. Vous aurez une piste claire depuis le problème de production jusqu'au commit de fusion, à la pull request, et à la discussion qui a mené au changement.