Comment créer des fichiers de mise à jour «git push» sur votre hébergeur?

J'ai quelques sites qui sont tous hébergés sur le même service d'hébergement Web sous hébergement partagé. Mon hébergeur prend en charge Git et j'ai accès à SSH, et j'ai également la configuration de Git sur mon ordinateur portable.

Je veux faire en sorte que lorsque je fais un "maître d'origine git push", il met automatiquement à jour les fichiers sur mon serveur Web, et enregistre également une sauvegarde des fichiers du commit précédent afin que je puisse facilement revenir en arrière si je le souhaite. Est-ce possible?

git web

— Ryan
source

Curieux - qui est votre hébergeur?

— utilisateur

Et pourquoi voudriez-vous une "sauvegarde des fichiers du commit précédent"? Vous pouvez simplement pousser le commit précédent, si vous voulez revenir en arrière (en supposant que vous savez toujours ce que vous avez poussé en dernier - mais vous devriez quand même le savoir).

— 2015

Réponses:

Ceci est résumé à partir de l' utilisation de Git pour gérer un site Web

La clé du processus est le hook côté serveur «post-réception» (plus d'informations sur les hooks git dans Personnalisation de Git - Git Hooks et la page de manuel githooks ). Ce hook s'exécute après que le serveur a reçu toutes les données.

Une fois que le serveur reçoit les données, il s'exécute git checkout -f L'option -f forcera une extraction à la tête même s'il existe des différences locales.

#!/bin/sh
GIT_WORK_TREE=/var/www/www.example.org git checkout -f

Mettez-le dans le hooks/répertoire as post-receiveet exécutable. Bien sûr, le chemin change à l'endroit où vous avez les fichiers de votre serveur Web (l'utilisation de GIT_WORK_TREEdéfinit la variable d'environnement afin que vous n'ayez pas à jongler avec les fichiers dot et les paramètres git sur le serveur).

Pour revenir en arrière, il faut étiqueter chaque version (cela peut également être fait dans le cadre du hook post-commit). En étiquetant la version, on peut facilement identifier l'endroit où restaurer, bien que cela implique probablement de se connecter au serveur et d'extraire cette étiquette.

Il convient de noter que cela signifie que vous utilisez git comme outil de déploiement, ce à quoi il n'est pas vraiment destiné. Cela peut fonctionner, mais il existe de nombreuses limitations (besoin de télécharger le référentiel entier, aucun moyen d'appeler des scripts ou de gérer les autorisations de fichiers, aucun moyen de décompresser les choses ...). Il est probablement préférable d'utiliser un outil de déploiement approprié.

— 2015

@sleske Vous pouvez faire tout cela dans le post-receivecrochet, qui est vraiment juste un script où vous pouvez mettre ce que vous voulez.

— Mario

@Mario: Oui, vous le pouvez - ce qui signifie que vous implémentez efficacement votre propre solution de déploiement en tant que hook post-réception. Il y a toujours des avantages à utiliser une solution existante, mais parfois rouler la vôtre peut être le meilleur ...

— sleske

Vous pouvez même passer à la caisse dans un dossier intermédiaire et avoir des liens du dossier Web vers le dossier intermédiaire pour éviter d'avoir des fichiers .git dans votre dossier Web.

— Bent

La façon la plus simple de mettre à jour l'arborescence de travail du référentiel vers lequel vous poussez est de définir git config receive.denyCurrentBranch updateInstead du côté du récepteur. Voir https://git-scm.com/docs/git-config/#git-config-receivedenyCurrentBranch

La réponse de Ryan avec les hooks post commit est meilleure en ce sens qu'elle permet de vérifier à un emplacement différent (vous ne voulez probablement pas avoir le .git dans votre dossier web). Mais à ce niveau, il pourrait être judicieux d'utiliser un outil de déploiement existant, comme l'a dit sleske dans les commentaires.

— Echsecutor
source