You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

523 lines
11 KiB
Markdown

# 🔀 Git Workflow - Guide des Bonnes Pratiques
Ce document décrit le workflow Git utilisé pour le projet **BricoLoc Architecture Evolution**.
---
## 📋 Stratégie de Branching
Nous utilisons une variante simplifiée de **Git Flow** adaptée à un projet académique.
### Branches Principales
```
main (production)
develop (développement)
feature/* (fonctionnalités)
```
#### `main`
- **Protection** : ✅ Protégée (pas de push direct)
- **Contenu** : Code stable, déployable
- **Merge** : Uniquement depuis `develop` via Pull Request
- **Tags** : Versions (v1.0.0, v2.0.0, etc.)
#### `develop`
- **Protection** : ⚠️ Semi-protégée (PR recommandées)
- **Contenu** : Code en développement actif
- **Merge** : Depuis `feature/*` branches
#### `feature/*`
- **Nomenclature** : `feature/<nom-descriptif>`
- **Durée de vie** : Courte (1-5 jours max)
- **Base** : Créée depuis `develop`
- **Merge** : Vers `develop` via Pull Request
---
## 🚀 Workflow Complet
### Étape 1 : Créer une Feature Branch
```bash
# S'assurer d'être sur develop et à jour
git checkout develop
git pull origin develop
# Créer une nouvelle feature branch
git checkout -b feature/auth-service
# Vérifier la branche active
git branch
```
**Nomenclature des branches** :
- `feature/auth-service`
- `feature/catalogue-crud`
- `feature/reservation-flow`
- `fix/inventory-bug`
- `docs/update-readme`
- `refactor/clean-architecture`
**❌ À éviter** :
- `feature/test` (trop vague)
- `my-branch` (pas de préfixe)
- `feature-auth` (utiliser `/` pas `-`)
### Étape 2 : Développer
```bash
# Faire des modifications
code packages/microservices/auth/src/
# Vérifier les fichiers modifiés
git status
# Ajouter les fichiers (sélectif)
git add packages/microservices/auth/
# OU ajouter tout
git add .
```
### Étape 3 : Committer
**Format des messages de commit** (Conventional Commits) :
```
<type>(<scope>): <subject>
<body (optionnel)>
<footer (optionnel)>
```
**Types** :
- `feat` : Nouvelle fonctionnalité
- `fix` : Correction de bug
- `docs` : Documentation
- `style` : Formatage (pas de changement de code)
- `refactor` : Refactoring (pas de nouvelle feature)
- `test` : Ajout de tests
- `chore` : Tâches diverses (config, deps)
**Exemples** :
```bash
# Feature
git commit -m "feat(auth): add user registration use case"
# Fix
git commit -m "fix(inventory): resolve stock availability bug"
# Docs
git commit -m "docs(readme): update setup instructions"
# Refactor
git commit -m "refactor(reservation): apply repository pattern"
# Avec body
git commit -m "feat(auth): implement OAuth Google login
- Add Supabase Auth provider configuration
- Create OAuth callback route
- Add Google button to login page"
```
**✅ Bons commits** :
```
feat(catalogue): implement search with filters
fix(reservation): prevent double-booking
docs(adr): add ADR-006 for database choice
refactor(inventory): extract business logic to service layer
test(auth): add unit tests for RegisterUser use case
```
**❌ Mauvais commits** :
```
fix bug # Trop vague
update # Pas de contexte
WIP # Work In Progress (à éviter sur develop/main)
asdfasdf # Non descriptif
Fixed everything # Trop général
```
### Étape 4 : Push vers Remote
```bash
# Premier push (créer la branche remote)
git push -u origin feature/auth-service
# Pushs suivants
git push
```
### Étape 5 : Créer une Pull Request
**Sur GitHub** :
1. Aller sur le repository
2. Cliquer sur "Pull Requests" > "New Pull Request"
3. **Base** : `develop`**Compare** : `feature/auth-service`
4. Remplir le template (voir ci-dessous)
5. Assigner des reviewers (si équipe > 1)
6. Créer la PR
**Template de Pull Request** :
```markdown
## Description
Implémentation du Auth Service avec Clean Architecture.
## Type de changement
- [x] Nouvelle fonctionnalité (feature)
- [ ] Correction de bug (fix)
- [ ] Documentation
- [ ] Refactoring
## Changements
- ✅ Ajout de `RegisterUser` use case
- ✅ Ajout de `SupabaseAuthRepository`
- ✅ Tests unitaires (85% coverage)
- ✅ API Route `/api/auth/register`
## Checklist
- [x] Le code compile sans erreurs
- [x] Les tests passent (`pnpm test`)
- [x] Le linting passe (`pnpm lint`)
- [x] La documentation est à jour
- [x] J'ai testé manuellement
## Captures d'écran (si applicable)
![Screenshot](url)
## Issues liées
Closes #42
Related to #38
```
### Étape 6 : Review & Merge
**Si vous êtes seul** :
- Relire votre code
- Vérifier les tests
- Merger la PR
```bash
# Via GitHub UI : "Merge Pull Request" > "Squash and Merge"
```
**Si en équipe** :
- Attendre review
- Faire les modifications demandées
- Re-push
```bash
# Après review, modifications demandées
git add .
git commit -m "refactor(auth): apply review feedback"
git push
```
### Étape 7 : Supprimer la Feature Branch
```bash
# Après merge, supprimer la branche locale
git checkout develop
git branch -d feature/auth-service
# Supprimer la branche remote (si pas fait automatiquement)
git push origin --delete feature/auth-service
# Mettre à jour develop
git pull origin develop
```
---
## 🔄 Workflow Quotidien
### Démarrer la Journée
```bash
# Mettre à jour develop
git checkout develop
git pull origin develop
# Créer/reprendre une feature branch
git checkout feature/ma-feature
# OU
git checkout -b feature/nouvelle-feature
```
### Pendant le Développement
```bash
# Commits fréquents (toutes les 30min - 2h)
git add .
git commit -m "feat(scope): descriptive message"
# Push régulièrement (fin de session)
git push
```
### Fin de Journée
```bash
# Push final
git add .
git commit -m "feat(scope): progress on feature X"
git push
# Vérifier le statut
git status
```
---
## 🔧 Commandes Git Utiles
### Vérifier l'État
```bash
# Statut actuel
git status
# Différences non staged
git diff
# Différences staged
git diff --cached
# Historique
git log --oneline --graph --all
```
### Annuler des Changements
```bash
# Annuler modifications non staged (fichier spécifique)
git restore <file>
# Annuler modifications non staged (tous les fichiers)
git restore .
# Annuler un fichier staged
git restore --staged <file>
# Annuler le dernier commit (GARDE les modifications)
git reset --soft HEAD~1
# Annuler le dernier commit (SUPPRIME les modifications)
git reset --hard HEAD~1
```
### Stash (Mettre de Côté)
```bash
# Mettre de côté les modifications actuelles
git stash
# Lister les stash
git stash list
# Récupérer le dernier stash
git stash pop
# Récupérer un stash spécifique
git stash apply stash@{0}
# Supprimer un stash
git stash drop stash@{0}
```
### Rebase (Mettre à Jour depuis develop)
```bash
# Sur votre feature branch
git checkout feature/ma-feature
# Rebase sur develop (mettre à jour)
git fetch origin
git rebase origin/develop
# Si conflits, résoudre puis :
git add .
git rebase --continue
# Forcer le push (ATTENTION : seulement sur votre feature branch)
git push --force-with-lease
```
### Cherry-Pick (Appliquer un Commit Spécifique)
```bash
# Récupérer un commit d'une autre branche
git cherry-pick <commit-hash>
```
---
## 🛡️ Règles Importantes
### ✅ À FAIRE
- ✅ Commits fréquents et atomiques
- ✅ Messages de commit descriptifs
- ✅ Pull Request pour toute feature
- ✅ Tester avant de push
- ✅ Rebase pour mettre à jour depuis develop
- ✅ Supprimer les branches mergées
### ❌ À ÉVITER
- ❌ Push direct sur `main` ou `develop`
- ❌ Commits vagues ("fix", "update")
- ❌ Feature branches qui durent > 1 semaine
- ❌ Force push sur `main` ou `develop`
- ❌ Merge conflicts non résolus
- ❌ Code non testé
---
## 🚨 Gestion des Conflits
### Scénario : Conflit lors du Rebase
```bash
# 1. Lancer le rebase
git rebase origin/develop
# 2. Git indique des conflits
# CONFLICT (content): Merge conflict in file.ts
# 3. Ouvrir les fichiers en conflit dans VS Code
code .
# 4. Résoudre les conflits (VS Code affiche les markers)
# <<<<<<<
# votre code
# =======
# code de develop
# >>>>>>>
# 5. Choisir la version à garder ou combiner
# 6. Marquer comme résolu
git add file.ts
# 7. Continuer le rebase
git rebase --continue
# 8. Si tout est OK, force push
git push --force-with-lease
```
### Scénario : Conflit lors du Merge
```bash
# 1. Merger develop dans votre branche
git merge develop
# 2. Résoudre les conflits (même process)
# 3. Commit de merge
git commit -m "merge: resolve conflicts with develop"
# 4. Push
git push
```
---
## 📊 Git Flow Visuel
```
main ─────o─────────────────o───────────→
│ │
│ │ (PR merge)
│ │
develop ─────o─────o───────o───o───────o───→
│ │ │
│ │ │
feature/A ────o───o───o │
│ │
(PR) │
feature/B ────o───o───o
(PR)
```
**Légende** :
- `o` : Commit
- `→` : Timeline
- `│` : Branches
- `(PR)` : Pull Request merge
---
## 📝 Exemple Complet
### Cas d'Usage : Implémenter Catalogue Service
```bash
# 1. Setup
git checkout develop
git pull origin develop
git checkout -b feature/catalogue-service
# 2. Développement (Jour 1)
# ... créer fichiers ...
git add packages/microservices/catalogue/
git commit -m "feat(catalogue): add domain entities and interfaces"
git push -u origin feature/catalogue-service
# 3. Développement (Jour 2)
# ... implémenter use cases ...
git add .
git commit -m "feat(catalogue): implement search outils use case"
git push
# 4. Développement (Jour 3)
# ... tests ...
git add .
git commit -m "test(catalogue): add unit tests for SearchOutils"
git push
# 5. Mise à jour depuis develop (si besoin)
git fetch origin
git rebase origin/develop
git push --force-with-lease
# 6. Créer Pull Request sur GitHub
# ... remplir template ...
# 7. Merger (après review/tests)
# Via GitHub UI
# 8. Cleanup
git checkout develop
git pull origin develop
git branch -d feature/catalogue-service
```
---
## 🔗 Ressources
- **Conventional Commits** : https://www.conventionalcommits.org/
- **Git Flow** : https://nvie.com/posts/a-successful-git-branching-model/
- **Atlassian Git Tutorials** : https://www.atlassian.com/git/tutorials
---
**Dernière mise à jour** : Octobre 2025