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#

develop/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.

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.
- Fusionné de nouveau dans develop une fois terminé.
- Supprimé après la fusion.
hotfix/xxx : Utilisé pour les corrections urgentes critiques pour la production.
- Créé à partir de main.
- Fusionné de nouveau dans 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).

Workflow pour les nouvelles fonctionnalités#

Créer une nouvelle branche de fonctionnalité à partir de develop :
```
git checkout develop
git checkout -b develop/feature_name
```
Développer la fonctionnalité et valider les modifications.
Fusionner la branche de fonctionnalité de nouveau dans develop :
```
git checkout develop
git merge --no-ff develop/feature_name
```
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#

Créer une branche de correction d’anomalie à partir de develop :
```
git checkout develop
git checkout -b fix/bug_description
```
Appliquer la correction et valider les modifications.
Fusionner la branche de correction de nouveau dans develop :
```
git checkout develop
git merge --no-ff fix/bug_description
```
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 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#

Créer une branche de correctif urgent à partir de main :
```
git checkout main
git checkout -b hotfix/critical_bug
```
Appliquer la correction et valider les modifications.
Fusionner le correctif de nouveau dans main :
```
git checkout main
git merge --no-ff hotfix/critical_bug
```
Faire un cherry-pick du correctif dans develop :
```
git checkout develop
git cherry-pick <commit_hash>
```
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.

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 d’anomalies dans main sont font toujours l’objet d’un cherry-pick dans develop.
Différencier clairement entre fix/xxx (correctifs non urgents) et hotfix/xxx (correctifs critiques pour la production).

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.

Il garantit également que les corrections d’anomalies sont correctement gérées et propagées entre les branches.