Workflows Git, issues et Conventional Commits

Un workflow Git est l'organisation des branches qu'une équipe adopte pour travailler ensemble : GitHub Flow (une branche par sujet, fusionnée dans main par pull request), Git Flow (des branches develop, release et hotfix en plus de main) ou le développement sur tronc commun. Ce chapitre compare ces trois modèles et dit lequel choisir pour un projet de BTS. Il présente aussi la convention Conventional Commits pour les messages, et le suivi des tâches avec les issues et les tableaux GitHub Projects, ce « suivi des problèmes » que demande le référentiel.

GitHub Flow : le modèle simple

C'est le modèle du chapitre précédent :

• main est toujours stable et déployable ;
• chaque sujet (fonctionnalité, correction, documentation) part de main dans une branche courte ;
• la branche revient dans main par une pull request relue et testée ;
• après la fusion, on déploie et on supprime la branche.

Il tient en une phrase, convient aux applications Web qu'on déploie souvent, et c'est celui que suivent la plupart des projets hébergés sur GitHub. Pour un projet de BTS à deux, trois ou quatre, c'est le bon choix.

Git Flow : des versions planifiées

Git Flow, proposé en 2010 par Vincent Driessen, organise le travail autour de versions numérotées qu'on livre à des dates précises. Il utilise deux branches permanentes et trois sortes de branches temporaires.

Git Flow est adapté aux logiciels qui ont des versions installées chez les clients et plusieurs versions à maintenir en même temps : un logiciel de caisse, une application de bureau, un micrologiciel. Pour une application Web déployée plusieurs fois par semaine, il ajoute de la cérémonie sans bénéfice : son auteur lui-même conseille désormais un modèle plus simple dans ce cas. Si un sujet ou une entreprise te parle de develop et de release, c'est de Git Flow qu'il s'agit.

Le développement sur tronc commun

Dans le trunk-based development, tout le monde intègre son travail dans main (le tronc) au moins une fois par jour, directement ou par des branches qui vivent quelques heures. Les fonctionnalités inachevées sont livrées mais masquées par des interrupteurs dans le code (feature flags). Ce modèle suppose une batterie de tests automatiques solide et une équipe expérimentée : c'est celui des grandes entreprises qui déploient des dizaines de fois par jour.

Quel workflow choisir ?

Le pire workflow est celui que personne n'a choisi. Écris le vôtre en quelques lignes dans le README ou dans un fichier CONTRIBUTING.md : nommage des branches, format des messages, nombre d'approbations, méthode de fusion.

Des messages normalisés avec Conventional Commits

Conventional Commits est une convention d'écriture des messages de commit, adoptée par de nombreux projets libres et entreprises. Le titre suit le format :

type(portée): description

La portée, facultative, précise la partie du projet : api, front, auth, export. La description commence par un verbe, sans point final. Exemples sur Sorbier Frais :

feat(export): ajoute l'export CSV des notes validées
fix(api): corrige le filtre par mois qui oubliait le dernier jour
docs: documente les variables d'environnement dans le README
test(notes): couvre le refus d'une note sans justificatif
refactor(indemnites): extrait le calcul kilométrique dans un service
ci: lance les tests sur Node.js 24

Un changement qui casse la compatibilité (une route d'API supprimée, un format de réponse modifié) se signale par un ! après le type, ou par un pied de message BREAKING CHANGE: :

feat(api)!: renvoie les montants en centimes

BREAKING CHANGE: le champ montant est désormais un entier en centimes.
Les clients doivent diviser par 100 pour afficher des euros.

Pourquoi s'y astreindre ? L'historique se lit d'un coup d'œil (git log --oneline --grep="^fix" liste les corrections), le relecteur repère un feat glissé dans une pull request censée ne contenir que des corrections, et des outils lisent ces préfixes pour calculer le prochain numéro de version et rédiger le CHANGELOG : un fix donne une version corrective, un feat une version mineure, un BREAKING CHANGE une version majeure (versionnage sémantique).

Les issues : le suivi des problèmes

Une issue (un ticket) décrit un travail à faire : un bug, une demande d'évolution, une tâche technique. Sur GitHub, l'onglet Issues du dépôt les rassemble. Chaque issue a un numéro (#12), un titre, une description, des commentaires, des étiquettes, une ou plusieurs personnes assignées et éventuellement un jalon (milestone, par exemple « Version 1.1 »).

Pour un bug, une bonne issue permet de le reproduire sans poser de question :

**Contexte** : liste des notes, filtre « Octobre 2026 », compte salarie1.

**Étapes pour reproduire**
1. Créer une note datée du 31/10/2026 à 18:00
2. Filtrer la liste sur octobre 2026

**Résultat attendu** : la note apparaît.
**Résultat obtenu** : la note n'apparaît pas. Elle apparaît si on ne filtre pas.

**Environnement** : version 1.0.2, Firefox sous Windows 11, serveur de recette.

Les modèles d'issues (issue templates), rangés dans .github/ISSUE_TEMPLATE/, préremplissent ce plan pour chaque nouveau signalement : un modèle « Bug » et un modèle « Demande d'évolution » suffisent.

Les issues se relient au code :

C'est exactement ce que le référentiel du BTS SIO appelle un « logiciel de gestion de versions et de suivi des problèmes » : un bug signalé, une issue, une branche, une pull request qui la ferme, une version qui la livre. À l'E6, cette chaîne prouve la sous-compétence « Recueillir, analyser et mettre à jour les informations sur une version d'une solution applicative » (les compétences de l'E6).

GitHub Projects : le tableau de l'équipe

GitHub Projects affiche les issues et les pull requests sous forme de tableau (colonnes Todo, In Progress, Done, à la manière d'un tableau Kanban), de liste ou de planning. Tu ajoutes des champs personnalisés : priorité, estimation, itération (sprint) de deux semaines. Les cartes changent de colonne automatiquement quand une issue est fermée ou une pull request fusionnée.

Pour une équipe de BTS, un tableau à trois colonnes, des issues assignées et un jalon par version suffisent. Ce tableau est une trace de la compétence « Travailler en mode projet » du bloc 1 : planification, répartition des tâches, suivi de l'avancement. Fais une capture du tableau à chaque fin d'itération pour ton portfolio (portfolio de l'E5).

Exercices