Déployer son site via Git (git pull, hook post-receive, CI GitLab)

Déployer un site en glissant-déposant des fichiers dans FileZilla, ça marche. Mais dès qu'on travaille à plusieurs, qu'on veut pouvoir revenir en arrière ou qu'on a besoin de tracer ce qui part en prod, Git change la donne. Voici quatre approches, de la plus simple à la plus automatisée, toutes compatibles avec un hébergement Plesk Datacampus ou un VPS.

Pourquoi abandonner le SFTP

Le SFTP fait circuler des fichiers, pas de l'information. Dès que le projet dépasse la landing page, ça coince :

• Historique : Git sait qui a modifié quoi, quand, pourquoi. Le SFTP ne sait rien.
• Rollback : un git reset --hard <sha> annule un déploiement foireux en deux secondes. En SFTP, on prie.
• Travail d'équipe : deux développeurs qui éditent le même fichier via SFTP, c'est une course aux écrasements. Git gère les merges.
• Intégration continue : tests, lint, build des assets, notifications Slack, purge CDN — tout ça devient scriptable dans une pipeline.
• Reproductibilité : même état de code en préprod et en prod, garanti par un SHA commun.

Quatre méthodes, à choisir selon la maturité de l'équipe et la complexité du projet.

Méthode 1 — git pull manuel côté serveur

La plus simple. Vous clonez votre dépôt une fois sur le serveur, puis vous lancez git pull quand vous voulez déployer. Idéal pour un freelance qui bosse seul, ou pour tester la bascule Git.

Cloner la première fois

Connectez-vous en SSH (voir SSH & SFTP), placez-vous dans le DocumentRoot et clonez :

cd /var/www/vhosts/monsite.fr/httpdocs
git clone git@gitlab.datacampus.fr:agence/monsite.git .

Le point final est important : il clone dans le répertoire courant sans créer de sous-dossier monsite/. Si le répertoire n'est pas vide (fichier index.html par défaut de Plesk, par exemple), supprimez-le avant ou clonez ailleurs puis déplacez.

Pour que la clé SSH du serveur puisse cloner depuis GitLab, ajoutez la clé publique du compte Linux de votre domaine (cat ~/.ssh/id_ed25519.pub) en Deploy Key sur le projet GitLab, en lecture seule.

Mettre à jour

cd /var/www/vhosts/monsite.fr/httpdocs
git pull

Gérer les permissions après pull

Chez Datacampus, chaque site tourne sous son propre utilisateur Linux dédié (PHP-FPM isolé par pool), pas sous www-data. Si vous clonez en tant qu'utilisateur root ou que votre processus CI pose des fichiers en tant qu'un autre user, PHP ne pourra plus lire ou écrire. Après chaque déploiement, on remet l'ownership au user du site :

USER=$(stat -c '%U' .)
chown -R "$USER:$USER" .

La première ligne récupère automatiquement le nom du propriétaire du dossier courant, la seconde l'applique récursivement. À intégrer dans un script deploy.sh pour ne jamais l'oublier.

Méthode 2 — intégration Git de Plesk

Plesk embarque une intégration Git native. Zéro ligne de commande, parfait pour un client non-technique qui doit pouvoir re-déployer sans appeler l'agence.

1. Dans Plesk, ouvrez Sites Web & Domaines > votre domaine > Git.
2. Cliquez sur Ajouter un dépôt.
3. Choisissez Dépôt distant, collez l'URL SSH ou HTTPS du projet GitLab.
4. Plesk génère une clé SSH propre au domaine — copiez-la et ajoutez-la en Deploy Key sur GitLab.
5. Sélectionnez la branche (main) et le dossier cible (httpdocs par défaut).
6. Activez Déploiement automatique lors du push : Plesk fournit une URL de webhook à déclarer côté GitLab (Settings > Webhooks).

Méthode 3 — webhook + hook post-receive

Ici, votre serveur héberge lui-même un dépôt Git bare. Vous poussez dessus, un hook se déclenche, et le code est copié dans le DocumentRoot. Pas de GitLab intermédiaire requis, le serveur est lui-même la remote.

Créer le dépôt bare

cd ~
mkdir -p repos && cd repos
git init --bare monsite.git

Écrire le hook post-receive

Dans ~/repos/monsite.git/hooks/post-receive, créez un script exécutable :

#!/bin/bash
set -e
TARGET="/var/www/vhosts/monsite.fr/httpdocs"
GIT_DIR="/home/user/repos/monsite.git"
BRANCH="main"

while read oldrev newrev ref; do
    if [[ $ref = refs/heads/$BRANCH ]]; then
        echo "Déploiement de $BRANCH vers $TARGET"
        git --work-tree="$TARGET" --git-dir="$GIT_DIR" checkout -f "$BRANCH"
        # Étapes optionnelles : composer, npm, cache
        cd "$TARGET" && composer install --no-dev --optimize-autoloader
    fi
done

Rendez-le exécutable : chmod +x ~/repos/monsite.git/hooks/post-receive.

Configurer la remote côté machine locale

git remote add prod ssh://user@serveur.datacampus.fr/home/user/repos/monsite.git
git push prod main

Chaque git push prod main déclenche le hook et met la prod à jour. Vous pouvez avoir plusieurs remotes : origin pour GitLab (source de vérité), prod pour le déploiement direct.

Méthode 4 — pipeline GitLab CI/CD

La méthode industrielle. GitLab exécute une pipeline à chaque push, qui se connecte en SSH au serveur et déploie. C'est la voie royale pour une agence : tests, build, déploiements multi-environnements, notifications, tout est versionné dans le projet.

Préparer la clé SSH de déploiement

1. Sur votre poste (ou en local CI), générez une paire dédiée : ssh-keygen -t ed25519 -f deploy_key -N "" (sans passphrase pour que la CI puisse l'utiliser).
2. Ajoutez deploy_key.pub dans ~/.ssh/authorized_keys du user Linux de votre domaine (via Plesk > Accès SSH).
3. Dans GitLab : projet > Settings > CI/CD > Variables. Ajoutez SSH_PRIVATE_KEY (contenu de deploy_key, type File, masquée et protégée).
4. Ajoutez aussi SSH_USER et SSH_HOST en variables standard.

Le fichier .gitlab-ci.yml

stages:
  - build
  - deploy

build:
  stage: build
  image: node:20-alpine
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 week

deploy:
  stage: deploy
  image: alpine:latest
  before_script:
    - apk add --no-cache openssh-client rsync
    - eval $(ssh-agent -s)
    - chmod 600 "$SSH_PRIVATE_KEY"
    - ssh-add "$SSH_PRIVATE_KEY"
    - mkdir -p ~/.ssh && ssh-keyscan -H "$SSH_HOST" >> ~/.ssh/known_hosts
  script:
    - ssh $SSH_USER@$SSH_HOST "cd /var/www/vhosts/monsite.fr/httpdocs && git pull"
    - rsync -avz --delete dist/ $SSH_USER@$SSH_HOST:/var/www/vhosts/monsite.fr/httpdocs/dist/
  only:
    - main

À chaque push sur main, GitLab compile les assets puis pousse le résultat en prod. La clé privée reste chiffrée dans les variables, jamais commitée.

Bonnes pratiques

.gitignore sérieux

Tout ce qui est secret, généré ou volumineux n'a rien à faire dans Git. Exemples à exclure systématiquement :

# Secrets
.env
.env.local
wp-config.php        # WordPress : config DB en dehors du dépôt
config/database.yml  # Rails, Symfony, etc.

# Dépendances
node_modules/
vendor/              # Composer : si vous build en CI
/bower_components/

# Générés
dist/                # Sauf si vous voulez commit le build
.cache/
*.log

# OS & éditeurs
.DS_Store
Thumbs.db
.idea/
.vscode/

Pour les clés d'API et config sensibles, versionnez un .env.example (sans les valeurs), que chaque environnement copie en .env avec ses propres secrets.

Build en CI, pas sur le serveur

Compiler du Sass, bundler du JS ou faire tourner composer install directement en prod, c'est lent, ça nécessite d'installer des outils lourds sur le serveur web, et ça bloque le site pendant le build. Mieux : la CI build, produit un artefact (dossier dist/), et le serveur ne fait que récupérer le résultat.

Rollback

Noter le SHA avant chaque déploiement (la pipeline peut l'envoyer sur Slack). En cas de pépin, un simple :

cd /var/www/vhosts/monsite.fr/httpdocs
git reset --hard <sha-precedent>

… remet le site dans son état précédent. Combiné avec des sauvegardes DB, c'est un vrai filet de sécurité.

Hooks de post-déploiement

Après le git pull ou le rsync, enchaînez les étapes qui dépendent de la mise en ligne :

• Purger le cache CDN : curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE/purge_cache" -H "Authorization: Bearer $CF_TOKEN" -d '{"purge_everything":true}'
• Vider le cache applicatif : wp cache flush (WordPress), php artisan cache:clear (Laravel), bin/console cache:clear --env=prod (Symfony)
• Notifier Slack ou Mattermost : curl -X POST "$SLACK_WEBHOOK" -d '{"text":"Déploiement prod OK — commit abc123"}'
• Migrations DB : php artisan migrate --force, bin/console doctrine:migrations:migrate --no-interaction

Pièges classiques

# Dans .htaccess
RedirectMatch 404 /\.git

Récapitulatif : quelle méthode choisir ?

• Solo, peu de pushs : méthode 1 (git pull manuel). Simple, transparent.
• Client non-technique qui déploie lui-même : méthode 2 (Plesk Git). UI clicodrome, zéro SSH à gérer.
• Dev avancé sans GitLab ni CI : méthode 3 (hook post-receive). Élégant, autonome.
• Agence, multi-devs, tests, build, notifications : méthode 4 (GitLab CI). Industrielle, auditée, reproductible.

On bascule d'une méthode à l'autre sans tout jeter : un projet démarre souvent en méthode 1, puis s'industrialise vers la 4 à mesure que l'équipe grandit. L'important, c'est de sortir du SFTP au plus vite.