Workflow Git#

Ce document décrit le workflow Git utilisé dans le projet DataLab, basé sur une branche main, une branche develop et des branches spécifiques aux fonctionnalités. Il définit également comment les correctifs de bogues sont gérés.

Note

Ce workflow est une version simplifiée du Gitflow Workflow. Il a été adapté pour répondre aux besoins du projet DataLab à l’étape actuelle de développement. À l’avenir, nous pourrions envisager d’adopter un workflow plus complexe, par exemple en ajoutant des branches de publication.

Modèle de branches#

Branches principales#

  • main : Représente la version stable et prête pour la production du projet.

  • develop : Utilisé pour le développement continu et l’intégration de nouvelles fonctionnalités.

Branches de fonctionnalités#

  • feature/feature_name : Utilisé pour le développement de nouvelles fonctionnalités.

    • Créé à partir de develop.

    • Fusionné de nouveau dans develop une fois terminé.

    • Supprimé après la fusion.

Branche de maintenance#

  • release : Représente la ligne de maintenance actuelle pour les versions correctives.

    • Créé à partir de main après une version stable lorsque le premier correctif est nécessaire.

    • Accepte les fusions des branches fix/xxx et hotfix/xxx.

    • Fusionné de nouveau dans main pour chaque tag de version corrective (par exemple, 1.0.1, 1.0.2).

    • Réinitialisé ou recréé lors du démarrage d’un nouveau cycle de version mineure/majeure.

Note

La branche release n’est pas versionnée (pas de release/1.0.x). Elle représente toujours « la ligne de maintenance actuelle ». Lorsqu’une nouvelle version mineure est publiée (par exemple, 1.2.0), l’ancienne branche release est supprimée et une nouvelle est créée à partir du nouveau tag lorsque le premier correctif pour 1.2.1 est nécessaire.

Branches de correction d’anomalies#

  • fix/xxx : Utilisé pour les corrections générales d’anomalies qui ne sont pas urgentes.

    • Créé à partir de develop (pour la prochaine version de fonctionnalité) ou release (pour la version corrective).

    • Fusionné de nouveau dans la branche d’origine une fois terminé.

    • Supprimé après la fusion.

  • hotfix/xxx : Utilisé pour les corrections urgentes critiques pour la production.

    • Créé à partir de release (si elle existe) ou main (si aucune branche release n’existe encore).

    • Fusionné de nouveau dans release ou main.

    • La correction est ensuite sélectionnée dans develop.

    • Supprimé après la fusion.

Note

Les correctifs urgents (correctifs de haute priorité) seront intégrés dans la prochaine version de maintenance (X.Y.Z -> Z+1), tandis que les correctifs (correctifs de basse priorité) seront intégrés dans la prochaine version de fonctionnalité (X.Y -> Y+1).

Branches de documentation#

Lors de la rédaction de documentation qui n’est pas liée au code source (par exemple, les supports de formation, les guides utilisateur), les branches doivent être nommées en utilisant le préfixe doc/.

Exemples :

  • doc/training-materials

  • doc/user-guide

Cette convention de nommage améliore la clarté en séparant clairement les efforts de documentation du développement lié au code (fonctionnalités, corrections, etc.).

Workflow pour les nouvelles fonctionnalités#

  1. Créer une nouvelle branche de fonctionnalité à partir de develop :

    git checkout develop
git checkout -b develop/feature_name

  2. Développer la fonctionnalité et valider les modifications.

  3. Fusionner la branche de fonctionnalité de nouveau dans develop :

    git checkout develop
git merge --no-ff develop/feature_name

  4. Supprimer la branche de fonctionnalité :

    git branch -d develop/feature_name

Avertissement

Ne pas laisser les branches de fonctionnalités non fusionnées trop longtemps. Les réorganiser régulièrement sur develop pour minimiser les conflits.

Workflow pour les corrections d’anomalies régulières#

Pour la prochaine version de fonctionnalité (cible : develop) :

  1. Créer une branche de correction d’anomalie à partir de develop :

    git checkout develop
git checkout -b fix/bug_description

  2. Appliquer la correction et valider les modifications.

  3. Fusionner la branche de correction de nouveau dans develop :

    git checkout develop
git merge --no-ff fix/bug_description

  4. Supprimer la branche de correction :

    git branch -d fix/bug_description

Pour la version de maintenance actuelle (cible : release) :

  1. Créer une branche de correction d’anomalie à partir de release :

    git checkout release
git checkout -b fix/bug_description

  2. Appliquer la correction et valider les modifications.

  3. Fusionner la branche de correction de nouveau dans release :

    git checkout release
git merge --no-ff fix/bug_description

  4. Supprimer la branche de correction :

    git branch -d fix/bug_description

Avertissement

Ne pas créer une branche fix/xxx à partir d’une branche develop/feature_name. Toujours créer une branche à partir de develop ou release pour garantir que les corrections sont correctement propagées.

# Incorrect:
git checkout develop/feature_name
git checkout -b fix/wrong_branch

# Correct:
git checkout develop
git checkout -b fix/correct_branch

Workflow pour les correctifs urgents#

  1. Créer une branche de correctif urgent à partir de release (ou main si aucune branche release n’existe) :

    git checkout release  # or: git checkout main
git checkout -b hotfix/critical_bug

  2. Appliquer la correction et valider les modifications.

  3. Fusionner la correction de nouveau dans release (ou main) :

    git checkout release  # or: git checkout main
git merge --no-ff hotfix/critical_bug

  4. Faire un cherry-pick du correctif dans develop :

    git checkout develop
git cherry-pick <commit_hash>

  5. Supprimer la branche de correctif urgent :

    git branch -d hotfix/critical_bug

Avertissement

Ne pas fusionner fix/xxx ou hotfix/xxx directement dans main sans suivre le workflow. Assurez-vous que les correctifs urgents ont fait l’objet de cherry-pick dans develop pour éviter de perdre des correctifs dans les futures versions.

Workflow pour les versions correctives#

Dès qu’une version corrective est prête à être publiée (par exemple, 1.0.1, 1.0.2) :

  1. S’assurer que la branche release contient toutes les corrections souhaitées.

  2. Fusionner release dans main :

    git checkout main
git merge --no-ff release

  3. Taguer la version sur main :

    git tag -a v1.0.1 -m "Release version 1.0.1"
git push origin main --tags

  4. Conserver la branche release pour des correctifs supplémentaires dans la même série de versions mineures.

Workflow pour les versions mineures/majeures#

Dès qu’une nouvelle version mineure ou majeure est prête à être publiée (par exemple, 1.1.0, 2.0.0) :

  1. Fusionner develop dans main :

    git checkout main
git merge --no-ff develop

  2. Taguer la version sur main :

    git tag -a v1.1.0 -m "Release version 1.1.0"
git push origin main --tags

  3. Supprimer l’ancienne branche release (si elle existe) :

    git branch -d release
git push origin --delete release

  4. Créer une nouvelle branche release à partir de main lorsque le premier correctif pour 1.1.1 est nécessaire :

    git checkout main
git checkout -b release
git push -u origin release

Bonnes pratiques#

  • Réorganiser régulièrement les branches de fonctionnalités sur develop pour rester à jour :

    git checkout develop/feature_name
git rebase develop

  • Éviter les branches de longue durée pour minimiser les conflits de fusion.

  • S’assurer que les corrections de bogues dans release ou main sont toujours sélectionnées dans develop.

  • Différencier clairement entre fix/xxx (correctifs non urgents) et hotfix/xxx (correctifs critiques pour la production).

  • Lors de la création de la branche release, mettre à jour les notes de version pour indiquer la version qu’elle cible (par exemple, ajouter un commentaire dans le commit de fusion : « Créer une branche de maintenance pour v1.0.x »).

  • La branche release représente toujours la ligne de maintenance actuelle. Pour savoir quelle version elle cible, vérifiez le tag le plus récent sur main ou les notes de version.

Conclusion#

Ce workflow garantit un processus de développement structuré mais flexible tout en maintenant main stable et develop toujours à jour avec les dernières modifications.

La branche release fournit une ligne de maintenance dédiée pour les versions correctives, permettant à develop de poursuivre avec de nouvelles fonctionnalités sans interférence. Cela résout le problème de la coordination des modifications non publiées à travers l’écosystème PlotPyStack (DataLab, Sigima, PlotPy, guidata, PythonQwt) en fournissant une branche stable pour les tests CI pendant les cycles de maintenance.