Я столкнулся с той же проблемой с сайтом, который я размещал в пакете хостинга HostNine. Они также предоставляют вам sshдоступ, но, к сожалению, они не gitустановлены и даже не дают вам доступа к запуску gcc, что затрудняет загрузку и установку git для вашего пользователя.
Единственный способ обойти эти ограничения - это скопировать двоичные файлы git с другого компьютера, на котором они были. Возможно, одно и то же решение подойдет вам и вашему общему хосту GoDaddy. Вот что я сделал:
Сначала выясните, какая архитектура у вашего сервера. В моем случае это был 32-битный (i386). Вот несколько способов понять это:
# 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
Затем вам нужно найти другой компьютер под управлением Linux с той же архитектурой и с установленным на нем git. Им даже не обязательно использовать один и тот же дистрибутив или версию Linux, если они имеют одинаковую архитектуру, и вы можете найти нужные вам двоичные файлы и библиотечные файлы.
Чтобы найти местоположение основного двоичного файла git:
> which git
/usr/local/bin/git
Некоторые другие важные двоичные файлы (например git-receive-pack) также находятся в том же каталоге, поэтому я рекомендую просто скопировать все файлы, /usr/local/bin/git*чтобы убедиться, что вы получите все, что вам нужно.
Другие важные файлы, от которых зависит git, находятся в каталоге libexec где-то в исходной системе. Если вы не скопируете их, вы можете получить неожиданное сообщение об ошибке при попытке сделать git push, как я:
git: 'index-pack' is not a git-command. See 'git --help'.
Чтобы найти каталог, содержащий основные библиотеки git на target_host, вы можете использовать это:
> git --exec-path
/usr/local/libexec/git-core
Я бы порекомендовал сначала скопировать эти файлы, а затем попытаться запустить git, чтобы проверить, не жалуются ли они на какие-либо отсутствующие общие библиотеки. Если этого не произойдет, тогда вы (предположительно) готовы идти. Если это так, то продолжайте читать. (Не используйте копирование через общие библиотеки, если они уже существуют на целевом хосте и имеют правильную версию.)
Вы можете копировать файлы с scp, rsync, ftpили все , что вы комфортно. Я использовал scp, что-то вроде этого:
> 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
Затем SSH к target_host. Вам нужно будет добавить несколько строк, подобных этим ~/.bashrc:
export PATH=$PATH:~/bin
export LD_LIBRARY_PATH=~/lib
export GIT_EXEC_PATH=~/libexec/git-core
Если вы забудете этот шаг, вы можете быть удивлены, увидев эту ошибку при выполнении git push:
git-receive-pack: command not found
Это описано в Git FAQ на git.or.cz:
По сути, проблема в том, что git-receive-pack не находится в $ PATH по умолчанию на удаленном конце.
...
- Убедитесь, что у вас есть правильный путь
.bashrc(не только .bash_profile)
GIT_EXEC_PATHзадокументировано на 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.
Источник ваш новый ~/.bashrc. Теперь попробуйте запустить git.
Это то, что он дал мне в первый раз:
> git
git: error while loading shared libraries: libcrypto.so.4: cannot open shared object file: No such file or directory
Я смог выяснить расположение разделяемых библиотек для копирования, запустив это на исходном компьютере:
> 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)
В моем случае я просто должен был скопировать /lib/libcrypto.so.4к ~/libна моем , target_hostи все было в порядке.
Теперь у вас должна быть работа gitна вашем сервере общего хостинга, и вы должны быть в состоянии подтолкнуть к нему!
Теперь вам нужно либо создать новый репозиторий git и рабочее дерево на своем сервере, либо скопировать существующее хранилище / рабочее дерево.
Между прочим, я не думаю, что в этом случае на сервере вам нужно пустое хранилище, поскольку вы сказали, что хотите развернуть фактические файлы содержимого (а не только config HEAD objects/ refs/файлы, которые будут включены в пустое хранилище) всякий раз, когда вы делаете git push.
toolmantim.com объясняет разницу между обычным репозиторием git и пустым репозиторием:
В репозитории git по умолчанию предполагается, что вы будете использовать его в качестве рабочего каталога, поэтому git сохраняет фактические файлы репозитория в каталоге .git вместе со всеми файлами проекта. Удаленные репозитории не нуждаются в копиях файлов в файловой системе в отличие от рабочих копий, все, что им нужно, - это дельты и двоичные данные самого репозитория. Это то, что значит «голый» для мерзавца. Просто сам репозиторий.
На данный момент я предполагаю, что вы уже создали каталог в том месте, target_hostгде вы хотите развернуть свой веб-сайт (или все, что вы развертываете). Давайте назовем этот каталог ~/www/my_site. Вы можете иметь даже ftp'd для всех ваших файлов ~/www/my_site already. (Независимо от того, есть ли у вас или нет, это не важно.) Я также предполагаю, что на данный момент вы еще не скопировали в подкаталог .git ~/www/my_site(хотя это должно работать нормально).
Поскольку на target_host нет инициализированного git-репозитория, первым шагом будет его создание:
> cd ~/www/my_site
> git init
Затем с любого хоста, у которого есть репозиторий с последними изменениями, которые вы хотите внедрить (я бы предположил, что это ваш блок разработки), вам просто нужно сделать что-то подобное для развертывания:
> git push --all ssh://username@target_host:port/~/www/my_site/.git
Такое предупреждение может появиться, если ваш репозиторий target_hostне обновлен:
> 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'.
( gitЯ думаю, что при обычном использовании вы никогда не видите это сообщение, потому что вы обычно отправляете в пустые репозитории. Но поскольку наш удаленный репозиторий в этом случае является обычным репозиторием с рабочим деревом и индексом, gitпонятно, что он может испортить что-нибудь.)
Я думаю, что для нас безопасно установить «игнорирование» на вашем сервере, потому что вы вряд ли будете делать какие-либо коммиты непосредственно в хранилище. (Вероятно, все коммиты должны исходить из вашего репозитория разработки, а затем отправляться на сервер.)
Так что продолжайте и установите это так, чтобы вы не увидели предупреждение при каждом нажатии:
> ssh target_host 'cd ~/www/my_site/; git config receive.denyCurrentBranch ignore'
Сам по pushсебе обновляет только индекс, но НЕ файлы в самом рабочем дереве. Тем не менее, обновление этих файлов - это всего лишь смысл всего, что мы пытаемся сделать, поэтому наша работа не будет завершена, пока мы не скажем gitзаписать содержимое индекса в само дерево работы, например, так:
> ssh target_host 'cd ~/www/my_site/; git reset --hard'
(Примечание. Любые изменения, которые вы могли внести в свое рабочее дерево на сервере, будут перезаписаны содержимым репозитория.)
Я также последовал совету Маттикуса и создал пульт для своего сервера:
> git remote add h9 ssh://username@target_host:port/~/www/my_site/.git
Теперь все, что мне нужно сделать, чтобы развернуть это:
> git push --all --force h9
> ssh remote_host 'cd ~/www/my_site/; git reset --hard'
Я даже дошел до того, что бросил эти команды в сценарий, который назвал, script/deployпоэтому в любое время, когда я хочу развернуть, у меня есть только одна команда для запуска.
Пожалуйста, дайте мне знать, если вы найдете какие-либо ошибки в этих инструкциях или если вы знаете лучшее решение.