Récupérer la dernière version depuis git

Pas encore déployé ? → Déployer un site web depuis un dépôt git ou Déployer une appli web depuis un dépôt git

Une fois qu’un site ou une appli a été déployé depuis un dépôt git, pousser de nouveaux commits vers votre dépôt ne met pas automatiquement le serveur à jour. Cliquez sur Récupérer la dernière version depuis git pour mettre le serveur à jour : un seul clic suffit, nous lançons git pull --ff-only en arrière-plan et, pour les applis web, nous installons les nouvelles dépendances éventuelles puis redémarrons votre appli sous systemd.

Quand le serveur est en retard sur votre dépôt, la carte de la charge de travail sur l’écran d’accueil affiche un petit badge **· ⤓ N behind** à côté de son état : vous voyez d’un coup d’œil qu’il y a quelque chose à récupérer. Survolez-le pour voir la commande exacte.

1. Ouvrir le panneau du service

Sur l’écran d’accueil, cliquez sur la carte du site ou de l’appli que vous voulez mettre à jour. Le panneau du service s’ouvre.

2. Ouvrir l’onglet Contrôles et cliquer sur « Récupérer la dernière version depuis git »

Pour les sites statiques comme pour les applis web, Récupérer la dernière version depuis git se trouve dans l’onglet Contrôles, avec Redémarrer / Arrêter / Démarrer / Générer une clé de déploiement.

Le bouton apparaît aussi à deux autres endroits, pour plus de praticité :

• Site statique — également dans la barre d’outils de l’onglet Fichiers (⤓ Récupérer la dernière version depuis git), car c’est là que les utilisateurs de sites statiques passent du temps.
• Les deux types — dans l’onglet État, lorsqu’il y a de nouveaux commits à récupérer. Une bannière « N commits de retard sur origin » s’affiche avec un bouton Récupérer la dernière version à côté. Utilisez cette vue si vous voulez voir exactement ce qui est en attente (nombre de commits, SHA actuel et distant) avant de récupérer les changements.

3. Faro récupère les changements

Le chat prend le relais. Pour un site statique, nous lançons git pull --ff-only et Caddy continue de servir le site : aucun redémarrage nécessaire. Pour une appli web, nous installons aussi les nouvelles dépendances éventuelles (npm ci / pip install) et redémarrons votre appli.

4. Terminé

La section d’état Git passe à « Synchronisé » sur le nouveau commit.

Si le site n’a pas été déployé depuis un dépôt git

Faro vérifie d’abord et vous l’indique dans le chat : « Ce site n’a pas été déployé depuis un dépôt git, il n’y a donc rien à récupérer. » Pour remplacer les fichiers, redéployez avec Déployer un site web depuis votre ordinateur (ou l’équivalent pour une appli web) : déposez un nouveau dossier sur le même site et nous remplacerons ce qui s’y trouve.

Si la récupération échoue avec « would be overwritten »

Nous utilisons git pull --ff-only, qui refuse les fusions non fast-forward. Si quelque chose a modifié un fichier suivi sur le serveur — l’onglet Fichiers, un client SFTP comme FileZilla, une session SSH, voire l’appli en cours d’exécution elle-même — la récupération peut échouer avec « Your local changes would be overwritten by merge ».

La section État Git de l’onglet État vous montre ce qui a changé :

• M = un fichier suivi a été modifié sur le serveur. Cela entre en conflit avec la récupération. Pour utiliser le fichier du dépôt (et abandonner votre modification locale), exécutez sudo git checkout -- <file> depuis le chemin de la charge de travail, puis relancez la récupération.
• ? = un fichier non suivi (par exemple des données téléversées par les utilisateurs dans uploads/, ou des fichiers d’exécution créés par votre appli). Cela n’entre pas en conflit : git pull laisse les fichiers non suivis tels quels. Aucune action nécessaire.

Pour les dépôts privés : générer d’abord une clé de déploiement

La première fois que vous récupérez la dernière version d’un dépôt privé, l’identifiant HTTPS mis en cache ne fonctionnera pas pour les récupérations sans intervention. La solution consiste à créer une clé de déploiement une seule fois.

1. Dans le panneau du service, cliquez sur Générer une clé de déploiement (à côté de Récupérer la dernière version).
2. Faro génère une paire de clés SSH sur le serveur et vous affiche la clé publique dans le chat.
3. Collez-la dans les paramètres de votre dépôt → Deploy keys (GitHub) ou SSH keys (GitLab, Bitbucket, Codeberg, Gitea). Ne cochez PAS l’accès en écriture : nous avons seulement besoin d’un accès en lecture.
4. Répondez done dans le chat : Faro fait passer le remote git de HTTPS à SSH et le teste.

Ensuite, Récupérer la dernière version fonctionne sans redemander d’identifiants.

Déploiements depuis un monorepo / sous-dossier

Si vous avez déployé depuis un sous-dossier d’un monorepo (par exemple apps/web), Récupérer la dernière version fonctionne quand même : sparse-checkout s’en charge en arrière-plan. Nous récupérons les changements dans le clone de longue durée situé dans /var/www/.helm-repos/<domain>/ (ou /opt/.helm-repos/<app>/ pour une appli web native) et votre dossier de déploiement est un lien symbolique qui reflète automatiquement les nouveaux fichiers.

Changer de branche

Récupérer la dernière version récupère les changements depuis la branche que vous avez clonée lors du déploiement initial. Pour passer à une autre branche, redéployez depuis la fenêtre modale : choisissez la nouvelle branche dans Avancé (git).