Git pour le DevOps : branches, revues de code et versions

1. Stratégies de branches #

Trunk-based ou GitFlow.

Comparaison #

Bonne Pratique : Les recherches DORA associent le trunk-based development (moins de trois branches actives, fusion quotidienne) à une meilleure performance de livraison. Réservez GitFlow aux produits qui maintiennent plusieurs versions.

2. Pull requests et revues #

Relire vite et bien.

Une bonne pull request #

• Petite : moins de 400 lignes modifiées, un seul sujet.
• Une description qui explique le pourquoi, avec le lien vers le ticket.
• Le pipeline CI est vert avant la relecture humaine.
• Relue dans la journée : une revue qui attend plusieurs jours est une file d'attente de plus.

Protéger main #

• Fusion uniquement par pull request, au moins une approbation.
• Statuts CI obligatoires (tests, analyse, build).
• Historique linéaire (squash ou rebase) et branche à jour avant fusion.
• Fichier CODEOWNERS pour impliquer automatiquement les bons relecteurs.

# CODEOWNERS
/infra/         @equipe-plateforme
/src/paiement/  @equipe-paiement
*.tf            @equipe-plateforme

3. Commits et versions #

Un historique lisible par les humains et les outils.

Commits conventionnels #

feat(panier): ajouter le calcul des frais de port
fix(api): corriger le code HTTP en cas de stock vide
docs: documenter la variable DATABASE_URL
refactor!: renommer le champ client_id en customer_id

BREAKING CHANGE: l'API v1 n'accepte plus client_id

Le préfixe (feat, fix, docs, chore, refactor, test, ci) permet de générer automatiquement le changelog et le prochain numéro de version.

Versionnement sémantique #

git tag -a v1.5.0 -m "v1.5.0"
git push origin v1.5.0
git describe --tags            # version la plus proche
git log v1.4.0..v1.5.0 --oneline --no-merges   # changements entre deux versions

Hooks et outils #

# .git/hooks/commit-msg : refuser un message non conventionnel
#!/usr/bin/env bash
grep -qE '^(feat|fix|docs|chore|refactor|test|ci|perf|build)(\(.+\))?!?: .+' "$1" || {
  echo "Message non conventionnel : type(portée): description" >&2; exit 1; }

En équipe, on partage les hooks avec pre-commit (formatage, lint, détection de secrets) et on génère versions et changelog avec semantic-release ou release-please dans le pipeline.

4. Réparer sans paniquer #

Les commandes de secours.

Commandes #

git revert <sha>             # annuler un commit publié (crée un commit inverse)
git commit --amend           # corriger le dernier commit non poussé
git rebase -i HEAD~3         # réorganiser ses commits locaux avant la PR
git reflog                   # retrouver un commit « perdu »
git bisect start ; git bisect bad ; git bisect good v1.4.0   # trouver le commit fautif
git stash ; git stash pop

Règle d'or #

Erreur Courante : Ne réécrivez jamais (rebase, push --force) l'historique d'une branche partagée comme main : utilisez git revert. Si un force push est nécessaire sur votre branche, préférez --force-with-lease.