Gestion du GIT
Source : Confluence EasyWMS France
Dernière mise à jour : 27/02/2024 (v1)
1. Phase de Développement Initial
a. Création des branches de fonctionnalité (feature) ou de correction
| # |
Acteur |
Action |
| 1 |
Dev |
Utiliser Git Flow dans Sourcetree |
| 2 |
Dev |
Faire un "Start New Feature" au début de la tâche |
| 3 |
Dev |
Utiliser le même nom de branche que le "tag" de la tâche Jira |
| 4 |
Dev |
Corriger les retours (revue de code et test fonctionnel) dans une nouvelle "feature" avec le même nom |
| 5 |
Dev |
Terminer les tâches avec la commande "finish feature" avec l'option "rebase" |
2. Avant la mise en service
a. Merge de la branche develop dans master
| # |
Acteur |
Action |
| 1 |
CdP |
Merger la branche develop dans master |
| 2 |
CdP |
Supprimer la branche develop (évite qu'au retour on ait une branche develop plus du tout à jour) |
3. Après la mise en service (pendant l'hypercare et avant le passage en TLM)
a. Retour de mise en service
| # |
Acteur |
Action |
| 1 |
CdP |
Mettre à jour la branche master (récupérer les éventuels développements de la mise en service) |
| 2 |
Dev Principal |
Créer une nouvelle branche develop à partir de master s'il y a des développements à réaliser |
b. Pendant l'hypercare
| # |
Acteur |
Action |
| 1 |
Dev Principal |
Réaliser les développements "hypercare" sur la develop |
| 2 |
CdP |
Livrer la production depuis la branche develop (toujours livrer quand tous les développements sont terminés) |
| 3 |
CdP |
Merger develop dans master — si possible aussi merger master dans develop pour avoir les deux branches au même niveau |
c. Avant le passage en TLM
| # |
Acteur |
Action |
| 1 |
CdP |
Merger develop dans master (par sécurité) |
| 2 |
CdP |
Supprimer la branche develop après validation |
⛔ L'équipe support refusera le passage en TLM si le dépôt Git du projet contient encore une branche develop.
4. Pendant la TLM et la TMA
a. Branches de hotfix pour l'équipe de Support
Cas de modifications longues/conséquentes ou testées sur intégration d'abord :
| # |
Acteur |
Action |
| 1 |
Support |
Créer des branches de hotfix à partir de master |
| 2 |
Support |
Merger dans master à la livraison |
| 3 |
Support |
Prévenir l'équipe TMA qu'une livraison a eu lieu (pour mise à jour des branches release en cours) |
Cas de modifications directes en prod :
| # |
Acteur |
Action |
| 1 |
Support |
Exporter la production dans master |
| 2 |
Support |
Prévenir l'équipe TMA qu'une livraison a eu lieu |
b. Branches de release pour l'équipe de TMA
| # |
Acteur |
Action |
| 1 |
TMA |
Créer une nouvelle branche de release pour chaque offre complémentaire prévue |
| 2 |
TMA |
Les développeurs tirent des branches de feature depuis release pour chaque tâche Jira de l'offre |
| 3 |
TMA |
Merger master dans release à chaque annonce de livraison en production par le support |
| 4 |
TMA |
Intégrer les branches de feature dans release sur demande du chef d'équipe, après test et validation finale |
| 5 |
TMA |
Merger master dans release et effectuer une passe de tests généraux avant livraison de l'offre |
| 6 |
TMA |
Merger release dans master après livraison de l'offre |
| 7 |
TMA |
Prévenir l'équipe Support qu'une livraison a eu lieu (pour mise à jour des branches hotfix en cours) |
5. Visibilité et Communication
a. Communication entre les équipes
⚠️ Il est très important de bien communiquer sur les livraisons effectuées, tant entre les équipes de développement et les chefs de projet, qu'entre les équipes TMA et Support, afin de maintenir un Git à jour.
Arthur Ria