Arthur Ria
99 lines
4.1 KiB
Markdown
99 lines
4.1 KiB
Markdown
# 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.
|