Ich hatte das gleiche Problem mit einer Site, die ich in einem HostNine Shared Hosting-Paket gehostet hatte. Sie gewähren Ihnen ebenfalls sshZugriff, haben aber leider nicht gitinstalliert und gewähren Ihnen nicht einmal Zugriff auf die Ausführung gcc, was das Herunterladen und Installieren von git für Ihren Benutzer ziemlich schwierig macht.
Die einzige Möglichkeit, diese Einschränkungen zu umgehen, bestand darin, die Git-Binärdateien von einem anderen Computer zu kopieren, auf dem sie installiert waren. Möglicherweise funktioniert die gleiche Lösung für Sie und Ihren gemeinsam genutzten GoDaddy-Host. Folgendes habe ich getan:
Stellen Sie zunächst fest, über welche Architektur Ihr Server verfügt. In meinem Fall war es 32-Bit (i386). Hier sind ein paar Möglichkeiten, das herauszufinden:
# 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
Als nächstes müssen Sie einen anderen Computer finden, auf dem Linux mit derselben Architektur und installiertem Git ausgeführt wird. Sie müssen nicht einmal dieselbe Distribution oder Version von Linux ausführen, solange sie dieselbe Architektur haben und Sie die benötigten Binärdateien und Bibliotheksdateien finden.
So finden Sie den Speicherort der Haupt-Git-Binärdatei:
> which git
/usr/local/bin/git
Einige andere wichtige Binärdateien (wie git-receive-pack) befinden sich ebenfalls im selben Verzeichnis. Ich empfehle daher, nur alle /usr/local/bin/git*zu kopieren , um sicherzustellen, dass Sie alles bekommen, was Sie brauchen.
Andere wichtige Dateien, von denen git abhängt, befinden sich in einem 'libexec'-Verzeichnis irgendwo auf dem Quellsystem. Wenn Sie diese nicht überschreiben, wird möglicherweise eine überraschende Fehlermeldung angezeigt, wenn Sie versuchen git push, wie folgt vorzugehen:
git: 'index-pack' is not a git-command. See 'git --help'.
So finden Sie das Verzeichnis mit den wichtigsten Git-Bibliotheken auf target_host:
> git --exec-path
/usr/local/libexec/git-core
Ich würde empfehlen, diese Dateien zuerst zu kopieren und dann zu versuchen, git auszuführen, um festzustellen, ob es sich über fehlende gemeinsam genutzte Bibliotheken beschwert. Wenn dies nicht der Fall ist, können Sie (vermutlich) loslegen. Wenn ja, lesen Sie weiter. (Kopieren über gemeinsam genutzte Bibliotheken ist nicht sinnvoll, wenn diese bereits auf dem Zielhost vorhanden sind und die richtige Version aufweisen.)
Sie können die Dateien mit kopieren scp, rsync, ftp, oder was auch immer Sie sind komfortabel mit. Ich habe so scpetwas verwendet:
> 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
Dann ssh zu target_host. Sie müssen einige Zeilen wie diese zu Ihrem hinzufügen ~/.bashrc:
export PATH=$PATH:~/bin
export LD_LIBRARY_PATH=~/lib
export GIT_EXEC_PATH=~/libexec/git-core
Wenn Sie diesen Schritt vergessen, werden Sie möglicherweise überrascht sein, diesen Fehler zu sehen, wenn Sie Folgendes ausführen git push:
git-receive-pack: command not found
Dies ist in den Git-FAQ auf git.or.cz dokumentiert:
Grundsätzlich besteht das Problem darin, dass 'git-receive-pack' nicht im Standard $ PATH auf der Remote-Seite enthalten ist.
...
- Stellen Sie sicher, dass Sie den richtigen Pfad eingerichtet haben
.bashrc(nicht nur .bash_profile)
GIT_EXEC_PATHist dokumentiert am 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.
Beschaffe dein neues ~/.bashrc. Versuchen Sie jetzt zu laufen git.
Das gab es mir zum ersten Mal:
> git
git: error while loading shared libraries: libcrypto.so.4: cannot open shared object file: No such file or directory
Ich konnte den Speicherort der freigegebenen Bibliotheken zum Kopieren herausfinden, indem ich Folgendes auf dem Quellcomputer ausführte:
> 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)
In meinem Fall hatte ich nur zu kopieren , /lib/libcrypto.so.4um über ~/libmeine target_hostund alles war in Ordnung.
Jetzt sollten Sie gitauf Ihrem gemeinsam genutzten Hosting-Server arbeiten und in der Lage sein, darauf zu pushen!
Jetzt müssen Sie entweder ein neues Git-Repository und einen neuen Arbeitsbaum auf Ihrem Server erstellen oder Ihren vorhandenen Repository- / Arbeitsbaum kopieren.
Übrigens, ich glaube nicht, dass Sie in diesem Fall ein nacktes Repository auf dem Server haben möchten, da Sie gesagt haben, dass Sie die eigentlichen Inhaltsdateien (im Gegensatz zu den Dateien, die in einem nackten Repository enthalten wären) immer bereitstellenconfig HEAD objects/ refs/ möchten du machst ein git push.
toolmantim.com erklärt den Unterschied zwischen einem normalen Git-Repository und einem leeren Repository:
In einem Standard-Git-Repository wird davon ausgegangen, dass Sie es als Arbeitsverzeichnis verwenden. Daher speichert Git die eigentlichen Bare-Repository-Dateien in einem Git-Verzeichnis neben allen Projektdateien. Remote-Repositorys benötigen im Gegensatz zu Arbeitskopien keine Kopien der Dateien im Dateisystem. Sie benötigen lediglich die Deltas und Binär-What-Nots des Repositorys. Dies ist, was "nackt" bedeutet, um zu git. Nur das Repository selbst.
Ich gehe für den Moment davon aus, dass Sie bereits ein Verzeichnis erstellt haben, in target_hostdem Sie Ihre Website bereitstellen möchten (oder was auch immer Sie bereitstellen). Nennen wir das Verzeichnis ~/www/my_site. Möglicherweise haben Sie sogar über alle Ihre Dateien zu ftp'd ~/www/my_site already. (Ob Sie es getan haben oder nicht, ist nicht wichtig.) Ich gehe auch für den Moment davon aus, dass Sie das .git-Unterverzeichnis noch nicht in dieses kopiert haben ~/www/my_site(es sollte aber gut funktionieren, wenn Sie es getan haben).
Da auf target_host noch kein Git-Repository initialisiert ist, müssen Sie zunächst eines erstellen:
> cd ~/www/my_site
> git init
Unabhängig davon, auf welchem Host sich das Repository mit den neuesten Änderungen befindet, die Sie bereitstellen möchten (Ihre Entwicklungsbox, würde ich vermuten), müssen Sie zum Bereitstellen nur Folgendes tun:
> git push --all ssh://username@target_host:port/~/www/my_site/.git
Möglicherweise wird eine Warnung wie die folgende angezeigt, wenn Ihr Repository auf target_hostnoch nicht aktuell ist:
> 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'.
( gitIch glaube, im normalen Gebrauch wird diese Meldung nie angezeigt, weil Sie normalerweise auf leere Repositorys drängen . Da unser Remote-Repository in diesem Fall jedoch ein normales Repository mit einem Arbeitsbaum und einem Index ist, gitbesteht verständlicherweise die Befürchtung, dass dies der Fall sein könnte etwas durcheinander bringen.)
Ich denke, es ist sicher für uns, es auf Ihrem Server auf "Ignorieren" zu setzen, da Sie dort wahrscheinlich keine Commits direkt an das Repository vornehmen. (Alle Commits sollten wahrscheinlich aus Ihrem Entwicklungs-Repository stammen und dann auf den Server übertragen werden.)
Stellen Sie dies so ein, dass die Warnung nicht bei jedem Drücken angezeigt wird:
> ssh target_host 'cd ~/www/my_site/; git config receive.denyCurrentBranch ignore'
Der pushselbst aktualisiert nur den Index, NICHT jedoch die Dateien im Arbeitsbaum. Das Aktualisieren dieser Dateien ist jedoch nur ein Teil der Aufgabe, die wir zu erledigen versuchen. Unsere Aufgabe wird also erst dann erledigt, wenn wir gitden Inhalt des Index in den Arbeitsbaum selbst schreiben:
> ssh target_host 'cd ~/www/my_site/; git reset --hard'
(Hinweis: Alle Änderungen, die Sie möglicherweise an Ihrem Arbeitsbaum auf dem Server vorgenommen haben, werden durch die Angaben im Repository überschrieben.)
Ich bin auch dem Vorschlag von mattikus gefolgt und habe eine Fernbedienung für meinen Server erstellt:
> git remote add h9 ssh://username@target_host:port/~/www/my_site/.git
Jetzt muss ich nur noch Folgendes tun, um das Deployment durchzuführen:
> git push --all --force h9
> ssh remote_host 'cd ~/www/my_site/; git reset --hard'
Ich bin sogar so weit gegangen, diese Befehle in ein Skript zu integrieren, das ich benannt habe, script/deploysodass ich bei jeder Bereitstellung nur einen einzigen Befehl ausführen muss.
Bitte lassen Sie mich wissen, wenn Sie Fehler in dieser Anleitung finden oder eine bessere Lösung kennen.