Настройка репозитория git в моем плане хостинга GoDaddy

Я столкнулся с той же проблемой с сайтом, который я размещал в пакете виртуального хостинга 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 вместе со всеми файлами проекта. Удаленным репозиториям не нужны копии файлов в файловой системе, в отличие от рабочих копий, все, что им нужно, - это дельты и двоичные файлы чего-то самого репозитория. Вот что означает «голый» для git. Просто сам репозиторий.

---

На данный момент я предполагаю, что вы уже создали каталог на своем target_host где вы хотите развернуть свой веб-сайт (или все, что вы развертываете). Назовем этот каталог ~/www/my_site. Возможно, вы даже настроили ftp для всех ваших файлов, чтобы ~/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 поэтому каждый раз, когда я хочу развернуть, у меня есть только одна команда для запуска.

Пожалуйста, дайте мне знать, если вы обнаружите какие-либо ошибки в этих инструкциях или если вы знаете лучшее решение.

Я и научная фантастика, и godaddy n00b, так что потерпите меня, но в любом случае, я очень рад, что это обсуждается здесь.

Всего лишь свои 0,02 доллара, я попытался создать git (динамически) на своем Linux-компьютере, перенеся его на свою учетную запись godaddy, и даже если попытался просто нажать на пассивную машину godaddy, это не удалось из-за отсутствия openssl. Возможно, если я попытаюсь построить git статически с помощью openssl, но это тоже плохая идея.

$ git remote add godaddy ssh://unclecj@sveningsson.info//home/content/u/n/c/unclecj/foo.git

$ git push godaddy master
bash: git-receive-pack: command not found
fatal: The remote end hung up unexpectedly

$ git push --receive-pack="/home/content/u/n/c/unclecj/opt/git-1.6.3/bin/git-receive-pack" godaddy master
/home/content/u/n/c/unclecj/opt/git-1.6.3/bin/git-receive-pack: error while loading shared libraries: libcrypto.so.0.9.8: cannot open shared object file: No such file or directory
fatal: The remote end hung up unexpectedly

Не по теме, но разве такого рода отсутствие поддержки я должен ожидать от godaddy? Должен ли я сожалеть, что не выбрал Dreamhosts вместо этого?

С уважением, CJ

PS. Не ответ, а предположение, что если git-receive работает с godaddy (не так ли?), То репозиторий с отключенным рабочим деревом - отличный способ развертывания для Интернета: http://toroid.org/ams/git-website-howto

Самый простой способ сделать это - запустить на удаленном сервере что-то вроде этого:

mkdir repo.git
cd repo.git
git init --bare 

Затем при оформлении покупки:

git push --all ssh://<username>@<your server>/~/path/to/repo/relative/to/homedir/repo.git

Не требуется ни сервера, ни чего-либо еще, и вы должны иметь возможность получать / извлекать данные с этого компьютера, если у вас есть доступ по ssh.

Если у вас также настроен .ssh / config, он должен воспользоваться этим и использовать любые личные ключи, которые вы могли настроить.

Если вы планируете часто выкладывать обновления, вы можете добавить удаленное репо в свой devel checkout:

git remote add godaddy ssh://<username>@<your server>/path/to/repo.git

С этого момента вы можете:

git push godaddy

Для получения дополнительной информации ознакомьтесь с онлайн-документы на git push или беги git push --help чтобы запустить страницу руководства на вашем локальном.