Arthur Ria
158 lines
8.2 KiB
Markdown
158 lines
8.2 KiB
Markdown
---
|
|
title: "Git Branch Lifecycle (Project Phases)"
|
|
type: operation
|
|
sources:
|
|
- sources/archives/Gestion_du_GIT.md
|
|
related:
|
|
- operations/development-methodology.md
|
|
- operations/git-workflow.md
|
|
- operations/deploy-test-application.md
|
|
last_compiled: "2026-04-17"
|
|
---
|
|
|
|
# Git Branch Lifecycle (Project Phases)
|
|
|
|
## Overview
|
|
|
|
Stratégie de gestion **par phase de projet** des branches Git pour les projets EasyWMS France : qui fait quoi, à quel moment, sur quelle branche. Cette page complète :
|
|
|
|
- [development-methodology](development-methodology.md) — vue d'ensemble (master / développement / post-production)
|
|
- [git-workflow](git-workflow.md) — procédure opérationnelle Git Flow (CLI / SourceTree)
|
|
|
|
…en explicitant les **règles de gouvernance** entre les acteurs (Dev, CdP, Support, TMA) au fil du cycle de vie : **Développement → Mise en service (MEP) → Hypercare → TLM (Tierce Maintenance) → TMA (Tierce Maintenance Applicative)**.
|
|
|
|
Source : Confluence EasyWMS France — *Gestion du GIT* (v1, 27/02/2024).
|
|
|
|
## Acteurs
|
|
|
|
| Acteur | Rôle |
|
|
|---|---|
|
|
| **Dev** | Développeur custom app (réalise les `feature` Jira) |
|
|
| **Dev Principal** | Référent technique du projet (gère la branche `develop` après MEP) |
|
|
| **CdP** | Chef de Projet (responsable des merges de mise en service et de la branche `master`) |
|
|
| **Support** | Équipe de support post-MEP (`hotfix` urgents) |
|
|
| **TMA** | Équipe de Tierce Maintenance Applicative (offres complémentaires sur `release`) |
|
|
|
|
## 1. Phase de développement initial
|
|
|
|
### Création des branches `feature` (et de correction)
|
|
|
|
Outil : **Git Flow dans Sourcetree**.
|
|
|
|
| # | 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 chaque tâche avec **"Finish Feature"** + option **"Rebase"** |
|
|
|
|
> Détail technique des commandes (`git flow init -d` / `git flow feature start` / `git flow feature finish -r`) → cf. [git-workflow](git-workflow.md).
|
|
|
|
> Convention de nommage du tag : `<TRIGRAMME_PROJET>-V<NUMERO>` (ex : `LMD-V1`). Voir aussi [deploy-test-application](deploy-test-application.md) où le tag est créé sur le commit `develop` à livrer en test.
|
|
|
|
## 2. Avant la mise en service (MEP)
|
|
|
|
### Merge `develop` → `master`
|
|
|
|
| # | Acteur | Action |
|
|
|---|---|---|
|
|
| 1 | CdP | **Merger `develop` dans `master`** |
|
|
| 2 | CdP | **Supprimer la branche `develop`** |
|
|
|
|
> ⚠️ Pourquoi supprimer `develop` ? Pour **éviter qu'au retour** (post-MEP) on retombe sur une branche `develop` plus du tout à jour vis-à-vis de la production. Une nouvelle `develop` sera recréée à partir de `master` si nécessaire (cf. section 3).
|
|
|
|
## 3. Après la MEP (pendant l'hypercare, 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 faits **pendant** la MEP) |
|
|
| 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 `develop` |
|
|
| 2 | CdP | **Livrer la production** depuis `develop` *(toujours quand tous les développements sont terminés, jamais en cours)* |
|
|
| 3 | CdP | Merger `develop` → `master` ; **si possible aussi merger `master` → `develop`** pour aligner les deux branches |
|
|
|
|
### c. Avant le passage en TLM
|
|
|
|
| # | Acteur | Action |
|
|
|---|---|---|
|
|
| 1 | CdP | Merger `develop` → `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`.** C'est le critère bloquant numéro 1 lors du transfert au Support.
|
|
|
|
## 4. Pendant la TLM et la TMA
|
|
|
|
### a. Branches `hotfix` — équipe Support
|
|
|
|
**Cas 1 — Modifications longues / conséquentes ou testées sur intégration d'abord :**
|
|
|
|
| # | Acteur | Action |
|
|
|---|---|---|
|
|
| 1 | Support | Créer une branche `hotfix` à partir de `master` |
|
|
| 2 | Support | Merger `hotfix` → `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 2 — Modifications directes en production :**
|
|
|
|
| # | Acteur | Action |
|
|
|---|---|---|
|
|
| 1 | Support | **Exporter la production dans `master`** |
|
|
| 2 | Support | **Prévenir l'équipe TMA** qu'une livraison a eu lieu |
|
|
|
|
### b. Branches `release` — équipe TMA
|
|
|
|
| # | Acteur | Action |
|
|
|---|---|---|
|
|
| 1 | TMA | Créer une **nouvelle branche `release`** pour chaque offre complémentaire prévue |
|
|
| 2 | TMA | Les développeurs tirent des `feature` **depuis `release`** pour chaque tâche Jira de l'offre |
|
|
| 3 | TMA | **Merger `master` → `release`** à chaque annonce de livraison Support |
|
|
| 4 | TMA | Intégrer les `feature` dans `release` sur demande du chef d'équipe, après test et validation finale |
|
|
| 5 | TMA | **Merger `master` → `release`** + passe de tests généraux **avant livraison de l'offre** |
|
|
| 6 | TMA | **Merger `release` → `master`** après livraison de l'offre |
|
|
| 7 | TMA | **Prévenir l'équipe Support** qu'une livraison a eu lieu *(pour mise à jour des `hotfix` en cours)* |
|
|
|
|
## 5. Visibilité et communication
|
|
|
|
> ⚠️ Communication **bidirectionnelle obligatoire** sur les livraisons :
|
|
> - Dev ↔ CdP (pendant le projet)
|
|
> - **Support ↔ TMA** (pendant TLM/TMA — chaque livraison de l'un impose un re-merge de l'autre)
|
|
>
|
|
> Une livraison non communiquée provoque des conflits Git lourds + risque de régressions en prod.
|
|
|
|
## Schéma récapitulatif (cycle de vie d'un projet)
|
|
|
|
```
|
|
Phase Dev MEP Hypercare TLM
|
|
develop ─o─o─o──────merge──┐ (delete) ┌─o─o──merge──┐ (delete)
|
|
▼ ▼ ▼
|
|
master ────────────────o──o──────o─────o─o───────────o──────────►
|
|
│
|
|
┌──────────┴──────────┐
|
|
▼ ▼
|
|
hotfix (Support) ─o──────merge──┐ release (TMA) ─o─o─merge
|
|
▼ │
|
|
master ───────────────────────────────────o─o───o─────────merge─────────o─o
|
|
```
|
|
|
|
## Common errors
|
|
|
|
- **`develop` toujours présente au passage TLM** → Support refuse le transfert. Le CdP doit merger une dernière fois `develop`→`master` puis supprimer `develop`.
|
|
- **TMA livre une `release` sans avoir mergé les `hotfix` Support récents** → conflits massifs en prod ou régressions des correctifs Support. Toujours `master → release` avant livraison.
|
|
- **Support fait un hotfix sans prévenir TMA** → la `release` en cours diverge silencieusement. Toute livraison Support **doit** être annoncée à TMA.
|
|
- **Branche `develop` recréée par un Dev (et non par le Dev Principal)** → risque de fork involontaire. Seul le Dev Principal recrée `develop` post-MEP, à partir de `master`.
|
|
- **Tag de revue/test non créé sur `develop` avant déploiement test** → le CdP ne peut pas figer la version testée. Toujours tag avant [deploy-test-application](deploy-test-application.md).
|
|
|
|
## Related
|
|
|
|
- [Development Methodology (Custom Apps)](development-methodology.md) — stratégie haut niveau master/développement/post-production
|
|
- [Git Workflow (Git Flow)](git-workflow.md) — commandes Git Flow CLI + SourceTree (le "comment" opérationnel)
|
|
- [Deploy Test Application](deploy-test-application.md) — création du tag `<TRIGRAMME>-V<N>` et déploiement de la livraison en test
|