Я зіткнувся з тією самою проблемою з сайтом, який я розмістив на пакеті хостингу для спільного розміщення 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
Це задокументовано у FAQ щодо Git на git.or.cz:
По суті, проблема полягає в тому, що "git-accept-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(він повинен спрацьовувати нормально, якщо у вас є).
Оскільки сховище git ще не ініціалізовано на target_host, вашим першим кроком буде створення одного:
> 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тому щоразу, коли мені хочеться розгорнути, у мене є лише одна команда для запуску.
Будь ласка, повідомте мене, якщо ви виявили помилки в цих інструкціях або якщо ви знаєте кращого рішення.