La question revient sur chaque nouveau projet : qu’est-ce qu’on met dans Git, exactement ? Un site WordPress mélange du code qui nous appartient (le thème, les plugins maison) et du code qui ne nous appartient pas (le cœur, les plugins tiers), plus des données qui n’ont rien à faire dans un dépôt (les uploads, la base). Sans règle claire, on finit avec des dépôts de plusieurs centaines de mégaoctets ou, pire, des conflits de fusion sur des fichiers générés.
Voici le découpage qu’on applique systématiquement, affiné après plusieurs projets où on avait fait les mauvais choix au démarrage — toujours plus coûteux à corriger a posteriori qu’à poser dès le premier commit.
Ce qui ne doit jamais entrer dans le dépôt
- Le cœur de WordPress (
wp-admin,wp-includes, les fichierswp-*.phpà la racine) : c’est du code tiers, géré par les mises à jour automatiques ou parwp core update. Le versionner revient à dupliquer un dépôt qui existe déjà sur SVN chez WordPress.org. - Les uploads (
wp-content/uploads) : ce sont des données, pas du code. Elles grossissent vite, changent en permanence et n’ont pas leur place dans un historique Git. On les gère par synchronisation de fichiers ou par un stockage externe. - La base de données : jamais en clair dans le dépôt. Elle contient des mots de passe hashés, parfois des données personnelles, et change à chaque commande, chaque commentaire, chaque connexion.
wp-config.php: il contient les identifiants de connexion à la base et les clés de sécurité, qui diffèrent entre environnements. On versionne plutôt unwp-config-sample.phpou on externalise la configuration dans des variables d’environnement.
Ce qu’on versionne systématiquement
À l’inverse, tout ce qui constitue le travail de développement doit être dans Git : le thème actif, les plugins développés en interne, et la configuration nécessaire pour reconstruire l’environnement.
# .gitignore type pour un projet WordPress
wp-admin/
wp-includes/
wp-content/uploads/
wp-content/cache/
wp-*.php
!wp-config-sample.php
.htaccess
wp-content/plugins/*
!wp-content/plugins/mon-plugin-maison/
wp-content/themes/*
!wp-content/themes/mon-theme/La logique des deux dernières lignes de chaque bloc est importante : on ignore tout le dossier plugins ou themes par défaut, puis on ajoute une exception explicite pour ce qu’on développe nous-mêmes. Ça évite qu’un plugin tiers installé par erreur se retrouve commité sans qu’on s’en aperçoive.
Le cas des plugins premium et tiers
Les plugins tiers posent un vrai dilemme. Les gérer via wp plugin update et les exclure de Git garde le dépôt propre, mais ça suppose une procédure de déploiement qui réinstalle systématiquement les bonnes versions. Une alternative plus robuste consiste à les déclarer comme dépendances Composer, avec un gestionnaire comme WPackagist pour les plugins gratuits — un sujet que je détaille dans un article dédié à Composer et WordPress.
Pour les plugins premium sans dépôt public, deux options : les commiter malgré tout (pragmatique, mais alourdit le dépôt et pose la question des mises à jour), ou les héberger sur un miroir privé accessible via Composer. Sur les petits projets, on commite encore ; sur les projets plus structurés, on est passés au miroir.
Un dépôt par projet, une structure claire
On travaille avec un dépôt Git à la racine du projet (pas seulement dans wp-content), ce qui permet d’inclure aussi les scripts de déploiement, la documentation interne et, le cas échéant, la configuration Composer. Voici la structure qu’on retrouve sur la plupart de nos projets :
| Élément | Versionné ? | Pourquoi |
|---|---|---|
| Thème maison | Oui | C’est le cœur du travail de développement |
| Plugin maison | Oui | Même raison, code métier spécifique au projet |
| Plugins WordPress.org | Non (ou via Composer) | Déjà versionnés en amont, réinstallables |
wp-config.php | Non | Contient des secrets propres à chaque environnement |
| Uploads | Non | Ce sont des données, pas du code |
| Scripts de déploiement | Oui | Font partie du projet au même titre que le code |
Un piège fréquent : les migrations de base oubliées
Un projet WordPress bien versionné donne une fausse impression de complétude : on peut recréer le code, mais pas l’état exact de la base au moment du commit. Pour les changements de structure (nouveaux champs ACF, options créées par un plugin maison), on documente les migrations dans un fichier dédié ou, mieux, on les exécute via une commande WP-CLI personnalisée jouée à chaque déploiement.
La règle qu’on répète à chaque nouvelle recrue : si le fichier peut être régénéré ou retéléchargé, il n’a rien à faire dans Git. Si sa perte ferait perdre du travail de développement, il doit y être.
En résumé
Versionner un site WordPress correctement, c’est accepter de séparer le code du contenu et la configuration des secrets. Un .gitignore bien construit, une structure de dépôt réfléchie dès le premier commit, et une stratégie claire pour les plugins tiers évitent la plupart des mauvaises surprises. C’est un investissement de dix minutes en début de projet qui économise des heures de nettoyage d’historique plus tard.
