Git pour un développeur WordPress : workflow en 2026 avec hooks et CI

Pendant mes premières années de freelance, je déployais mes sites WordPress en FTP. Un glisser-déposer de fichiers dans FileZilla, une prière silencieuse, et on croisait les doigts pour que rien ne casse en production. En 2026, je ne touche plus jamais à un client FTP. Git a transformé ma façon de travailler sur WordPress, et les hooks combinés à la CI/CD ont éliminé une catégorie entière de bugs que je découvrais autrefois après la mise en ligne.

Ce guide documente le workflow exact que j utilise sur mes projets clients. Pas de théorie abstraite : du concret, avec les fichiers de configuration, les commandes, et les pièges que j ai rencontrés sur de vrais projets.

Pourquoi Git est devenu indispensable pour un développeur WordPress en 2026

WordPress représente encore 43 % des sites web selon les données de W3Techs, et pourtant une grande partie des développeurs WordPress travaillent encore sans versionning. Le problème n est pas Git lui-même : c est que l écosystème WordPress a longtemps encouragé le bricolage direct sur le serveur. Modifier un fichier functions.php en production via l éditeur intégré, c était normal. En 2026, c est une faute professionnelle.

Voici ce que Git apporte concrètement à un projet WordPress :

• Historique complet de chaque modification, avec la raison du changement dans le message de commit
• Retour arrière instantané si un déploiement casse quelque chose (un simple git revert suffit)
• Collaboration sécurisée quand un autre développeur intervient sur le projet
• Déploiement reproductible : le même code, déployé de la même façon, à chaque fois
• Traçabilité contractuelle : en cas de litige avec un client, le log Git prouve exactement qui a modifié quoi

J ai décrit dans mon article sur les clauses indispensables des contrats freelance pourquoi la livraison d un dépôt Git versionné devrait figurer dans chaque devis. C est aussi une question de professionnalisme : un client qui reçoit un zip par e-mail ne peut pas auditer le travail réalisé.

Structurer son .gitignore et son dépôt WordPress correctement

La première erreur que je vois chez les développeurs WordPress qui adoptent Git, c est de versionner l intégralité du répertoire WordPress. Le core WordPress n a pas sa place dans votre dépôt. Il se met à jour via WP-CLI ou Composer, pas via Git. Comme je l explique dans mon guide sur les commandes WP-CLI essentielles, wp core update gère ça proprement.

Voici le .gitignore que j utilise sur tous mes projets :

# Core WordPress
/wp-admin/
/wp-includes/
/wp-*.php
/index.php
/license.txt
/readme.html
/xmlrpc.php

# Configuration sensible
wp-config.php
.env
*.sql

# Uploads (trop lourds, sauvegardés séparément)
wp-content/uploads/

# Plugins tiers (gérés par Composer)
wp-content/plugins/*
!wp-content/plugins/mon-plugin-custom/

# Thèmes tiers
wp-content/themes/*
!wp-content/themes/mon-theme-custom/

# Cache et fichiers générés
wp-content/cache/
wp-content/upgrade/
wp-content/advanced-cache.php
wp-content/object-cache.php

# Système
.DS_Store
Thumbs.db
node_modules/
*.log

Ce que je versionne, c est uniquement ce que j ai écrit : le thème custom, les mu-plugins maison, le fichier composer.json qui gère les dépendances, et les fichiers de configuration CI. Tout le reste est soit géré par un gestionnaire de paquets, soit sauvegardé autrement. Pour la sauvegarde des uploads et de la base de données, j ai détaillé ma méthode dans l article sur les sauvegardes WordPress avec rsync.

La structure type d un dépôt WordPress propre ressemble à ça :

mon-projet-wp/
├── wp-content/
│   ├── themes/mon-theme-custom/
│   ├── mu-plugins/
│   └── plugins/mon-plugin-custom/
├── composer.json
├── .gitignore
├── .github/workflows/deploy.yml
├── phpcs.xml
└── README.md

Quel modèle de branching choisir quand on est freelance

J ai longtemps utilisé Gitflow (develop, release, hotfix, feature branches). C est un modèle robuste pour les grosses équipes, mais complètement surdimensionné pour un freelance ou une petite agence. En 2026, je recommande GitHub Flow pour 95 % des projets WordPress freelance.

Le principe est simple :

• La branche main est toujours déployable en production
• Pour chaque fonctionnalité ou correction, je crée une branche feature/nom-descriptif
• Je travaille sur cette branche, je commite régulièrement
• Quand c est prêt, je merge dans main (avec ou sans pull request selon le contexte)
• Le merge dans main déclenche automatiquement le déploiement via CI/CD

Pour les projets avec un environnement de staging, j ajoute une branche staging qui déclenche un déploiement vers le serveur de recette. C est utile quand le client doit valider avant la mise en production, ce qui arrive sur 80 % de mes projets.

La convention de nommage que j utilise :

feature/ajout-formulaire-contact
fix/bug-menu-mobile
hotfix/faille-securite-upload
chore/mise-a-jour-php-8.3

Ces préfixes ne sont pas juste cosmétiques : ils permettent aux hooks Git et à la CI de déclencher des actions différentes selon le type de branche.

Les hooks Git essentiels pour un projet WordPress

Les hooks Git sont des scripts qui s exécutent automatiquement à certains moments du workflow Git. Côté client, ils servent de filet de sécurité avant que le code ne quitte votre machine. Côté serveur, ils peuvent déclencher des déploiements ou des vérifications supplémentaires.

Voici les hooks que j installe systématiquement sur mes projets WordPress :

pre-commit : bloquer les erreurs avant le commit

Ce hook vérifie la syntaxe PHP, détecte les var_dump et error_log oubliés, et lance PHP_CodeSniffer avec les standards WordPress :

#!/bin/sh
# .git/hooks/pre-commit

# Vérifier la syntaxe PHP
FILES=$(git diff --cached --name-only --diff-filter=ACM | grep '\.php$')
if [ -n "$FILES" ]; then
    for FILE in $FILES; do
        php -l "$FILE" > /dev/null 2>&1
        if [ $? -ne 0 ]; then
            echo "Erreur de syntaxe PHP dans $FILE"
            exit 1
        fi
    done
fi

# Détecter les debug statements oubliés
if git diff --cached --name-only | xargs grep -l 'var_dump\|error_log\|print_r' 2>/dev/null; then
    echo "Debug statements détectés. Retirez-les avant de commiter."
    exit 1
fi

# PHPCS avec les standards WordPress
if command -v phpcs > /dev/null 2>&1; then
    phpcs --standard=WordPress --extensions=php $FILES
    if [ $? -ne 0 ]; then
        echo "Violations PHPCS détectées."
        exit 1
    fi
fi

exit 0

commit-msg : imposer un format de message

Des messages de commit comme « fix » ou « update » ne servent à rien six mois plus tard. Ce hook impose un format conventionnel :

#!/bin/sh
# .git/hooks/commit-msg

COMMIT_MSG=$(cat "$1")
PATTERN='^(feat|fix|chore|docs|style|refactor|test|hotfix): .{10,}$'

if ! echo "$COMMIT_MSG" | grep -qE "$PATTERN"; then
    echo "Format de commit invalide."
    echo "Utilisez : type: description (min 10 caractères)"
    echo "Types : feat, fix, chore, docs, style, refactor, test, hotfix"
    exit 1
fi

exit 0

pre-push : vérifier avant d envoyer

Ce hook lance les tests PHPUnit avant d autoriser le push vers le dépôt distant. C est le dernier rempart avant la CI :

#!/bin/sh
# .git/hooks/pre-push

if [ -f "vendor/bin/phpunit" ]; then
    vendor/bin/phpunit --configuration phpunit.xml
    if [ $? -ne 0 ]; then
        echo "Les tests échouent. Push annulé."
        exit 1
    fi
fi

exit 0

Pour partager ces hooks avec d autres développeurs sur le projet, je les place dans un répertoire .githooks/ à la racine du dépôt et je configure Git en conséquence :

git config core.hooksPath .githooks

Cette commande fait partie de mon script d initialisation de projet, aux côtés des commandes WP-CLI que je décris dans mon guide WP-CLI.

Mettre en place un pipeline CI/CD pour WordPress

Les hooks côté client sont utiles, mais ils peuvent être contournés (un --no-verify et c est réglé). La CI/CD côté serveur est le vrai gardien de la qualité. Voici le pipeline GitHub Actions que j utilise sur mes projets WordPress en 2026 :

# .github/workflows/wordpress-ci.yml
name: WordPress CI/CD

on:
  push:
    branches: [main, staging]
  pull_request:
    branches: [main]

jobs:
  lint-and-test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        php-version: ['8.2', '8.3']

    steps:
      - uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: ${{ matrix.php-version }}
          extensions: mysqli, mbstring, intl
          tools: composer, phpcs, phpunit

      - name: Install dependencies
        run: composer install --no-dev --prefer-dist

      - name: Run PHPCS
        run: phpcs --standard=WordPress wp-content/themes/mon-theme-custom/

      - name: Run PHPStan
        run: vendor/bin/phpstan analyse wp-content/themes/mon-theme-custom/ --level=5

      - name: Run PHPUnit
        run: vendor/bin/phpunit

  deploy-staging:
    needs: lint-and-test
    if: github.ref == 'refs/heads/staging'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to staging
        uses: easingthemes/ssh-deploy@v5
        with:
          SSH_PRIVATE_KEY: ${{ secrets.SSH_KEY }}
          REMOTE_HOST: ${{ secrets.STAGING_HOST }}
          REMOTE_USER: ${{ secrets.STAGING_USER }}
          SOURCE: "wp-content/themes/mon-theme-custom/"
          TARGET: "/var/www/staging/wp-content/themes/mon-theme-custom/"

  deploy-production:
    needs: lint-and-test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to production
        uses: easingthemes/ssh-deploy@v5
        with:
          SSH_PRIVATE_KEY: ${{ secrets.SSH_KEY }}
          REMOTE_HOST: ${{ secrets.PROD_HOST }}
          REMOTE_USER: ${{ secrets.PROD_USER }}
          SOURCE: "wp-content/themes/mon-theme-custom/"
          TARGET: "/var/www/prod/wp-content/themes/mon-theme-custom/"
          SCRIPT_AFTER: "cd /var/www/prod && wp cache flush"

Ce pipeline fait trois choses : il vérifie le code (linting + tests), il déploie sur staging quand on pousse sur la branche staging, et il déploie en production quand on merge dans main. Le tout en moins de 2 minutes sur GitHub Actions.

Le SCRIPT_AFTER sur le déploiement production exécute un wp cache flush après la copie des fichiers. Si vous utilisez un VPS OVH comme je le décris dans mon tutoriel de déploiement WordPress sur VPS, cette commande est essentielle pour que les modifications soient visibles immédiatement.

Déploiement automatisé vers la production

Le déploiement SSH via rsync reste ma méthode préférée en 2026. Certains développeurs utilisent des solutions comme Deployer (deployer.org) ou Capistrano, mais pour un site WordPress standard, rsync via SSH est largement suffisant et ne nécessite aucune dépendance supplémentaire sur le serveur.

Le processus complet d un déploiement automatisé ressemble à ça :

1. Le développeur merge sa feature branch dans main
2. GitHub Actions détecte le push et lance le pipeline
3. Les tests passent (PHPCS, PHPStan, PHPUnit)
4. Le job de déploiement copie les fichiers modifiés via SSH/rsync
5. Le script post-déploiement vide le cache et vérifie que le site répond

Pour la vérification post-déploiement, j ajoute un health check simple :

SCRIPT_AFTER: |
  cd /var/www/prod
  wp cache flush
  HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" https://monsite.fr)
  if [ "$HTTP_CODE" != "200" ]; then
    echo "ALERTE: le site retourne $HTTP_CODE"
    exit 1
  fi

Si le health check échoue, le pipeline retourne une erreur et je reçois une notification. Sur un projet avec de l automatisation plus poussée, j ai documenté comment intégrer des API externes dans WordPress pour envoyer une alerte Slack ou un e-mail en cas de problème.

Comparatif GitHub, GitLab et Bitbucket pour un dev WordPress

Le choix de la plateforme Git dépend de vos besoins en CI/CD, du nombre de collaborateurs, et de votre budget. Voici le comparatif basé sur mon expérience en 2026 :

Pour un développeur WordPress freelance, GitHub reste le choix par défaut en 2026. Les 2 000 minutes de CI gratuites couvrent largement les besoins d un freelance solo, et l intégration avec des outils comme GitHub Copilot ou Claude Code accélère considérablement le développement quotidien.

GitLab est pertinent si vous avez besoin d héberger le dépôt sur votre propre serveur, par exemple pour des clients dans des secteurs réglementés. La CNIL rappelle régulièrement les obligations liées au stockage de données sur des serveurs hors UE, et certains clients exigent un hébergement souverain du code source.

Les erreurs fréquentes qui sabotent un workflow Git WordPress

En onze ans de freelance, j ai commis (et vu commettre) à peu près toutes les erreurs possibles avec Git sur WordPress. Voici les plus courantes et comment les éviter :

1. Versionner wp-config.php avec les credentials en clair. C est la pire erreur de sécurité possible. Utilisez des variables d environnement ou un fichier .env exclu du dépôt. Le guide OWASP sur la gestion des secrets détaille les bonnes pratiques à suivre.

2. Commiter le répertoire uploads/. Les médias WordPress n ont pas leur place dans Git. Un dépôt de 500 Mo à cause de photos non optimisées, c est un cauchemar à cloner. Pour la gestion des médias, j ai documenté mes recommandations dans l article sur l optimisation des images WordPress en WebP et AVIF.

3. Travailler directement sur main. Même seul sur un projet, prenez l habitude de créer une branche. Le jour où un hotfix urgent arrive pendant que vous êtes en plein refactoring, vous serez content d avoir une branche main propre.

4. Ignorer les conflits de base de données. Git versionne les fichiers, pas la base de données. Si votre workflow implique des changements ACF ou des options WordPress, utilisez des fichiers de migration JSON synchronisés via Git, ou des outils comme WP Migrate.

5. Ne pas documenter le README. Votre futur vous (ou le développeur qui reprendra le projet) a besoin de savoir comment installer, configurer et déployer le projet. Un README avec les commandes d installation, les prérequis et la procédure de déploiement, c est le minimum.

6. Utiliser des hooks sans les partager. Si vos hooks sont dans .git/hooks/, ils restent locaux. Déplacez-les dans .githooks/ et configurez core.hooksPath pour que chaque développeur qui clone le projet bénéficie des mêmes garde-fous.

7. Négliger la CI parce que « c est un petit projet ». Un pipeline qui prend 30 minutes à configurer vous évitera des heures de débogage. Même un site vitrine mérite un php -l automatisé et un phpcs basique.

Pour aller plus loin sur l automatisation des tâches récurrentes, j ai comparé n8n, Make et Zapier dans un article dédié. Certains de ces outils peuvent compléter votre pipeline CI en déclenchant des actions post-déploiement (notification client, mise à jour d un Trello, etc.).