# Gestion du GIT

> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000400216098/Gestion+du+GIT)  
> 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.