romain
/
ansiblenginx
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
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.
main
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '7fd175eb01'
${ noResults }
ansiblenginx/app/bricolociaac/docs/guides/git-workflow.md

11 KiB
Raw Blame History

🔀 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

# 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

# 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 :

# 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

# 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 :

## 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
# Via GitHub UI : "Merge Pull Request" > "Squash and Merge"

Si en équipe :

  • Attendre review
  • Faire les modifications demandées
  • Re-push
# Après review, modifications demandées
git add .
git commit -m "refactor(auth): apply review feedback"
git push

Étape 7 : Supprimer la Feature Branch

# 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

# 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

# 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

# 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

# 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

# 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é)

# 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)

# 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)

# 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

# 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

# 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

# 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

Dernière mise à jour : Octobre 2025