# Push-to-deploy sur un VPS : déployer WordPress avec un simple hook Git

> Un dépôt bare, un hook post-receive et un `git push` qui met le site en ligne : la méthode de déploiement la plus simple à mettre en place sur un VPS.

- Auteur : Clément Hadrot
- Publié le : 2020-02-26
- Mis à jour le : 2020-02-26
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/push-to-deploy-vps-hook-git/

## L’essentiel

- Dépôt bare distant comme cible de push
- Hook post-receive pour installer et basculer
- Zéro outil tiers, juste Git et bash

Sur un projet client hébergé sur un VPS OVH, l'équipe utilisait encore FileZilla pour mettre en ligne les mises à jour. Chaque déploiement prenait un quart d'heure et laissait toujours un doute : a-t-on bien copié tous les fichiers modifiés ? La solution la plus simple, avant même d'envisager un outil comme Deployer, tient en un dépôt Git bare et un hook `post-receive`.

Ce mécanisme existe depuis les débuts de Git et ne demande aucune dépendance supplémentaire côté serveur. Il convient parfaitement à un petit ou moyen projet WordPress géré par une seule personne ou une petite équipe, sans complexité d'orchestration.

## Créer le dépôt bare sur le serveur

Sur le VPS, on crée un dépôt Git « nu », c'est-à-dire sans répertoire de travail, dédié à recevoir les pushs :

```
mkdir -p ~/repos/mon-site.git
cd ~/repos/mon-site.git
git init --bare
```

Ce dépôt ne contiendra jamais de fichiers visibles : il sert uniquement de point de réception. Le site lui-même vivra dans un dossier séparé, par exemple `/var/www/mon-site`, qui contient déjà WordPress installé et configuré (base de données, `wp-config.php`, éventuel `.htaccess`).

## Écrire le hook post-receive

> L'essentiel à retenir : Dépôt bare distant comme cible de push ; Hook post-receive pour installer et basculer ; Zéro outil tiers, juste Git et bash

Le fichier `hooks/post-receive` du dépôt bare est un script exécuté automatiquement à chaque réception d'un push. On y place la logique de déploiement :

```
#!/bin/bash
TARGET="/var/www/mon-site"
GIT_DIR="/root/repos/mon-site.git"

while read oldrev newrev ref
do
  if [ "$ref" = "refs/heads/main" ]; then
    echo "Déploiement de la branche main..."
    git --work-tree="$TARGET" --git-dir="$GIT_DIR" checkout -f main
    cd "$TARGET"
    composer install --no-dev --optimize-autoloader
    wp cache flush --path="$TARGET/web/wp" --allow-root
  fi
done
```

Il faut le rendre exécutable :

```
chmod +x ~/repos/mon-site.git/hooks/post-receive
```

Le paramètre `--work-tree` indique où extraire les fichiers, et `--git-dir` précise l'emplacement du dépôt bare. Cette combinaison permet de « déposer » les fichiers d'une branche dans un répertoire qui n'est pas lui-même un dépôt Git classique.

## Configurer le dépôt local

Côté poste de développement, il suffit d'ajouter le VPS comme remote :

```
git remote add production ssh://user@monserveur.fr/~/repos/mon-site.git
git push production main
```

Chaque `git push production main` déclenche désormais le hook et met le site à jour. Le retour de la commande `push` affiche en direct la sortie du script, ce qui permet de repérer immédiatement une erreur Composer ou une commande WP-CLI en échec.

## Gérer les fichiers qui ne doivent pas être écrasés

Le `checkout -f` écrase tout fichier présent dans le répertoire de travail qui serait aussi suivi par Git. Il faut donc veiller à ce que `wp-config.php`, le dossier `wp-content/uploads` et les caches ne soient jamais versionnés — un `.gitignore` soigné à la racine du projet évite les mauvaises surprises. Un oubli classique : versionner un `wp-config.php` de développement qui écrase discrètement la configuration de production lors du premier déploiement.

- Ajouter `wp-config.php`, `wp-content/uploads/` et les fichiers de cache au `.gitignore`
- Garder un `wp-config-sample.php` versionné comme référence
- Vérifier avec `git status` côté serveur qu'aucun fichier local n'a été modifié entre deux déploiements

## Limites de la méthode

Ce mécanisme n'offre ni rollback automatique, ni bascule atomique : pendant l'exécution de `composer install`, le site peut afficher des erreurs si un visiteur charge une page au mauvais moment. Sur un site à fort trafic, mieux vaut basculer vers un système de releases horodatées avec lien symbolique, mais pour un site vitrine ou un blog à trafic modéré, ce compromis reste largement acceptable.

> Sur les petits projets, je préfère toujours commencer par un hook Git basique. On migre vers un outil plus sophistiqué seulement quand la douleur devient réelle — pas avant.

## En résumé

Un dépôt bare et un script `post-receive` suffisent à transformer un simple `git push` en déploiement complet, sans FTP, sans outil tiers, sans abonnement à un service externe. C'est la solution à connaître avant de complexifier son infrastructure : elle a l'avantage d'être entièrement lisible, modifiable en cinq minutes, et de ne dépendre que de Git lui-même, déjà installé sur toute machine de développement.