J'ai rencontré le même problème avec un site que j'avais hébergé sur un package d'hébergement partagé HostNine. Ils vous donnent également sshaccès, mais ils ne l'ont malheureusement pas gitinstallé et ne vous donnent même pas accès à l'exécution gcc, ce qui rend le téléchargement et l'installation de git assez difficiles pour votre utilisateur.
La seule façon dont je pouvais penser à contourner ces restrictions était de copier les binaires git depuis un autre ordinateur qui les avait. Peut-être que la même solution fonctionnerait pour vous et votre hôte partagé GoDaddy. Voici ce que j'ai fait:
Déterminez d'abord l'architecture de votre serveur. Dans mon cas, c'était 32 bits (i386). Voici quelques façons de comprendre cela:
# uname -a
Linux ___.myserverhosts.com 2.6.18-128.1.6.el5PAE #1 SMP Wed Apr 1 10:02:22 EDT 2009 i686 i686 i386 GNU/Linux
# file /bin/echo
/bin/echo: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
Ensuite, vous devez trouver un autre ordinateur exécutant Linux avec la même architecture et avec git installé dessus. Ils n'ont même pas besoin d'exécuter la même distribution ou version de Linux, tant qu'ils sont de la même architecture et que vous pouvez trouver les fichiers binaires et les fichiers de bibliothèque dont vous avez besoin.
Pour trouver l'emplacement du binaire git principal:
> which git
/usr/local/bin/git
Certains autres binaires importants (comme git-receive-pack) résident également dans le même répertoire, je vous recommande donc de simplement les copier tous /usr/local/bin/git*pour vous assurer d'obtenir tout ce dont vous avez besoin.
D'autres fichiers importants sont ceux dont git dépend sont sous un répertoire «libexec» quelque part sur le système source. Si vous ne les recopiez pas, vous pouvez obtenir un message d'erreur surprenant lorsque vous essayez de faire un git push, comme je l'ai fait:
git: 'index-pack' is not a git-command. See 'git --help'.
Pour trouver le répertoire contenant les bibliothèques git principales sur target_host, vous pouvez utiliser ceci:
> git --exec-path
/usr/local/libexec/git-core
Je recommanderais de copier ces fichiers en premier, puis d'essayer d'exécuter git pour voir s'il se plaint d'éventuelles bibliothèques partagées manquantes. Si ce n'est pas le cas, alors vous êtes (vraisemblablement) prêt à partir. Si c'est le cas, continuez à lire. (N'utilisez pas la copie sur des bibliothèques partagées si elles existent déjà sur l'hôte cible et sont la version correcte.)
Vous pouvez copier les fichiers avec scp, rsync, ftpou tout ce que vous êtes à l' aise avec. J'ai utilisé scpquelque chose comme ça:
> ssh target_host 'mkdir -p ~/bin ~/libexec'
> scp /usr/local/bin/git* target_host:~/bin
> scp -r /usr/local/libexec/git-core target_host:~/libexec
Ensuite, ssh vers target_host. Vous devrez ajouter quelques lignes comme celles-ci à votre ~/.bashrc:
export PATH=$PATH:~/bin
export LD_LIBRARY_PATH=~/lib
export GIT_EXEC_PATH=~/libexec/git-core
Si vous oubliez cette étape, vous pourriez être surpris de voir cette erreur lorsque vous effectuez une git push:
git-receive-pack: command not found
Ceci est documenté dans la FAQ Git sur git.or.cz:
Fondamentalement, le problème est que 'git-receive-pack' n'est pas dans le $ PATH par défaut sur l'extrémité distante.
...
- Assurez-vous que le chemin d'accès correct est configuré dans
.bashrc(pas seulement .bash_profile)
GIT_EXEC_PATHest documenté sur man git:
--exec-path
Path to wherever your core git programs are installed.
This can also be controlled by setting the GIT_EXEC_PATH
environment variable. If no path is given, git will print
the current setting and then exit.
Achetez votre nouveau ~/.bashrc. Maintenant, essayez de courir git.
C'est ce que ça m'a donné la première fois:
> git
git: error while loading shared libraries: libcrypto.so.4: cannot open shared object file: No such file or directory
J'ai pu déterminer l'emplacement des bibliothèques partagées à copier en exécutant ceci sur la machine source:
> ldd /usr/local/bin/git
libz.so.1 => /usr/lib/libz.so.1 (0xb7fcf000)
libcrypto.so.4 => /lib/libcrypto.so.4 (0xb7ee4000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7ed2000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7da6000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb7d92000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb7d2d000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7d2a000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb7d08000)
libresolv.so.2 => /lib/libresolv.so.2 (0xb7cf5000)
libdl.so.2 => /lib/libdl.so.2 (0xb7cf1000)
/lib/ld-linux.so.2 (0xb7fe8000)
Dans mon cas , je devais juste copier /lib/libcrypto.so.4vers ~/libmon target_hostet tout allait bien.
Maintenant, vous devriez avoir un travail gitsur votre serveur d'hébergement partagé et vous devriez pouvoir y pousser!
Vous devez maintenant créer un nouveau référentiel git et une arborescence de travail sur votre serveur ou copier votre référentiel / arborescence de travail existant.
Soit dit en passant, je ne pense pas qu'un référentiel nu soit ce que vous voulez sur le serveur dans ce cas puisque vous avez dit que vous vouliez déployer les fichiers de contenu réels (par opposition aux seuls config HEAD objects/ refs/fichiers qui seraient inclus dans un référentiel nu) chaque fois vous faites un git push.
toolmantim.com explique la différence entre un référentiel git normal et un référentiel nu:
Un référentiel git par défaut suppose que vous l'utiliserez comme répertoire de travail, donc git stocke les fichiers de référentiel nus réels dans un répertoire .git à côté de tous les fichiers de projet. Les référentiels distants n'ont pas besoin de copies des fichiers sur le système de fichiers contrairement aux copies de travail, tout ce dont ils ont besoin sont les deltas et autres éléments binaires du référentiel lui-même. C'est ce que «nu» signifie git. Juste le référentiel lui-même.
Je suppose pour le moment que vous avez déjà créé un répertoire sur votre target_hostoù vous souhaitez déployer votre site web (ou quoi que vous déployiez). Appelons ce répertoire ~/www/my_site. Vous pouvez même avoir ftp'd sur tous vos fichiers ~/www/my_site already. (Que vous ayez ou non n'est pas important.) Je suppose également pour le moment que vous n'avez pas déjà copié le sous-répertoire .git dans ~/www/my_site(cela devrait fonctionner très bien si vous l'avez déjà fait).
Puisqu'il n'y a pas déjà de dépôt git initialisé sur target_host, votre première étape serait d'en créer un:
> cd ~/www/my_site
> git init
Ensuite, quel que soit l'hôte disposant du référentiel avec les dernières modifications que vous souhaitez déployer (votre boîte de développement, je suppose), il vous suffit de faire quelque chose comme ceci pour déployer:
> git push --all ssh://username@target_host:port/~/www/my_site/.git
Un avertissement comme celui-ci peut s'afficher si votre référentiel target_hostn'est pas déjà à jour:
> warning: updating the current branch
> warning: Updating the currently checked out branch may cause confusion,
> warning: as the index and work tree do not reflect changes that are in HEAD.
> warning: As a result, you may see the changes you just pushed into it
> warning: reverted when you run 'git diff' over there, and you may want
> warning: to run 'git reset --hard' before starting to work to recover.
> warning:
> warning: You can set 'receive.denyCurrentBranch' configuration variable to
> warning: 'refuse' in the remote repository to forbid pushing into its
> warning: current branch.
> warning: To allow pushing into the current branch, you can set it to 'ignore';
> warning: but this is not recommended unless you arranged to update its work
> warning: tree to match what you pushed in some other way.
> warning:
> warning: To squelch this message, you can set it to 'warn'.
> warning:
> warning: Note that the default will change in a future version of git
> warning: to refuse updating the current branch unless you have the
> warning: configuration variable set to either 'ignore' or 'warn'.
(En gitutilisation normale , vous ne voyez jamais ce message, je pense, parce que vous poussez normalement vers des référentiels nus . Mais puisque notre référentiel distant dans ce cas est un dépôt normal avec à la fois un arbre de travail et un index, il gitest compréhensible que cela puisse gâcher quelque chose.)
Je pense qu'il est sûr pour nous de le régler sur «ignorer» sur votre serveur, car vous ne risquez pas de faire de commit directement dans le référentiel. (Toutes les validations devraient probablement provenir de votre référentiel de développement, puis être envoyées au serveur.)
Alors, allez-y et réglez ceci pour que vous ne voyiez pas l'avertissement à chaque fois que vous appuyez sur:
> ssh target_host 'cd ~/www/my_site/; git config receive.denyCurrentBranch ignore'
Le pushlui-même ne met à jour que l'index, mais PAS les fichiers dans l'arborescence de travail elle-même. Cependant, la mise à jour de ces fichiers n'est que le point essentiel de ce que nous essayons de faire, donc notre travail n'est pas terminé jusqu'à ce que nous disions gitd'écrire le contenu de l'index dans l'arbre de travail lui-même, comme ceci:
> ssh target_host 'cd ~/www/my_site/; git reset --hard'
(Remarque: toutes les modifications que vous pourriez avoir apportées à votre arborescence de travail sur le serveur seront écrasées par ce qui se trouve dans le référentiel.)
J'ai également suivi la suggestion de mattikus et créé une télécommande pour mon serveur:
> git remote add h9 ssh://username@target_host:port/~/www/my_site/.git
Alors maintenant, tout ce que je dois faire pour déployer est:
> git push --all --force h9
> ssh remote_host 'cd ~/www/my_site/; git reset --hard'
Je suis même allé jusqu'à lancer ces commandes dans un script que j'ai nommé, script/deploydonc chaque fois que je veux déployer, je n'ai qu'une seule commande à exécuter.
Veuillez me faire savoir si vous trouvez des erreurs dans ces instructions ou si vous connaissez une meilleure solution.