Déployer une application Git : branches et contrôles

Objectif

Ce guide explique comment organiser un déploiement depuis un dépôt Git, depuis le premier commit jusqu’à la vérification en ligne. Il vise les applications PHP/Laravel, Node.js et les projets construits par une étape de compilation. La méthode sépare clairement le code source, les secrets, les dépendances et les fichiers destinés à être servis par le web.

Pour un projet applicatif, reliez cette procédure à un serveur VPS et au guide pour déployer une application depuis Git.

Git permet notamment d’ajouter un dépôt distant avec git remote add et de récupérer les références distantes avec fetch [1]. NovaHoster peut proposer un raccordement Git, un déploiement manuel ou une autre méthode selon l’offre et les droits : vérifiez le parcours exact affiché dans votre Espace client.

Prérequis

Vous devez disposer d’un dépôt accessible depuis le compte ou le mécanisme d’authentification choisi, d’une branche de déploiement identifiée et d’un projet qui fonctionne localement. Préparez également le nom de domaine ou sous-domaine, le répertoire public attendu par l’application et la liste des variables d’environnement nécessaires.

Avant toute mise en production, contrôlez que .env, les clés privées, les jetons et les sauvegardes locales ne sont pas suivis par Git. Un fichier .env.example peut documenter les noms attendus sans contenir de secrets. Si le dépôt est privé, confirmez le mode d’accès accepté par NovaHoster : clé SSH, jeton, intégration Git ou dépôt miroir. Ne transmettez jamais un secret dans une URL, un ticket public ou un fichier versionné.

Procédure

Préparer le dépôt. Depuis le poste de développement, vérifiez l’état puis créez un commit cohérent :

``bash git status git add . git commit -m "Préparer le déploiement" git branch --show-current ``

La branche indiquée doit être celle que vous souhaitez publier. Évitez de déployer un répertoire de travail non commité : cela rend le diagnostic et le retour arrière difficiles.

Définir une stratégie de branches. Utilisez par exemple une branche de développement, une branche de préproduction et une branche de production. Le nom importe moins que la règle : une seule branche doit être la source autorisée du site public. Documentez la branche, le commit attendu et la date de chaque mise en ligne.

Raccorder le dépôt dans l’Espace client. Ouvrez le service d’hébergement concerné, cherchez la rubrique de déploiement ou de gestion du code, puis renseignez l’URL du dépôt et la branche. Les champs et actions disponibles sont susceptibles de varier selon le forfait et les droits ; si aucun raccordement Git n’est proposé, confirmez avec NovaHoster la méthode de transfert compatible.

Choisir le répertoire publié. Une application ne doit pas nécessairement exposer sa racine de projet. Pour Laravel, le document officiel recommande de servir le répertoire public, afin de ne pas rendre accessibles les fichiers de configuration et le code interne [2]. Pour un projet Node.js, le répertoire public peut être le dossier produit par la compilation, comme dist, tandis que le serveur applicatif doit rester derrière le mécanisme d’exécution prévu par l’hébergement.

Configurer l’installation et la construction. Si NovaHoster fournit des champs de commande, indiquez uniquement des commandes adaptées au projet, par exemple composer install --no-dev --optimize-autoloader pour une application PHP ou npm ci && npm run build pour un projet Node.js. Ces commandes ne sont possibles que si les runtimes et accès correspondants sont disponibles dans votre offre. Ne supposez pas qu’un gestionnaire de processus, une compilation persistante ou une commande personnalisée est inclus.

Renseigner les variables d’environnement hors du dépôt. Reproduisez les variables nécessaires dans l’environnement de l’application : connexion à la base, URL, clé d’application, mode d’exécution et paramètres de journalisation. Conservez les valeurs secrètes dans le gestionnaire prévu par NovaHoster, s’il est disponible, et confirmez les droits de lecture ainsi que la façon de redémarrer l’application après modification.

Lancer le déploiement et relever le commit. Notez l’identifiant du commit publié. Si l’interface affiche une sortie de construction, conservez-la avec l’heure, la branche et le résultat. Un déploiement réussi signifie généralement que les fichiers ont été transférés et que les commandes se sont terminées ; il ne garantit pas que le domaine, la base, les permissions ou le processus applicatif fonctionnent.

Tester le site. Ouvrez la page d’accueil, une route interne, un formulaire et, si possible, une opération de lecture en base. Vérifiez aussi les codes HTTP, les redirections, les fichiers statiques et l’absence de message de débogage. Pour une application Laravel récente, une route de santé peut répondre 200 lorsque l’application a démarré sans exception, mais sa présence et son URI doivent être vérifiées dans le code [2].

Préparer le retour arrière. Gardez le dernier commit connu comme fonctionnel. Si la plateforme propose une restauration de version, confirmez sa portée ; sinon, prévoyez la procédure documentée pour sélectionner l’ancien commit. Un retour arrière du code ne restaure pas automatiquement une migration de base de données déjà exécutée.

Cas d’erreur et diagnostic

Symptôme	Causes probables	Diagnostic et correction
Le dépôt est inaccessible	URL incorrecte, dépôt privé non autorisé, clé ou jeton refusé	Revalidez l’URL, la branche et les droits. Régénérez l’accès selon la procédure du fournisseur Git, puis confirmez le format accepté par NovaHoster.
Le mauvais code est publié	Branche incorrecte ou ancien cache de build	Comparez le commit publié au commit attendu, puis relancez depuis la bonne branche. Vérifiez si un cache de dépendances ou d’artefacts est actif.
Le site affiche une liste de fichiers ou une erreur 404	Racine web mal réglée	Pour Laravel, pointez vers `public`. Pour un frontend compilé, utilisez le dossier de sortie prévu par le projet. Ne déplacez pas arbitrairement `index.php` à la racine Laravel [2].
La construction échoue sur `composer` ou `npm`	Runtime absent, version incompatible, dépendance verrouillée	Comparez les versions locales et celles autorisées par l’offre. Utilisez le fichier de verrouillage adapté (`composer.lock` ou `package-lock.json`) lorsque le projet le prévoit.
Le déploiement réussit mais l’application renvoie 500	Variable manquante, migration non exécutée, permission ou processus non démarré	Lisez les logs, contrôlez les variables sans afficher leurs secrets, testez la connexion à la base et vérifiez le processus attendu.

Questions fréquentes

Puis-je déployer n’importe quel dépôt Git ?

Non. Le dépôt doit être accessible par le mécanisme autorisé, et le projet doit être compatible avec les runtimes et ressources disponibles. Confirmez les dépôts privés et les méthodes d’authentification dans l’Espace client.

Dois-je versionner le fichier .env ?

Non. Laravel recommande de ne pas versionner les fichiers d’environnement non chiffrés, car ils peuvent contenir des identifiants [3]. Versionnez plutôt un modèle sans valeur sensible.

Un déploiement Git exécute-t-il automatiquement les migrations ?

Pas nécessairement. Une synchronisation de fichiers ou une construction ne signifie pas qu’une commande de migration a été lancée. Vérifiez le journal du déploiement et exécutez les migrations uniquement après sauvegarde et validation de la procédure.

Puis-je publier directement la branche principale ?

Oui, techniquement, mais une branche de production protégée et une validation préalable réduisent les erreurs. Le choix de gouvernance appartient à votre projet, pas à Git lui-même.

Pourquoi le site reste-t-il sur l’ancienne version ?

Le domaine peut pointer vers un autre site, le déploiement peut viser une autre branche ou un cache peut servir d’anciens fichiers. Comparez le commit, la racine publiée, le domaine et les journaux.

Quand contacter l’Espace client

Contactez NovaHoster si l’option Git n’apparaît pas, si l’accès au dépôt est refusé malgré des identifiants valides, si vous devez connaître les runtimes disponibles, si une commande de build est bloquée par des droits, ou si vous avez besoin de confirmer les quotas, limites de durée, tâches planifiées, workers et mécanismes de restauration de votre offre. Joignez l’identifiant du site, le commit, l’heure, le message d’erreur et les étapes déjà testées, sans transmettre de secret.

Maillage interne suggéré

[Configurer les variables d’environnement sans exposer ses secrets](#guide-2--configurer-les-environnements-dune-application-laravel-ou-nodejs)
[Lire les logs et diagnostiquer une erreur 500](#guide-3--lire-les-logs-et-diagnostiquer-une-application-en-production)
[Checklist avant mise en production]
[Sauvegarder une base avant une migration]
[Comprendre les limites de son offre NovaHoster]

Sources techniques

[1] Git — git-remote [2] Laravel — Deployment [3] Laravel — Configuration

Cette procédure ne correspond pas à votre écran ?

Les permissions et options visibles peuvent dépendre de votre formule ou de vos droits. Faites vérifier le contexte depuis l’Espace client.

Demander une vérification

Déployer une application depuis Git sur NovaHoster