mcp-wms-wiki/wiki/operations/git-workflow.md

title, type, sources, related, last_compiled

title	type	sources	related	last_compiled
Git Workflow (Git Flow)	operation	sources/archives/Gestion_versions_projet_GIT.md	operations/development-methodology.md operations/git-branch-lifecycle.md operations/custom-application-management.md operations/deployment-existing-app.md operations/deployment-specific-commit.md operations/gna-services-license.md operations/ssh-keys-setup.md operations/ugna-data-export.md operations/code-review-process.md	2026-04-17

Git Workflow (Git Flow)

Overview

Workflow Git Flow appliqué aux projets EasyWMS France. Git Flow est une extension de Git qui impose un workflow structuré et uniformise la gestion des branches (features / bugfixes / releases / hotfixes / support). Il complète la stratégie de branches décrite dans development-methodology en donnant la procédure opérationnelle (commandes CLI et SourceTree) :

• Initialiser le dépôt
• Créer / basculer sur une feature
• Committer ses développements (y compris export CustomApp + export uGNA + sauvegarde GNA)
• Clôturer la feature avec rebase sur develop
• Gérer les conflits

La gestion est expliquée en parallèle via invite de commande (CLI) et SourceTree (configuré en anglais).

Source : Confluence EasyWMS France - Gestion des versions du projet avec GIT (v27, 22/08/2025).

Ressources externes

• Équivalences git ↔ git flow
• Git flow cheat sheet

1. Initialiser le projet en local

Clone

CLI :

cd <emplacement souhaité>
git clone <url>

SourceTree : bouton "Clone" → renseigner l'URL du repo.

L'URL du repo GIT se trouve dans l'interface de gestion du projet (bouton "Clone" / "Code" selon la plateforme).

Initialiser Git Flow

CLI :

git flow init -d \
  --feature feature/ \
  --bugfix bugfix/ \
  --release release/ \
  --hotfix hotfix/ \
  --support support/ \
  -t ''
git push --set-upstream origin develop

SourceTree : icône Git Flow → ne rien modifier dans la fenêtre de configuration → OK.

2. Créer une nouvelle feature / branche

Récupérer les derniers commits

CLI :

git pull

SourceTree : bouton "Pull".

Démarrer la feature

CLI :

git flow feature start <nom de la feature>
# Ex : git flow feature start PD-49

SourceTree : icône Git Flow → "Start New Feature" → saisir le nom.

Déployer la VM sur la nouvelle branche

1. Appliquer le point de contrôle "DEPLOY 0" sur la VM (cf. vm-installation)
2. Déployer la branche : cf. deployment-existing-app

Si une pop-up de connexion apparaît sur SmartUI après déploiement : procédure dédiée Confluence

Vous êtes prêt à commencer vos développements. ✅

3. Commit de vos modifications

Étape préalable - exporter les modifications

Avant tout commit, exporter tout ce qui a été modifié :

1. Custom app → cf. custom-application-management - Export
2. Paramètres / config WMS modifiés → export datas via uGNA (procédure complète avec liste des entités et erreurs droits)
3. Fichiers BOO du GNA modifiés → exécuter GNAGetDataForGit.ps1

Commit + push

CLI :

# Ajouter tout ce qui est modifié
git add .
# Ou fichier par fichier
git add <Nom du fichier>

# Commit avec message explicite
git commit -m "<Message expliquant vos modifications>"

# Push
git push

SourceTree :

1. "Commit" (haut à gauche)
2. "Stage all" ou drag & drop / "Stage selected"
3. Écrire le message de commit
4. "Commit"
5. Pour push simultané : cocher "Push changes immediately"

ℹ️ Les fichiers générés par l'export de la custom app sont séparés en plusieurs fichiers pour un même élément (workflow, source C#, DESIGN…). Bien prendre tous les fichiers portant le nom de l'élément modifié.

⚠️ Règle absolue : commit et push ses développements tous les soirs avant de quitter les bureaux - évite toute perte (perte/vol/casse du PC).

4. Fin de la tâche de développement

Une fois développements testés et validés, clôturer la branche.

4.1 Mettre à niveau develop

CLI :

git switch develop
git pull

SourceTree : double-clic sur la branche develop → "Pull".

4.2 Clôturer la feature

CLI :

git flow feature finish -r <Nom feature>
git push
# Ex : git flow feature finish -r PD-49

SourceTree :

1. Icône Git Flow → sélectionner la feature
2. ✅ Cocher "Rebase on development Branch"
3. Valider → "Push"

4.3 Gérer les conflits

Si le rebase lève des conflits :

1. Ouvrir les fichiers en conflit (VSCode recommandé) et les résoudre

CLI :

git add <nom du fichier résolu>
git rebase --continue
# Répéter pour chaque commit jusqu'à la fin du rebase
# Puis recommencer la clôture de la feature

SourceTree :

1. Ne pas faire de commit - uniquement "stage" les fichiers résolus
2. "Continue Rebase"
3. Répéter pour chaque commit de develop
4. Recommencer la clôture de la feature - cette fois sans cocher "Rebase"

4.4 Mettre à jour Jira

Passer le ticket à "Revue de code".

Checklist journalière

• ☐ git pull en début de journée sur votre branche
• ☐ Commits petits et explicites tout au long de la journée
• ☐ Avant commit : export custom app + uGNA + GNA (si concerné)
• ☐ Soir : tous les commits poussés sur le remote (règle absolue)
• ☐ Avant clôture : develop à jour + rebase réussi

Parameters / Branches Git Flow

Type	Préfixe	Source	Destination	Objet
Feature	feature/	develop	develop	Développements courants (ex : feature/PD-49)
Bugfix	bugfix/	develop	develop	Corrections de bugs sur le développement en cours
Release	release/	develop	master + develop	Préparation d'une release
Hotfix	hotfix/	master	master + develop	Correctifs urgents en production
Support	support/	master	-	Maintien d'une version antérieure

Common errors

• Pop-up de connexion SmartUI après déploiement sur nouvelle branche → procédure dédiée Confluence (pas traité ici).
• Perte de travail suite à casse PC → n'a pas respecté la règle du push de fin de journée. Règle absolue.
• Rebase qui répète les mêmes conflits → normal : git flow feature finish -r rejoue chaque commit. Résoudre, stage, continue, recommencer.
• SourceTree re-clôture et re-rebase → après résolution manuelle des conflits, relancer la finalisation sans cocher "Rebase" (c'est l'étape 4.3 → 4.2).
• Fichiers custom app manquants après commit → stager tous les fichiers (workflow + C# + DESIGN séparés). Faire un git status avant commit pour vérifier.
• Conflits systématiques sur le manuel de reten DOC → utiliser Markdown pendant le dev, conversion DOC uniquement en fin de chantier (cf. development-methodology).
• Push refusé ("non-fast-forward") → git pull --rebase sur votre branche avant de re-push.

Related

• Development Methodology - cadre général (branches master/développement/post-production, phases dev/test/post-prod)
• Git Branch Lifecycle - gouvernance par phase de projet (Dev / MEP / Hypercare / TLM / TMA), rôles Dev/CdP/Support/TMA
• SSH Keys Setup (MSSCODE & Sourcetree) - clé SSH ed25519 pour ne plus saisir les identifiants MSSCODE
• Custom Application Management - export/import systématique avant commit
• uGNA Data Export - export config WMS via uGNAConsole.exe -Z: (étape pré-commit)
• Code Review Process - revue Code/Fonctionnel/Documentation avant Finish Feature
• Deploy Existing Application - déploiement après pull ou changement de branche
• Deploy Specific Commit - figer un commit pour démo / debug
• GNA, Services & License - sauvegarde GIT des scripts BOO avant commit