Git et versionning — Workflows, bonnes pratiques et outils pour les développeurs web

Q: Git Flow ou trunk-based development ?

Le trunk-based development (tout le monde commit sur main via des branches courtes) est recommandé pour les équipes qui pratiquent le CI/CD. Git Flow reste pertinent pour les projets avec des releases versionnées (librairies, apps mobiles, logiciels on-premise). Pour un site web déployé en continu, le trunk-based est plus simple et plus rapide.

Git est l'outil que tous les développeurs utilisent quotidiennement, mais que peu maîtrisent en profondeur. Au-delà des git add / git commit / git push, un historique propre, un workflow adapté et des conventions d'équipe font la différence entre un projet maintenable et un projet où personne n'ose toucher au code.

Cet article fait le point sur les bonnes pratiques Git pour un développeur web Symfony, PrestaShop ou WordPress — du choix du workflow à l'automatisation des vérifications.

Pourquoi le versionning est fondamental

Le versionning n'est pas qu'un historique de fichiers. C'est un filet de sécurité (rollback à tout moment), un outil de collaboration (plusieurs développeurs sur le même code sans conflit) et une source de vérité (qui a changé quoi, quand et pourquoi).

Git est devenu le standard universel. Avec plus de 150 millions d'utilisateurs sur GitHub seul et une adoption quasi-totale chez les développeurs professionnels, ne pas maîtriser Git est un handicap concret.

Choisir son workflow

Le workflow définit comment l'équipe organise ses branches et ses merges. Deux approches dominent :

Trunk-based development

Tout le monde travaille sur main (ou des branches très courtes — quelques heures à quelques jours max). C'est l'approche recommandée pour les équipes qui pratiquent le CI/CD : chaque commit est déployé rapidement, les conflits sont rares car les branches ne vivent pas longtemps.

Avantages : intégration continue réelle, feedback rapide, moins de merge conflicts.
Prérequis : une bonne couverture de tests, des feature flags pour les fonctionnalités en cours, et un pipeline CI solide.

Git Flow

Un modèle plus structuré avec des branches dédiées : main (production), develop (intégration), feature/*, release/*, hotfix/*. Adapté aux projets avec des releases versionnées (librairies, apps mobiles, logiciels on-premise).

Avantages : contrôle strict des versions, branches stables identifiées.
Inconvénients : branches longues, merge conflicts fréquents, lenteur de livraison.

Conventional Commits : un historique lisible

Les conventional commits structurent les messages de commit avec un format machine-readable :

type(scope): description courte

Corps optionnel (le "pourquoi", pas le "quoi")

Les types courants : feat (nouvelle fonctionnalité), fix (correction de bug), refactor, docs, style, test, chore (config, deps), perf, ci.

Pourquoi les adopter ?

Lisibilité — En lisant l'historique, on sait immédiatement si un commit est un fix, une feature ou du refactoring
Automatisation — Des outils génèrent automatiquement le changelog depuis les commits
Semantic versioning — feat = minor, fix = patch, feat! = major
Enforcement — Un hook commit-msg valide le format avant chaque commit, sans friction

Signer ses commits avec SSH

La signature de commits prouve que le code vient bien de vous. Depuis Git 2.34, la signature SSH est supportée nativement — plus besoin de GPG.

La configuration est simple :

# Configurer Git pour utiliser votre clé SSH
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

Chaque commit sera signé automatiquement. Sur GitHub et GitLab, les commits signés affichent un badge "Verified".

Quand signer ? Sur les projets open-source (prouve l'identité), les projets sensibles (audit trail), et par bonne habitude sur tous les projets.

GitHub vs GitLab

Les deux plateformes couvrent les mêmes besoins fondamentaux (hébergement Git, PRs/MRs, CI/CD, issues) mais avec des philosophies différentes :

Critère	GitHub	GitLab
Utilisateurs	150M+	30M+
CI/CD	GitHub Actions (marketplace +15 000 actions)	GitLab CI (intégré nativement, plus complet)
IA	Copilot (code review, coding agent)	Duo (agentic platform)
Auto-hébergement	Enterprise (payant)	CE gratuit (self-managed)
Open source	Ecosystème dominant	Fort en entreprise/gouvernement
Prix	Gratuit (public), Pro 4$/mois	Gratuit (Free), Premium 29$/mois

En pratique : pour un développeur web indépendant ou un projet open-source, GitHub est le choix par défaut (visibilité, communauté, Copilot). Pour une entreprise qui veut maîtriser son infrastructure ou a des contraintes de souveraineté, GitLab est plus adapté.

Git 3.0 : ce qui arrive

Git 3.0 est attendu fin 2026 — le premier saut de version majeure depuis 2014. Les changements prévus :

SHA-256 par défaut — remplace SHA-1 (vulnérabilités connues depuis 2017). Les dépôts existants pourront migrer progressivement
main comme branche par défaut — officialise ce qui est déjà la pratique sur GitHub et GitLab
Reftable backend — nouveau format de stockage des références (branches, tags) plus performant et atomique
Rust comme dépendance de build — certaines parties de Git seront réécrites en Rust pour la sécurité mémoire

En pratique, l'impact pour les développeurs web sera minime au quotidien — les commandes ne changent pas. Le SHA-256 améliore la sécurité, le reftable améliore les performances sur les gros dépôts.

Bonnes pratiques au quotidien

Commits atomiques

Un commit = un changement logique. Pas de "fix + refactor + nouvelle feature" dans le même commit. Si vous devez écrire "et" dans le message, c'est probablement deux commits.

Pull Requests courtes

Les études montrent que les PRs de moins de 400 lignes sont reviewées plus rapidement et avec plus d'attention. Au-delà, les reviewers survolent et les bugs passent.

Le message explique le "pourquoi"

Le diff montre le "quoi" (le code changé). Le message de commit doit expliquer le "pourquoi" (la raison du changement). Un bon message : fix(cart): prevent negative quantity on product update. Un mauvais : fix bug.

Ne jamais committer de secrets

Clés API, mots de passe, tokens — même un git revert ne les supprime pas de l'historique. Utiliser un fichier .env (non committé) et un .gitignore strict. Les outils de CI/CD comme composer audit et les scans GitHub/GitLab détectent les secrets committés.

Git hooks pour automatiser

Les hooks Git exécutent des scripts avant ou après certaines actions. Les plus utiles :

pre-commit — Lint, analyse statique, détection de debug statements (dd(), var_dump())
commit-msg — Valide le format conventional commits
pre-push — Lance les tests avant de pousser

L'installation automatique via composer post-install-cmd garantit que chaque développeur a les hooks sans action manuelle.

Sécurité de la supply chain

Les dépôts Git ne sont pas à l'abri des attaques. En mars 2026, plusieurs incidents majeurs ont touché l'écosystème :

Compromission de Trivy (scanner de vulnérabilités) via des credentials volés — les tags de release ont été remplacés par du malware
Bypass de l'authentification 2FA sur GitLab (CVE-2026-0723)
Attaque supply chain npm découverte par GitLab avec un "dead man's switch"

Les bonnes pratiques : activer le 2FA, signer ses commits, auditer les dépendances (composer audit, npm audit), vérifier les sources avant d'ajouter une dépendance, et utiliser Dependabot ou Renovate pour les alertes automatiques.

Questions fréquentes

Git Flow ou trunk-based development ?

Le trunk-based development (tout le monde commit sur main via des branches courtes) est recommandé pour les équipes qui pratiquent le CI/CD. Git Flow reste pertinent pour les projets avec des releases versionnées (librairies, apps mobiles, logiciels on-premise). Pour un site web déployé en continu, le trunk-based est plus simple et plus rapide.

Faut-il signer ses commits ?

La signature de commits prouve que le code vient bien de vous, pas d'un imposteur. Depuis Git 2.34, la signature SSH est supportée nativement — c'est plus simple que GPG car vous avez déjà une clé SSH pour l'authentification. Sur les projets sensibles ou open-source, c'est une bonne pratique. En interne, c'est un plus mais pas indispensable.

GitHub ou GitLab : lequel choisir ?

GitHub domine le marché (~38%) avec le plus grand écosystème open-source et Copilot intégré. GitLab (~16%) excelle en auto-hébergement et en CI/CD intégré (pas besoin de service tiers). Pour un projet personnel ou open-source : GitHub. Pour une entreprise qui veut tout héberger en interne : GitLab.

Les conventional commits sont-ils obligatoires ?

Non, mais ils facilitent la lecture de l'historique, l'automatisation des changelogs et le semantic versioning. Le format type(scope): description est adopté par de plus en plus d'équipes. Un hook commit-msg peut l'enforcer automatiquement sans friction.

Pour aller plus loin

Git est un outil qu'on apprend une fois et qu'on affine toute sa carrière. Un bon workflow Git combiné à un pipeline CI/CD et des environnements Docker reproductibles forme la base d'un développement professionnel fiable.

L'arrivée de Git 3.0 fin 2026 et l'intégration croissante de l'IA dans les workflows (code review automatisée, coding agents) ne changent pas les fondamentaux : des commits propres, des branches courtes et un historique qui raconte l'histoire du projet.

Top