mcp-wms-wiki/wiki/operations/git-branch-lifecycle.md

title, type, sources, related, last_compiled

title	type	sources	related	last_compiled
Git Branch Lifecycle (Project Phases)	operation	sources/archives/Gestion_du_GIT.md	operations/development-methodology.md operations/git-workflow.md operations/deploy-test-application.md	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 — vue d'ensemble (master / développement / post-production)
• git-workflow — 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.

Convention de nommage du tag : <TRIGRAMME_PROJET>-V<NUMERO> (ex : LMD-V1). Voir aussi deploy-test-application 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.

Related

• Development Methodology (Custom Apps) — stratégie haut niveau master/développement/post-production
• Git Workflow (Git Flow) — commandes Git Flow CLI + SourceTree (le "comment" opérationnel)
• Deploy Test Application — création du tag <TRIGRAMME>-V<N> et déploiement de la livraison en test