Files
mcp-wms-wiki/wiki/operations/git-workflow.md
T
arthur 9ce6ae37be lint(standard): corrections completes mode standard
- Em dashes: 1712 remplaces par tirets simples (86 fichiers + _index.md,
  en-tete section Limagrain conserve)
- Checklists: 24 '- [ ]' -> '- ☐' (3 pages operations, plus de todos Obsidian)
- Ancres: 33 reparees (slugs GitHub + ancres HTML <a id> reconnues),
  1 reciblee (manuel de reten)
- related: tenseflow -> tense-flow, pie -> mechanical-elements,
  group.md retire (doublon shipping)
- Registre: compteur global 122 -> 131 pages
- Rapport racine _lint_report.md mis a jour (scan v2 + re-scan final: 0 anomalie)
- Aucun fichier limagrain/ modifie (cloisonnement)
2026-07-20 13:01:21 +02:00

228 lines
8.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
title: "Git Workflow (Git Flow)"
type: operation
sources:
- sources/archives/Gestion_versions_projet_GIT.md
related:
- 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
last_compiled: "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](development-methodology.md) 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](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000088854571)** (configuré en anglais).
Source : Confluence EasyWMS France - *Gestion des versions du projet avec GIT* (v27, 22/08/2025).
### Ressources externes
- [Équivalences git ↔ git flow](https://gist.github.com/JamesMGreene/cdd0ac49f90c987e45ac)
- [Git flow cheat sheet](http://danielkummer.github.io/git-flow-cheatsheet/)
## 1. Initialiser le projet en local
### Clone
**CLI :**
```bash
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 :**
```bash
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 :**
```bash
git pull
```
**SourceTree :** bouton **"Pull"**.
### Démarrer la feature
**CLI :**
```bash
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](vm-installation.md#7-point-de-contrôle-deploy-0))
2. Déployer la branche : cf. [deployment-existing-app](deployment-existing-app.md)
> Si une pop-up de connexion apparaît sur SmartUI après déploiement : [procédure dédiée Confluence](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000144789544)
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](custom-application-management.md#export)
2. **Paramètres / config WMS modifiés** → export datas via **[uGNA](ugna-data-export.md)** (procédure complète avec liste des entités et erreurs droits)
3. **Fichiers BOO du GNA modifiés** → exécuter [`GNAGetDataForGit.ps1`](gna-services-license.md#sauvegarder-la-configuration-sur-le-git)
### Commit + push
**CLI :**
```bash
# 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 :**
```bash
git switch develop
git pull
```
**SourceTree :** double-clic sur la branche `develop`**"Pull"**.
### 4.2 Clôturer la feature
**CLI :**
```bash
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 :**
```bash
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](development-methodology.md)).
- **Push refusé ("non-fast-forward")** → `git pull --rebase` sur votre branche avant de re-push.
## Related
- [Development Methodology](development-methodology.md) - cadre général (branches `master`/`développement`/`post-production`, phases dev/test/post-prod)
- [Git Branch Lifecycle](git-branch-lifecycle.md) - gouvernance par phase de projet (Dev / MEP / Hypercare / TLM / TMA), rôles Dev/CdP/Support/TMA
- [SSH Keys Setup (MSSCODE & Sourcetree)](ssh-keys-setup.md) - clé SSH ed25519 pour ne plus saisir les identifiants MSSCODE
- [Custom Application Management](custom-application-management.md) - export/import systématique avant commit
- [uGNA Data Export](ugna-data-export.md) - export config WMS via `uGNAConsole.exe -Z:` (étape pré-commit)
- [Code Review Process](code-review-process.md) - revue Code/Fonctionnel/Documentation avant `Finish Feature`
- [Deploy Existing Application](deployment-existing-app.md) - déploiement après pull ou changement de branche
- [Deploy Specific Commit](deployment-specific-commit.md) - figer un commit pour démo / debug
- [GNA, Services & License](gna-services-license.md) - sauvegarde GIT des scripts BOO avant commit