Git pour un site web : versionner sans être développeur

Modifier un fichier CSS, actualiser une page, changer un bout de code dans un thème WordPress : chaque intervention sur un site web comporte un risque. Un caractère en trop, une accolade oubliée, et le site affiche une page blanche. Sans outil de versionnement, la seule solution est de fouiller dans ses sauvegardes FTP en priant pour retrouver la bonne version. Git élimine ce problème en photographiant l’état exact de chaque fichier à chaque étape, et en permettant de revenir en arrière en une seule commande.

Pourquoi versionner son site web

Imaginez la situation : vous modifiez le fichier style.css de votre thème pour ajuster la taille d’un titre. Tout semble fonctionner. Deux jours plus tard, vous remarquez que la mise en page du formulaire de contact est cassée. Impossible de vous souvenir de ce que vous avez changé exactement. Sans versionnement, vous êtes coincé.

Le versionnement résout trois problèmes concrets que rencontre toute personne qui gère un site web :

• La traçabilité : chaque modification est datée, commentée et attribuée à son auteur. On sait qui a changé quoi, quand, et pourquoi.
• La réversibilité : revenir à un état précédent prend quelques secondes. Plus besoin de conserver des dossiers “site_backup_v2_final_FINAL”.
• La collaboration : si plusieurs personnes travaillent sur le même site, Git fusionne automatiquement les modifications et signale les conflits.

Même si vous êtes seul à gérer votre site, le versionnement vous protège de vos propres erreurs. Selon une documentation officielle de Git, l’outil est utilisé par plus de 90 % des développeurs dans le monde. Mais contrairement à ce que beaucoup croient, il n’est pas réservé aux développeurs chevronnés. Si vous savez ouvrir un terminal et taper une commande, vous pouvez utiliser Git.

J’ai accompagné des dizaines de clients non techniques dans cette transition au fil de mes années en agence web, et la plupart maîtrisaient les bases en moins d’une journée.

Git en termes simples : ce que fait réellement l’outil

Git est un système de contrôle de version décentralisé. Derrière ce terme technique se cache un mécanisme simple : Git surveille un dossier sur votre ordinateur et enregistre chaque changement que vous lui demandez de sauvegarder.

Voici une analogie qui fonctionne bien : pensez à Git comme à la fonction “Historique des versions” de Google Docs, mais appliquée à tous les fichiers d’un dossier simultanément. Chaque sauvegarde volontaire s’appelle un commit. Chaque commit contient la liste exacte des lignes ajoutées, modifiées ou supprimées.

Quelques termes à connaître avant de commencer :

• Dépôt (repository) : le dossier de votre site, une fois initialisé avec Git. Il contient un sous-dossier caché .git qui stocke tout l’historique.
• Commit : une photo horodatée de l’état de vos fichiers. Chaque commit possède un identifiant unique.
• Branche : une ligne de développement parallèle. La branche principale s’appelle généralement main.
• Remote : une copie distante de votre dépôt, hébergée sur un service comme GitHub ou GitLab.
• Push / Pull : envoyer vos commits vers le dépôt distant, ou récupérer les commits des autres.

L’important à retenir : Git ne sauvegarde pas automatiquement. C’est vous qui décidez quand créer un commit. Cela vous donne un contrôle total sur l’historique de votre projet.

Installer Git sur son ordinateur en quelques minutes

L’installation de Git est rapide quel que soit votre système d’exploitation. Voici la marche à suivre selon votre environnement.

Sur Windows

Téléchargez l’installateur depuis le site officiel de Git. Lancez le fichier .exe et conservez les options par défaut. L’installation inclut Git Bash, un terminal qui vous permettra d’utiliser les commandes Git. Pour vérifier que tout fonctionne, ouvrez Git Bash et tapez :

git --version

Vous devriez voir s’afficher quelque chose comme git version 2.45.0.

Sur macOS

Ouvrez le Terminal (Applications > Utilitaires > Terminal) et tapez git --version. Si Git n’est pas installé, macOS vous proposera d’installer les Xcode Command Line Tools, qui incluent Git. Acceptez et patientez quelques minutes.

Sur Linux

Utilisez le gestionnaire de paquets de votre distribution. Sur Ubuntu ou Debian : sudo apt install git. Sur Fedora : sudo dnf install git.

Configuration initiale

Après l’installation, configurez votre identité. Ces informations apparaîtront dans chaque commit :

git config --global user.name "Votre Nom"
git config --global user.email "[email protected]"

Cette étape ne prend que 30 secondes et ne se fait qu’une seule fois. Si vous gérez un site avec un hébergeur qui propose un accès SSH, pensez aussi à vérifier la version de PHP installée sur votre serveur pour éviter les incompatibilités lors du déploiement.

Les trois commandes essentielles pour débuter

Sur les centaines de commandes que propose Git, trois suffisent pour 90 % des usages d’un gestionnaire de site web. Voici le flux de travail quotidien.

Étape 1 : initialiser le dépôt

Placez-vous dans le dossier de votre site et tapez :

cd /chemin/vers/mon-site
git init

Git crée un sous-dossier caché .git. Votre dossier est maintenant un dépôt versionné.

Étape 2 : ajouter les fichiers modifiés

Après avoir modifié un fichier (par exemple style.css), vous le préparez pour le commit avec git add :

git add style.css

Pour ajouter tous les fichiers modifiés d’un coup : git add . (le point signifie “tout le dossier courant”). Attention, cette commande ajoute tous les fichiers, y compris ceux que vous ne souhaitez peut-être pas versionner. D’où l’importance du fichier .gitignore que nous verrons plus loin.

Étape 3 : enregistrer le commit

git commit -m "Correction de la taille du titre H1 sur la page d'accueil"

Le message entre guillemets décrit ce que vous avez changé. Soyez précis et concret : “Correction du titre H1” est mieux que “Mise à jour CSS”.

Étape bonus : envoyer vers le dépôt distant

git push origin main

Cette commande envoie vos commits vers le dépôt distant (GitHub, GitLab). Elle n’est utile que si vous avez configuré un remote, ce que nous aborderons dans la section dédiée.

Configurer le fichier .gitignore pour un site web

Le fichier .gitignore indique à Git quels fichiers ou dossiers il doit ignorer complètement. Sans ce fichier, vous risquez de versionner des éléments qui n’ont rien à faire dans un dépôt : fichiers de cache, images uploadées par les utilisateurs, fichiers de configuration contenant des mots de passe.

Créez un fichier nommé .gitignore à la racine de votre projet et adaptez-le à votre type de site.

Exemple pour un site WordPress

# Uploads utilisateurs (trop volumineux, sauvegardés ailleurs)
wp-content/uploads/

# Cache des plugins
wp-content/cache/

# Configuration locale (contient les identifiants BDD)
wp-config.php

# Fichiers systeme
.DS_Store
Thumbs.db
*.log
node_modules/

Exemple pour un site statique ou HTML/CSS

# Fichiers systeme
.DS_Store
Thumbs.db

# Dependances
node_modules/
vendor/

# Fichiers compiles (si vous les regenerez)
dist/
build/

La règle d’or : ne versionnez que ce qui est nécessaire pour reconstruire le site. Les images uploadées par les utilisateurs, les fichiers de cache et les dépendances téléchargeables n’ont pas leur place dans Git. Pour optimiser les fichiers qui restent dans votre projet, pensez à minifier vos CSS et JS avant de les déployer. Et pour les images du thème, la compression au format WebP réduit considérablement le poids du dépôt.

Attention au fichier wp-config.php sur WordPress : il contient les identifiants de votre base de données. Le versionner sur un dépôt public exposerait vos mots de passe. Si vous devez versionner la configuration, utilisez un fichier wp-config-sample.php avec des valeurs fictives.

Travailler avec les branches sans risquer la production

Les branches sont l’un des concepts les plus puissants de Git, et aussi l’un des plus simples à comprendre. Une branche est une copie virtuelle de votre projet dans laquelle vous pouvez travailler sans affecter la version principale.

Prenons un exemple concret. Vous souhaitez refondre la page d’accueil de votre site, mais cette refonte va prendre plusieurs jours. Pendant ce temps, vous devez pouvoir corriger un bug urgent sur le site en production. Voici comment procéder :

# Creer une branche pour la refonte
git checkout -b refonte-accueil

# Travailler, commiter...
git add .
git commit -m "Nouvelle structure HTML de la page d'accueil"

# Revenir sur la branche principale pour corriger le bug
git checkout main
git commit -m "Correction du lien cassé dans le pied de page"

# Une fois la refonte terminée, fusionner
git checkout main
git merge refonte-accueil

Ce flux de travail garantit que la branche main reste toujours dans un état fonctionnel. Les modifications en cours de développement restent isolées jusqu’à ce qu’elles soient prêtes. Si la refonte échoue ou si vous changez d’avis, il suffit de supprimer la branche sans conséquence sur le site en ligne.

Je recommande de nommer vos branches de manière explicite : fix/lien-pied-de-page, feature/formulaire-contact, update/theme-2026. En un coup d’œil, on sait ce que contient chaque branche.

Héberger son dépôt en ligne : GitHub, GitLab ou Bitbucket

Avoir Git en local, c’est bien. Avoir une copie distante de son dépôt, c’est indispensable. Si votre disque dur lâche ou si votre ordinateur est volé, l’historique complet de votre site est perdu. Un dépôt distant sert à la fois de sauvegarde et de point de synchronisation si vous travaillez depuis plusieurs postes ou avec d’autres personnes.

Trois plateformes dominent le marché :

Pour un débutant qui gère un site web personnel ou vitrine, GitHub reste le choix le plus simple. La création d’un compte est gratuite et les dépôts privés sont illimités. Voici comment connecter votre dépôt local à GitHub :

# Sur GitHub, creez un nouveau depot (bouton "+" > "New repository")
# Puis dans votre terminal :
git remote add origin https://github.com/votre-nom/mon-site.git
git push -u origin main

À partir de ce moment, chaque git push enverra vos commits vers GitHub. Vos fichiers sont en sécurité, et vous pouvez les récupérer depuis n’importe quel ordinateur avec git clone.

Si la question de l’espace disque vous préoccupe, sachez que les dépôts Git de sites web dépassent rarement quelques centaines de mégaoctets, à condition de ne pas versionner les images uploadées.

Déployer son site depuis Git : du dépôt au serveur

Versionner son site est une chose ; le mettre en ligne en est une autre. Git peut aussi simplifier le déploiement, c’est-à-dire le transfert des fichiers depuis votre ordinateur (ou votre dépôt distant) vers le serveur d’hébergement.

Méthode 1 : déploiement manuel via SSH

Si votre hébergeur propose un accès SSH (c’est le cas sur la plupart des VPS et serveurs dédiés), vous pouvez cloner votre dépôt directement sur le serveur :

# Sur le serveur, via SSH
cd /var/www/mon-site
git pull origin main

À chaque mise à jour, il suffit de se connecter en SSH et de lancer git pull. C’est rudimentaire mais efficace pour un site simple.

Méthode 2 : déploiement automatique avec un webhook

GitHub et GitLab permettent de déclencher un script sur votre serveur à chaque push. Le serveur reçoit une notification et exécute automatiquement git pull. Cette méthode évite de se connecter manuellement en SSH après chaque modification.

Méthode 3 : déploiement via un service tiers

Des outils comme Deployer, Buddy ou les pipelines CI/CD de GitLab offrent des déploiements plus sophistiqués : exécution de tests, minification des assets, notification par email en cas d’erreur. Ces solutions sont plutôt destinées aux projets qui grandissent, mais elles restent accessibles.

Quel que soit le mode de déploiement choisi, Git vous garantit une chose : si la mise en production casse quelque chose, un simple git revert ou git checkout ramène le site à son état précédent en quelques secondes. Cette sécurité est inestimable quand on change d’hébergeur ou qu’on effectue une mise à jour importante.

Erreurs fréquentes et solutions rapides

Même avec les meilleures intentions, certaines erreurs reviennent régulièrement chez les débutants. Voici celles que je rencontre le plus souvent, et comment les résoudre.

“J’ai commité un fichier par erreur”

Si vous avez ajouté un fichier sensible (comme wp-config.php) dans un commit, le supprimer du dossier ne suffit pas : il reste dans l’historique Git. Pour le retirer proprement :

git rm --cached wp-config.php
echo "wp-config.php" >> .gitignore
git commit -m "Retrait de wp-config.php du versionnement"

Le fichier reste sur votre disque mais n’est plus suivi par Git.

“Git me dit que j’ai un conflit”

Un conflit survient quand deux modifications touchent la même ligne du même fichier. Git ne peut pas deviner laquelle garder. Il marque le fichier avec des indicateurs :

<<<<<<< HEAD
Votre version du code
=======
L'autre version du code
>>>>>>> branche-distante

Ouvrez le fichier, choisissez la bonne version (ou combinez les deux), supprimez les marqueurs, puis commitez. Les conflits semblent intimidants au début, mais ils deviennent routiniers avec la pratique.

“J’ai tout cassé, je veux revenir en arrière”

C’est exactement la situation où Git brille. Pour annuler le dernier commit sans perdre les modifications :

git reset --soft HEAD~1

Pour revenir à l’état exact du dernier commit et abandonner toutes les modifications en cours :

git checkout .

Cette dernière commande est irréversible : les modifications non commitées sont perdues. Utilisez-la avec précaution.

“Mon dépôt est devenu énorme”

C’est souvent le signe que des fichiers volumineux ont été versionnés par erreur (images, vidéos, sauvegardes SQL). Vérifiez votre .gitignore, nettoyez l’historique si nécessaire avec git filter-branch ou l’outil BFG Repo-Cleaner. Pour les images de votre site, préférez un stockage séparé (CDN, dossier non versionné) plutôt que de les inclure dans Git.

“Je ne sais plus où j’en suis”

Deux commandes pour retrouver vos repères :

git status    # Affiche les fichiers modifies, ajoutes, ignores
git log --oneline -10    # Affiche les 10 derniers commits

Prenez l’habitude de lancer git status avant et après chaque opération. C’est le meilleur moyen d’éviter les surprises. Si votre site devient lent après une modification, l’historique Git vous permettra d’identifier rapidement quel changement a causé le problème.