--- 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 : `-V` (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 `-V` et déploiement de la livraison en test