Pour les quelques sites internet que je gère, jusqu'à maintenant, je les modifiais directement sur la "prod". Ce sont généralement des sites qui ne sont utilisés que par moi ou bien, pour FredVoyage, un site peu souvent modifié, donc pas vraiment besoin de repo ou de versioning pour le moment.

Toutefois, pour bien utiliser les outils que j'ai à ma disposition, notamment Cursor ou même VSCode, l'utilisation d'un outil de versioning est indispensable pour 3 raisons :

1. Lorsqu'avec Cursor, des modifications se font automatiquement, en cas de gros problème, si je n'arrive pas à débugger et que Cursor non plus, alors ça permet de revenir en arrière plus facilement, et l'outil git est intégré à Cursor ou à VSCode, ce qui rend son utilisation très simple.
2. VSCode ou Cursor sont des IDE qui permettent de bien gérer les fichiers locaux. Ils indexent les fichiers, tous les fichiers, et pour des raisons pas forcément toujours compréhensibles, si les fichiers ne sont pas en local, mais en accès par fuse, ce qui permet de monter un système de fichier distant en local, alors l'indexation ne se termine jamais, et occupe beaucoup de bande passante voire de CPU. L'utilisation de git permet alors de mieux gérer les ressources de la machine.
3. Un 3ème avantage bonus, c'est que grâce à cet outil de versioning, il est possible de travailler en offline, avec une machine virtuelle par exemple, en local, qui permet d'émuler le serveur pour tester les versions en local. Ca permet à la fois de tester et de pouvoir se passer du réseau, ce qui est très utile lorsque la connexion est mauvaise (dans certains hôtels par exemple) ou en cas d'absence de réseau (train, avion, ...).

Toutefois pour mettre en place git pour un projet existant, c'est un peu plus compliqué que pour un projet qui commence, car il faut s'assurer qu'aucun fichier ne soit perdu, et que cela ne perturbe pas le fonctionnement du site. Aussi, voici ma méthode pour mettre en place git sur mon serveur.

Petite convention d'écriture toute simple et assez commune : les lignes qui commencent par un dollar ($) sont à entrer avec un utilisateur qui n'est pas root ou pas forcément root. Celles qui utilisent un dièse (#) sont à entrer en tant que root. Si la ligne ne commence ni par l'un ni par l'autre, cela représente alors le contenu d'un fichier ou la réponse du serveur (notamment avec un signe plus grand que).

Projet local

A noter, avant de détailler cela, que git ne permet pas de faire juste une synchronisation. En local, il est possible, assez facilement, de mettre git sur un dossier pour faire du versioning sur ce dossier. On fait alors un git commit, pas besoin de push, et la mise à jour se fait facilement. Pour cela, il suffit d'aller dans le dossier et d'entrer la commande suivante pour créer le repo :

$ git init

Ensuite, on ajoute tous les fichiers :

$ git add --all

Et on fait le premier commit qui va valider l'ensemble des fichiers :

$ git commit -m "Premier commit"

Il est possible, et d'ailleurs recommandé de créer, avant cela, un fichier .gitignore, qui est un simple fichier texte, qui va contenir l'ensemble des fichiers et dossiers que l'on ne veut pas synchroniser. Voici la commande pour créer le fichier, dans le même dossier que le projet :

$ vi .gitignore

Et voici un exemple de ce que l'on peut mettre dedans :

.git/*
.gitignore

Une fois en place, dans VSCode ou dans Cursor, on peut alors utiliser l'outil de gestion de git et faire des commit à chaque fois que l'on fait une modification, ce qui permet de gérer les versions des fichiers et revenir en arrière ou voir les différences, ce qui peut s'avérer parfois très utile.

Cette solution fonctionne très bien pour des projets compilés, comme une application pour Android par exemple, pour laquelle il n'y a pas de fichiers à transférer, mais uniquement la partie gestion des versions à utiliser, c'est comme ça que j'utilise cette manière d'utiliser git.

Projet Web

Pour un projet web, en revanche, c'est un peu différent. C'est aussi là que l'on peut utiliser toute la puissance de git, et parfois, c'est aussi utile d'utiliser une interface web pour cela, par exemple Gitlab. J'utilise cela de manière professionnel, pour les projets d'envergure, avec plusieurs développeurs qui travaillent dessus, et l'avantage de Gitlab est que l'on peut à la fois gérer le code, avec git et une interface web qui permet de comparer les version et de gérer des branches ou des forks, mais aussi d'organiser le travail en créant des issues et en utilisant des tableaux Kaban.

Gitlab est donc totalement adapté pour un usage en entreprise ou communautaire, mais pour les sites que je gère, généralement il n'y a que 2 ou 3 utilisateurs et une petite interface, donc pas besoin d'outil de gestion de tickets, je corrige les bugs en temps réel et ça fonctionne très bien. Donc, sans gitlab, uniquement avec git.

Pour cela, je dois donc créer mon repo sur le serveur, mais en dehors de la partie web. Je vais donc créer un repo dans un dossier, sur Debian 12, j'ai remarqué que le dossier /var/lib/git existait déjà, vide, alors je l'utilise, mais on peut aussi choisir un autre dossier comme par exemple /srv/git par exemple.

Avant de commencer, il est préférable de créer un utilisateur git si cela n'est pas déjà fait. Cet utilisateur va servir à gérer les permissions pour les fichiers git et aussi pour les fichiers du serveur web si besoin. Il va aussi permettre de stocker les clés d'accès SSH dont on verra plus loin à quoi elles servent. Voici comment créer l'utilisateur :

# adduser git

Sur Debian 12, on peut ajouter cela afin de permettre à l'utilisateur git de faire partie des utilisateurs web :

# usermod -a -G www-data git

Je vais donner l'exemple du site sur lequel nous nous trouvons : fredvoyage. Voici la création du repo, qui va servir à gérer la synchronisation (on peut utiliser root ou git comme utilisateur) :

# mkdir -p /srv/git/fredvoyage.git
# cd /srv/git/fredvoyage.git
# git init --bare

Ici, on crée un repo "bare", c'est-à-dire vide, qui va servir à gérer les synchronisations. Le dossier doit être vide : surtout ne pas créer ce dossier dans le projet, car cela va ajouter des fichiers qui vont gêner les fichiers déjà présents.

Une fois le dossier créé et le git initialisé, on va dans le dossier de production sur le serveur, celui qui contient les fichiers du site internet existant, puisque tel est mon cas ici :

# cd /var/www/vhosts/fredvoyage.fr
# git init

Cette fois, on initialise git uniquement avec le paramètre d'initialisation, et git va alors créer un dossier .git qui va contenir les fichiers qui vont permettre de gérer les versions.

Une fois cela en place, on peut créer un fichier .gitignore comme indiqué dans la première partie, pour retirer de l'indexation et de la synchronisation des fichiers, ceux qui ne sont pas utiles, notamment le dossier .git, le fichier .gitignore et les dossiers de données si cela est utilisé sur vos projets.

Avant de continuer, on va s'assurer que tous les fichiers utilisent les bons utilisateurs. Il faut donc vérifier, par exemple pour Debian 12, que les fichiers aient ces permissions, mais pas sur tout le serveur, uniquement dans le dossier de production et surtout dans le dossier /var/lib/git qui contient tous les fichiers du repo :

# chown git:www-data * -R

Après ça, on va faire la première synchronisation en utilisant :

$ git add --all

Puis le premier commit :

$ git commit -m "Premier commit"

On va ensuite relier le repo de prod au serveur git avec cette commande :

$ git remote add origin /srv/git/fredvoyage.git

Puis on lance le premier push :

$ git push -u origin master

Pour la partie serveur de production, il nous restera le hook à mettre en place après la première synchronisation pour éviter que cela resynchronise les fichiers qui le sont déjà.

Il faut aussi, maintenant, ajouter les clés SSH, ce qui permettra de se connecter plus facilement au serveur, avec l'utilisateur git. Vous devez, pour cela, créer une paire de clés SSH, et mettre la clé publique, dans le fichier authorized_keys qui se trouve dans le dossier .ssh de l'utilisateur git. Si vous utilisez Debian, vous devriez déjà avoir une clé SSH, sinon il suffit de créer une clé avec cette commande :

$ ssh-keygen

La clé générée se trouve dans le dossier .ssh, et la clé publique aura une extension en .pub. C'est le contenu de ce fichier qui est la clé publique.

Maintenant, on va s'occuper du repo local sur mon ordinateur. C'est vraiment très simple à mettre en place une fois que l'on a décidé dans quel dossier mettre les fichiers. Il suffit de se placer dans le dossier et d'entrer :

$ git clone ssh://utilisateur@serveur.com/srv/git/fredvoyage.git

Cette commande va alors créer un dossier du nom du repo, sans l'extension git, et dans ce dossier, elle va initialiser un repo (donc avec un dossier .git) et copier tous les fichiers nécessaires dans le dossier du repo. Cette opération peut prendre un peu de temps suivant la taille du site internet, mais généralement, cela se fait en quelques minutes.

A partir de là, le repo local est en place. On peut alors ouvrir Cursor ou VSCode pour modifier les fichiers qu'il faut et utiliser l'outil de gestion de git pour faire les mises à jour. Dans VSCode, cet outil inclut la possibilité de décrire toutes les modifications automatiquement, ce qui permet, sans effort, d'indiquer ce qui a été fait, je reviendrai là-dessus plus en détail dans un autre article qui sera consacré à Cursor.

Côté serveur, il nous reste une seule chose à faire, c'est à créer le hook qui permet au serveur git de copier les fichiers qui sont poussés du local vers le serveur, sur le dossier de production. Ce hook est un petit script, que l'on peut modifier avec la commande (à éditer en tant que git ou root mais il faudra peut-être changer le propriétaire du fichier après la modification) :

$ vi /srv/git/fredvoyage.git/hooks/post-receive

Voici le contenu du fichier :

#!/bin/bash
TARGET="/var/www/vhosts/fredvoyage.fr/httpdocs"
GIT_DIR="/srv/git/fredvoyage.git"
# Déployer la dernière version
git --work-tree=$TARGET --git-dir=$GIT_DIR checkout -f

On peut aussi ajouter une partie consistant à modifier les permissions et les propriétaires des fichiers, pour être sûr que tout se passe au mieux sans erreurs de permission :

chown -R git:www-data $TARGET
find $TARGET -type d -exec chmod 755 {} ;
find $TARGET -type f -exec chmod 644 {} ;

Une suggestion consiste à ajouter aussi un log de ce déploiement pour s'assurer que tout s'est bien passé. Voici 3 lignes, les 2 premières à ajouter juste avant la commande git de déploiement (git checkout), et les 2 dernières à la fin du fichier :

LOG_FILE="/var/log/git-deployments.log"
echo "Déploiement effectué le $(date) par $(whoami)" >> $LOG_FILE

echo "Déploiement terminé avec succès" >> $LOG_FILE
echo "-----------------------------" >> $LOG_FILE


On peut alors tester le script de déploiement en utilisant cette commande en root depuis le serveur :

# su git /var/lib/git/fredscloud.git/hooks/post-receive

Cela permet de vérifier que tout fonctionne bien. Vous pouvez aussi tester cela en modifiant un fichier puis en faisant un commit et un push, toutefois avec cette commande, il sera possible de mieux voir les erreurs s'il y en a.

Sécurité

Pour vous assurer que personne ne puisse accéder à des données liées à git, il faut vérifier que le dossier .git ainsi que le fichier .gitignore ne soient pas accessibles depuis le web.

Pour cela, 2 méthodes sont possibles, soit l'utilisation du fichier .htaccess, si le serveur l'autorise, en bloquant l'accès aux fichiers/dossiers :

<DirectoryMatch "^/.*/.git/">
    Require all denied
</DirectoryMatch>

<FilesMatch "^.git">
    Require all denied
</FilesMatch>

Si cela n'est pas autorisé par la configuration, alors on peut mettre les lignes en question directement dans le fichier de configuration d'Apache qui se trouve dans le dossier /etc/apache2/sites-enabled en adaptant les directives :

<DirectoryMatch "^/var/www/vhosts/fredvoyage.fr/httpdocs/.git">
    Require all denied
</DirectoryMatch>

<DirectoryMatch "^/var/www/vhosts/fredvoyage.fr/httpdocs/.gitignore">
    Require all denied
</DirectoryMatch>



Vous devez ensuite redémarrer Apache avec la commande :

# systemctl restart apache2


Vérifiez bien que ces fichiers et dossiers ne soient pas accessibles, car cela peut poser de vrais problèmes de sécurité.

Un autre aspect important est la sauvegarde de vos données : n'oubliez pas de sauvegarder régulièrement le dossier /var/lib/git afin de ne pas perdre l'historique des modifications.

Conclusion

La mise en place d'un outil de versioning demande peu de travail et permet, en cas d'erreur, soit lié à la suppression accidentelle de fichiers ou à la modification inadequat de code, de pouvoir revenir en arrière facilement. C'est d'autant plus utile qu'avec les outils disponible aujourd'hui, je fais référence aux LLM, ces IA peuvent parfois faire des modifications qui ne sont pas sans erreur et rendre le site internet indisponible. Si ces modifications sont longues et complexes, elles le sont aussi pour le développeur qui doit les relire et trouver l'erreur, qui, parfois, se résume à un ";" oublié. Cet outil permet alors de voir plus facilement les modifications, mais aussi de conserver un historique des modifications. Cela permet de voir l'empleur du travail réalisé, et aussi de savoir depuis quand ce bug est apparu, qu'il faut maintenant corriger.

Si cet article vous a pu, n'hésitez pas à le partager ou à m'envoyer vos remarques (mon adresse email est dans les informations légales).