TP : Trunk-based development, commits conventionnels et versions

Ce que vous allez apprendre dans ce TP

• Travailler en branches courtes
• Automatiser une règle avec un hook
• Versionner et annuler

Introduction #

Ce que vous allez apprendre dans cette section

• Travailler en branches courtes
• Automatiser une règle avec un hook
• Versionner et annuler

Contexte. Votre équipe fusionne de longues branches une fois par mois et passe des jours à résoudre les conflits. Vous mettez en place un workflow trunk-based outillé.

Prérequis : Git 2.30 ou plus  ·  Durée estimée : 35 min

Un dépôt avec un historique lisible, deux versions publiées et un retour arrière.

Mise en place #

Étapes guidées, avec leur correction.

1. 1. Créer le dépôt

   Pourquoi ? main est la seule branche durable : elle doit toujours être livrable.

   Initialisez un dépôt avec une petite application et un premier commit sur main.

2. 2. Imposer les commits conventionnels

   Pourquoi ? Une règle vérifiée automatiquement ne dépend plus de la mémoire de chacun.

   Écrivez un hook commit-msg qui refuse les messages ne respectant pas type(portée): description, puis testez-le.

3. 3. Une branche courte et sa fusion

   Pourquoi ? Une branche de quelques heures se fusionne sans conflit et se relit facilement.

   Créez feat/remise, ajoutez une fonction de remise en deux petits commits, mettez la branche à jour avec rebase puis fusionnez-la (squash) dans main.

4. 4. Publier des versions

   Pourquoi ? Le versionnement sémantique dit aux utilisateurs ce qu'ils risquent en mettant à jour.

   Taguez v1.0.0, ajoutez un correctif conventionnel, déduisez le numéro suivant, taguez-le et générez la liste des changements entre les deux versions.

5. 5. Annuler sans réécrire l'historique

   Pourquoi ? Sur une branche partagée, on annule par un nouveau commit : personne ne perd son travail.

   Introduisez un commit fautif, retrouvez-le avec git bisect et annulez-le avec git revert.

Niveau de difficulté : ●●○○○ (2/5)