Arthur Ria
228 lines
8.7 KiB
Markdown
228 lines
8.7 KiB
Markdown
---
|
||
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
|