Вопрос: Настройка git-репо в моем хостинговом плане GoDaddy


У меня есть проект, который управляется версиями с помощью git.

То, что я хочу сделать, - настроить репо на моем (ssh-enabled) GoDaddy общем хостинговом пакете, чтобы я мог развертывать с помощью push, а не перетаскивания на FTP.

Любые советы будут оценены. Лучше всего было бы быть учетной записью от кого-то, кто уже сделал это, но я не мог лично найти онлайн.


14
2018-06-16 20:18


Источник


вы, вероятно, получите ответы на это лучше от StackOverflow - mrTomahawk
Да, это было топор между ними. Возможно, перекрестно разместите его. Благодарю. - Tom Wright
Не то, что я настроил git-репо еще, но как настраивается программирование сервера исходного кода? - Мое голосование за serverfault, ясно - serverhorror
Вероятно, это не так, но разработчики будут знать об этом, потому что они вряд ли будут доверять нам, чтобы настроить его. - tomjedrz
Конечно, tomjedrz, и для полноты: stackoverflow.com/questions/1003885/... - Tom Wright


Ответы:


Я столкнулся с той же проблемой с сайтом, на котором я разместил хостинг-хостинг 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 to 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'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'

(Примечание. Любые изменения, которые могут возникнуть в дереве вашей работы на сервере, будут перезаписаны тем, что находится в репозитории.)

Я также следил за предложением mattikus и создал пульт для моего сервера:

> 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 поэтому в любое время, когда я хочу развернуть, у меня есть только одна команда для запуска.

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


23
2017-07-03 01:39



Удивительно! Если бы это было возможно, я бы сделал +10. - icc97


Я и SF, и 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, должен ли я сожалеть о том, что вместо этого вы не выбираете сновидений?

С наилучшими пожеланиями CJ

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


2
2018-06-17 13:00





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

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, он должен воспользоваться этим и использовать любые секретные ключи, которые вы, возможно, настроили.

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

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

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

git push godaddy

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


0
2018-06-16 22:20



Тем не менее, это скорее установка git на удаленном сервере. Ваш ответ (хотя и полезный) просто охватывает создание репозитория стандартным образом. - Tom Wright
А, понятно. Я не думал об этом. Возможно, вы сможете отправить поддержку хостинга godaddy и посмотреть, могут ли они установить git для вас или, по крайней мере, минимальные депрессии, чтобы вы сами их создали. Если нет, вы можете выяснить, какая архитектура работает и скомпилировать ее на аналогичной, и загрузить ее.