Git Flow et GitLab : collaboration avancée au-delà du add, commit, push

main (ou master)
    → Code en production, toujours stable
    → Seules les releases et hotfixes peuvent merger ici
    → Tag pour chaque version (v1.0.0, v1.1.0, etc.)

develop
    → Code de développement en cours
    → Intégration continue de toutes les features
    → Base pour créer les releases

feature/*
    → Une branche par fonctionnalité
    → Créée depuis develop, mergée dans develop
    → Exemples : feature/login, feature/payment

release/*
    → Préparation d'une nouvelle version
    → Créée depuis develop, mergée dans main ET develop
    → Permet de figer les features et corriger les derniers bugs

hotfix/*
    → Fix urgent sur la production
    → Créée depuis main, mergée dans main ET develop
    → Permet de corriger sans attendre la prochaine release

Étape 1 : Développer une nouvelle feature

# Se placer sur develop
git checkout develop
git pull origin develop

# Créer une branche feature
git checkout -b feature/user-authentication

# Développer, committer
git add .
git commit -m "feat: add login form"
git commit -m "feat: add JWT token validation"
git commit -m "feat: add password encryption"

# Pousser la branche
git push origin feature/user-authentication

Résultat : Votre feature est isolée. Vous ne cassez pas le travail des autres, et les autres ne cassent pas le vôtre.

Étape 2 : Créer une Merge Request (MR) sur GitLab

Au lieu de merger directement, vous passez par une Merge Request. C'est la clé de la qualité du code.

• Allez sur GitLab → Merge Requests → New Merge Request
• Source branch : feature/user-authentication
• Target branch : develop
• Assignez des reviewers (vos collègues)
• Décrivez ce que fait la feature

Ce qui se passe automatiquement : GitLab lance le pipeline CI/CD, teste votre code, vérifie la sécurité, et notifie les reviewers.

Étape 3 : Code Review par vos pairs

Vos collègues reviewent votre code directement dans GitLab. Ils peuvent :

• Commenter ligne par ligne : "Ce if pourrait être simplifié"
• Suggérer des modifications : GitLab génère un diff que tu peux accepter en 1 clic
• Approuver ou demander des changements : Pas de merge tant que tout le monde n'a pas approuvé
• Créer des threads de discussion : Conversation contextuelle directement sur le code

Gain : Zéro bug qui passe inaperçu, code de meilleure qualité, équipe qui monte en compétences.

Étape 4 : Merge dans develop

# Une fois la MR approuvée, merger dans develop
# (sur GitLab, bouton "Merge" directement dans l'interface)

# Ou en ligne de commande :
git checkout develop
git pull origin develop
git merge --no-ff feature/user-authentication
git push origin develop

# Supprimer la branche feature (nettoyage)
git branch -d feature/user-authentication
git push origin --delete feature/user-authentication

Option recommandée : Utilisez le bouton "Merge" de GitLab. Il merge, ferme la MR, et supprime la branche automatiquement.

Étape 5 : Préparer une release

Quand vous avez assez de features dans develop, vous préparez une release.

# Créer une branche release
git checkout develop
git pull origin develop
git checkout -b release/1.2.0

# Figer la version dans le code
# Exemple : update version in pom.xml, package.json, etc.
mvn versions:set -DnewVersion=1.2.0

# Corriger les derniers bugs (pas de nouvelles features !)
git commit -m "chore: bump version to 1.2.0"
git commit -m "fix: correct login redirect"

# Pousser la branche
git push origin release/1.2.0

Règle d'or : Sur une branche release, on corrige les bugs, on ne développe pas de nouvelles features.

Étape 6 : Merger la release en production

# Merger dans main (production)
git checkout main
git pull origin main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release version 1.2.0"
git push origin main --tags

# Merger aussi dans develop (pour récupérer les derniers fixes)
git checkout develop
git pull origin develop
git merge --no-ff release/1.2.0
git push origin develop

# Supprimer la branche release
git branch -d release/1.2.0
git push origin --delete release/1.2.0

Résultat : Version v1.2.0 déployée en prod, taggée, traçable. En cas de problème, vous savez exactement quel commit déployer.

# 1. Créer une branche hotfix depuis main
git checkout main
git pull origin main
git checkout -b hotfix/fix-payment-bug

# 2. Corriger le bug
git commit -m "fix: resolve payment gateway timeout"

# 3. Bump la version (patch)
# v1.2.0 → v1.2.1
mvn versions:set -DnewVersion=1.2.1
git commit -m "chore: bump version to 1.2.1"

# 4. Merger dans main (production)
git checkout main
git merge --no-ff hotfix/fix-payment-bug
git tag -a v1.2.1 -m "Hotfix: payment gateway timeout"
git push origin main --tags

# 5. Merger aussi dans develop (important !)
git checkout develop
git merge --no-ff hotfix/fix-payment-bug
git push origin develop

# 6. Supprimer la branche hotfix
git branch -d hotfix/fix-payment-bug
git push origin --delete hotfix/fix-payment-bug

1. Protected Branches : empêcher les pushs directs

Dans GitLab, allez dans Settings → Repository → Protected Branches.

• Protégez main : Personne ne peut pusher directement
• Protégez develop : Seuls les Maintainers peuvent merger
• Activez "Require approval from code owners" : 2 approbations minimum avant merge

Résultat : Impossible de casser main par accident. Tout passe par une Merge Request reviewée.

2. Merge Request Templates : standardiser les MR

Créez un fichier .gitlab/merge_request_templates / Default.md :

## Description


## Type de changement
- [ ] Feature (nouvelle fonctionnalité)
- [ ] Fix (correction de bug)
- [ ] Refactoring (amélioration du code sans changer le comportement)
- [ ] Documentation

## Tests
- [ ] Tests unitaires ajoutés
- [ ] Tests d'intégration ajoutés
- [ ] Testé manuellement

## Checklist
- [ ] Le code suit les conventions du projet
- [ ] Les tests passent en local
- [ ] La documentation est à jour
- [ ] Pas de secrets hardcodés
- [ ] Le pipeline CI/CD passe

## Screenshots (si applicable)


## Issues liées
Closes #123

Résultat : Toutes les MR sont complètes, documentées, et les reviewers savent exactement ce qu'ils doivent vérifier.

3. Approval Rules : forcer la review

Dans Settings → Merge Requests → Approval Rules :

• Nombre d'approbations minimum : 2
• Code owners requis : Oui (pour les fichiers critiques)
• L'auteur de la MR ne peut pas s'approuver lui-même
• Bloquer le merge si le pipeline échoue

Résultat : Impossible de merger du code non testé ou non reviewé. La qualité est garantie.

4. Squash Commits : garder un historique propre

Activez "Squash commits when merging" dans les settings de la MR.

Avant squash (historique pollué) :

* fix typo
* fix typo again
* add login form
* fix login form
* update login form
* final fix I promise

Après squash (historique propre) :

* feat: add user authentication with JWT

Résultat : L'historique de main est lisible. Chaque commit = une feature ou un fix complet.

5. Branch Auto-Delete : nettoyage automatique

Dans Settings → Merge Requests, activez "Enable 'Delete source branch' option by default".

Résultat : Les branches feature/release/hotfix sont supprimées automatiquement après merge. Votre repo reste propre.

feature/NOM-COURT-DE-LA-FEATURE
    Exemples :
    - feature/user-login
    - feature/payment-integration
    - feature/email-notifications

fix/NOM-DU-BUG
    Exemples :
    - fix/login-redirect-error
    - fix/payment-timeout
    - fix/email-encoding

hotfix/NOM-DU-HOTFIX
    Exemples :
    - hotfix/critical-security-patch
    - hotfix/payment-gateway-down

release/VERSION
    Exemples :
    - release/1.2.0
    - release/2.0.0

feat: nouvelle fonctionnalité
    Exemples :
    - feat: add user authentication
    - feat: implement payment gateway

fix: correction de bug
    Exemples :
    - fix: resolve login timeout issue
    - fix: correct email validation regex

chore: tâches de maintenance
    Exemples :
    - chore: update dependencies
    - chore: bump version to 1.2.0

docs: documentation
    Exemples :
    - docs: add API documentation
    - docs: update README

refactor: amélioration du code
    Exemples :
    - refactor: simplify authentication logic
    - refactor: extract payment service

test: ajout/modification de tests
    Exemples :
    - test: add unit tests for login
    - test: improve integration test coverage

style: formatage du code
    Exemples :
    - style: format code with prettier
    - style: fix indentation

Piège #1 : Feature branch qui vit trop longtemps

Une branche feature qui reste ouverte 3 semaines accumule des conflits énormes avec develop. Règle d'or : une feature = 2-5 jours max. Si c'est plus long, découpez en sous-features.

Piège #2 : Oublier de merger le hotfix dans develop

Vous corrigez un bug critique en prod (hotfix dans main), mais vous oubliez de merger dans develop. Résultat : le bug réapparaît dans la prochaine release. Toujours merger hotfix dans main ET develop.

Piège #3 : Développer sur develop directement

Develop doit rester stable. Ne développez JAMAIS directement dessus. Toujours créer une branche feature, même pour un "petit fix de 2 lignes".

Piège #4 : Force push sur une branche partagée

git push --force écrase l'historique. Si quelqu'un d'autre travaille sur la même branche, vous détruisez son travail. Utilisez --force-with-lease si vraiment nécessaire, mais évitez au maximum.

Piège #5 : Commits trop gros ou trop vagues

Un commit "fix stuff" qui change 50 fichiers, c'est impossible à reviewer. Règle : 1 commit = 1 changement logique. Si vous avez corrigé 3 bugs, faites 3 commits séparés.

GitHub Flow : plus simple, pour du déploiement continu

Principe : Une seule branche principale (main), des branches feature, merge direct en prod.

main (toujours déployable)
    ↓
feature/ma-feature
    ↓
Merge Request → Review → Merge dans main
    ↓
Déploiement automatique en production

Quand l'utiliser : Applications web avec déploiement continu, pas de releases fixes, équipes qui déploient 10+ fois par jour.

GitLab Flow : le meilleur des deux mondes

Principe : Branches d'environnement (production, staging, development).

main (développement)
    ↓
feature/ma-feature → Merge dans main
    ↓
staging (environnement de test)
    ↓
production (prod finale)

Quand l'utiliser : Applications avec plusieurs environnements, déploiements progressifs (staging → prod).

Comparaison rapide

Workflow	Complexité	Cas d'usage
Git Flow	Élevée	Releases planifiées, versions fixes
GitHub Flow	Faible	Déploiement continu, web apps
GitLab Flow	Moyenne	Environnements multiples, staging

# macOS
brew install git-flow

# Ubuntu/Debian
sudo apt-get install git-flow

# Windows
choco install gitflow-avh

git flow init

# Accepter les valeurs par défaut :
# - Branche de production : main
# - Branche de développement : develop
# - Préfixe feature : feature/
# - Préfixe release : release/
# - Préfixe hotfix : hotfix/

# Créer une feature
git flow feature start user-login
# = git checkout -b feature/user-login develop

# Finir une feature (merge dans develop)
git flow feature finish user-login
# = git checkout develop
#   git merge --no-ff feature/user-login
#   git branch -d feature/user-login

# Créer une release
git flow release start 1.2.0

# Finir une release (merge dans main ET develop)
git flow release finish 1.2.0
# = git checkout main
#   git merge --no-ff release/1.2.0
#   git tag -a v1.2.0
#   git checkout develop
#   git merge --no-ff release/1.2.0

# Créer un hotfix
git flow hotfix start fix-payment-bug

# Finir un hotfix (merge dans main ET develop)
git flow hotfix finish fix-payment-bug

Avant Git Flow : 8-12h/semaine perdues

• 3-4h en résolution de conflits Git chaotiques
• 2-3h en debugging "qui a cassé master"
• 2h en coordination manuelle "attends je finis de pusher"
• 1-2h en rollback parce qu'on a déployé du code pas testé

Après Git Flow : ~1h/semaine

• 30min de code review (mais c'est du temps bien investi)
• 20min de gestion des branches (création, merge)
• 10min de résolution de conflits mineurs

# Workflow Git Flow

## Branches principales

- main : Code en production, toujours stable
- develop : Code de développement, intégration continue

## Types de branches

### Feature (nouvelle fonctionnalité)
```bash
git flow feature start nom-feature
# Développer...
git flow feature finish nom-feature
```

### Release (nouvelle version)
```bash
git flow release start 1.2.0
# Figer la version, corriger les bugs...
git flow release finish 1.2.0
```

### Hotfix (correction urgente en prod)
```bash
git flow hotfix start nom-hotfix
# Corriger le bug...
git flow hotfix finish nom-hotfix
```

## Convention de nommage

### Branches
- feature/nom-court
- release/x.y.z
- hotfix/nom-court

### Commits (Conventional Commits)
- feat: nouvelle fonctionnalité
- fix: correction de bug
- chore: maintenance
- docs: documentation
- refactor: amélioration du code
- test: ajout de tests

## Merge Request

1. Créer une MR de votre feature vers develop
2. Assigner 2 reviewers minimum
3. Attendre l'approbation + pipeline vert
4. Merger avec squash (historique propre)

## Règles d'or

- ❌ Jamais de push direct sur main ou develop
- ✅ Toujours créer une branche feature, même pour un petit fix
- ✅ Garder les features courtes (2-5 jours max)
- ✅ Merger les hotfixes dans main ET develop
- ✅ Code review obligatoire avant merge

Le vrai ROI (au-delà du temps gagné)

• Culture de la qualité : Code review devient la norme, pas l'exception
• Montée en compétences : Les juniors apprennent en reviewant le code des seniors
• Documentation vivante : L'historique Git raconte l'histoire du projet
• Moins de turnover : Les devs préfèrent travailler dans un environnement organisé
• Audit et compliance : Tout est tracé, approuvé, documenté