1. GitFlow

GitFlow est un modèle de branchement populaire défini par Vincent Driessen (2010). Il convient aux projets avec des releases planifiées.

Les 5 types de branches

Workflow GitFlow typique

git checkout develop
git checkout -b feature/login
# ... développement ...
git commit -m "feat(auth): add login form"
git checkout develop
git merge --no-ff feature/login   # Toujours --no-ff
git branch -d feature/login

# Release :
git checkout -b release/1.2.0 develop
# ... tests, bump version ...
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

Avantages et limites

• Avantages : Isolation des features, releases stables, hotfix propres
• Limites : Beaucoup de branches, merges fréquents, overhead pour les petites équipes
• Quand l'utiliser : Logiciel packagé, versions multiples en production simultanément

2. GitHub Flow

GitHub Flow est un workflow simplifié : une seule branche principale (main) + des feature branches courtes. Tout passe par des Pull Requests.

Les 6 étapes de GitHub Flow

git checkout -b feature/user-profile main
# ... code, commits ...
git push -u origin feature/user-profile
# Ouvrir PR sur GitHub → review → merge
# CI s'exécute → déploiement automatique

3. Trunk-Based Development

Trunk-Based Development (TBD) pousse encore plus loin : les branches vivent moins d'un jour avant d'être mergées dans main. Les features incomplètes sont cachées avec des feature flags.

Principe

# Branche très courte (quelques heures max)
git checkout -b fix/typo-header
git commit -m "fix: correct header typo"
git push origin fix/typo-header
# Merge le même jour !

Comparaison GitFlow vs GitHub Flow vs TBD

4. Conventional Commits

Conventional Commits est une convention de messages de commit qui permet de générer automatiquement le CHANGELOG et de déterminer la prochaine version SemVer.

Format

type(scope): description

# Corps optionnel (après une ligne vide)
# Explique le POURQUOI, pas le QUOI

# Pied de page optionnel
BREAKING CHANGE: description de la rupture

Types de commits

Exemples concrets

git commit -m "feat(auth): add OAuth2 Google login"
git commit -m "fix(api): handle null response from /users endpoint"
git commit -m "chore: update dependencies to latest versions"
git commit -m "docs(readme): add installation instructions"
git commit -m "refactor: extract authentication logic to AuthService"

# Breaking change :
git commit -m "feat!: change API response format to JSON:API spec

BREAKING CHANGE: API responses now follow JSON:API format.
All clients must be updated to handle the new structure."

5. Semantic Versioning

SemVer (semver.org) définit un format de version : MAJOR.MINOR.PATCH.

Règles d'incrémentation

Tags Git et versions

# Créer un tag annoté
git tag -a v1.2.0 -m "Release 1.2.0 — ajout OAuth2"

# Pousser les tags sur le remote
git push origin --tags

# Lister les tags
git tag -l
git tag -l "v1.*"     # Filtrer par pattern

# Voir les détails d'un tag
git show v1.2.0

# Supprimer un tag local et remote
git tag -d v1.2.0-beta
git push origin :refs/tags/v1.2.0-beta

6. Git Hooks

Les Git Hooks sont des scripts qui s'exécutent automatiquement lors d'événements Git (commit, push…). Ils vivent dans .git/hooks/.

Hooks côté client (les plus utilisés)

Hook pre-commit manuel

#!/bin/bash
# .git/hooks/pre-commit
echo "🔍 Running lint before commit..."
npm run lint
if [ $? -ne 0 ]; then
  echo "❌ Lint failed. Commit aborted."
  exit 1
fi
echo "✅ Lint passed!"

# Rendre le hook exécutable
chmod +x .git/hooks/pre-commit

Husky + lint-staged (recommandé pour Node.js)

# Installation
npm install --save-dev husky lint-staged
npx husky init

# package.json
{
  "lint-staged": {
    "*.{js,ts}": ["eslint --fix", "prettier --write"],
    "*.{css,md}": ["prettier --write"]
  }
}

# .husky/pre-commit
npx lint-staged

git bisect — trouver le commit qui a introduit un bug

git bisect start
git bisect bad                    # HEAD contient le bug
git bisect good v1.0.0           # Cette version était bonne
# Git checkout automatiquement le commit médian
# Tester → indiquer si bon ou mauvais
git bisect good                   # ou git bisect bad
# Répéter jusqu'à trouver le coupable
git bisect reset                  # Revenir à HEAD