Konfigurowanie repozytorium git w moim planie hostingowym GoDaddy

Mam projekt, który jest kontrolowany w wersji za pomocą git.

To, co chcę zrobić, to skonfigurować repozytorium w moim (udostępnionym ssh) GoDaddy współużytkowanym pakiecie hostingowym, aby móc wdrażać za pomocą wypychania zamiast przeciągania i upuszczania na FTP.

Wszelkie wskazówki będą mile widziane. Najlepsze byłoby konto kogoś, kto już to zrobił, ale nie mogłem osobiście znaleźć żadnego online.

Napotkałem ten sam problem z witryną, którą hostowałem w hostowanym pakiecie hostingu. Oni również dają ci sshdostęp, ale niestety nie mają gitzainstalowanego i nawet nie dają ci dostępu do uruchamiania gcc, co utrudnia pobranie i zainstalowanie git dla twojego użytkownika.

Jedynym sposobem na obejście tych ograniczeń było skopiowanie plików binarnych git z innego komputera, który je miał. Być może to samo rozwiązanie zadziałałoby dla Ciebie i Twojego współdzielonego hosta GoDaddy. Oto co zrobiłem:

Najpierw dowiedz się, jaką architekturę ma Twój serwer. W moim przypadku był to 32-bit (i386). Oto kilka sposobów, aby to zrozumieć:

# 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

Następnie musisz znaleźć inny komputer z systemem Linux o tej samej architekturze i zainstalowanym na nim git. Nie muszą nawet uruchamiać tej samej dystrybucji lub wersji systemu Linux, o ile mają taką samą architekturę i można znaleźć potrzebne pliki binarne i biblioteki.

Aby znaleźć lokalizację głównego pliku binarnego git:

> which git
/usr/local/bin/git

Niektóre inne ważne pliki binarne (jak git-receive-pack) również znajdują się w tym samym katalogu, więc zalecamy po prostu skopiowanie wszystkich, /usr/local/bin/git*aby upewnić się, że otrzymujesz wszystko, czego potrzebujesz.

Inne ważne pliki, od których zależy git, znajdują się w katalogu „libexec” gdzieś w systemie źródłowym. Jeśli nie skopiujesz ich, może pojawić się zaskakujący komunikat o błędzie podczas próby wykonania git push, podobnie jak ja:

git: 'index-pack' is not a git-command. See 'git --help'.

Aby znaleźć katalog zawierający podstawowe biblioteki git na docelowym hoście, możesz użyć tego:

> git --exec-path
/usr/local/libexec/git-core

Polecam najpierw skopiować te pliki, a następnie spróbować uruchomić git, aby sprawdzić, czy narzeka na brakujące biblioteki współdzielone. Jeśli tak się nie stanie, jesteś (prawdopodobnie) dobry. Jeśli tak, czytaj dalej. (Nie ma potrzeby kopiowania przez biblioteki współdzielone, jeśli już istnieją na hoście docelowym i są poprawną wersją.)

Można kopiować pliki z scp, rsync, ftp, czy cokolwiek innego są wygodne. Użyłem scpczegoś takiego:

> 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

Następnie ssh do target_host. Musisz dodać kilka takich wierszy do ~/.bashrc:

export PATH=$PATH:~/bin
export LD_LIBRARY_PATH=~/lib
export GIT_EXEC_PATH=~/libexec/git-core

Jeśli zapomnisz ten krok, możesz być zaskoczony tym błędem, gdy wykonujesz git push:

git-receive-pack: command not found

Jest to udokumentowane w Git FAQ na git.or.cz:

Zasadniczo problem polega na tym, że 'git-receive-pack' nie znajduje się w domyślnej zmiennej $ PATH na zdalnym końcu.

...

• Upewnij się, że masz skonfigurowaną prawidłową ścieżkę .bashrc(nie tylko .bash_profile)

GIT_EXEC_PATHjest udokumentowany na 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.

Źródło nowego ~/.bashrc. Teraz spróbuj uruchomić git.

Oto, co dał mi pierwszy raz:

> git
git: error while loading shared libraries: libcrypto.so.4: cannot open shared object file: No such file or directory

Udało mi się ustalić lokalizację bibliotek współdzielonych do skopiowania, uruchamiając to na komputerze źródłowym:

> 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)

W moim przypadku miałem tylko skopiować /lib/libcrypto.so.4na na ~/libna mój target_hosti wszystko było w porządku.

Teraz powinieneś pracować gitna swoim wspólnym serwerze hostingowym i powinieneś być w stanie na niego naciskać!

Teraz musisz albo utworzyć nowe repozytorium git i drzewo pracy na swoim serwerze, albo skopiować istniejące repozytorium / drzewo pracy.

Nawiasem mówiąc, nie sądzę, aby w tym przypadku na serwerze było to, czego potrzebujesz, ponieważ powiedziałeś, że chcesz wdrożyć rzeczywiste pliki treści (w przeciwieństwie do samych config HEAD objects/ refs/plików, które byłyby zawarte w nagim repozytorium), ilekroć chcesz robisz git push.

toolmantim.com wyjaśnia różnicę między zwykłym repozytorium git a zwykłym repozytorium:

Domyślne repozytorium git zakłada, że ​​będziesz go używać jako katalogu roboczego, więc git przechowuje rzeczywiste pliki repozytorium w katalogu .git obok wszystkich plików projektu. Zdalne repozytoria nie potrzebują kopii plików w systemie plików w przeciwieństwie do kopii roboczych, wszystko czego potrzebują to delta i binarne elementy tego samego repozytorium. To właśnie „gołe” znaczy git. Tylko samo repozytorium.

Zakładam na chwilę, że już utworzyłeś katalog w swoim target_hostmiejscu, w którym chcesz wdrożyć swoją stronę internetową (lub cokolwiek, co wdrażasz). Nazwijmy ten katalog ~/www/my_site. Być może masz nawet ftp na wszystkich swoich plikach ~/www/my_site already. (Nieważne, czy masz, czy nie jest to ważne.) Przyjmuję również na chwilę, że nie skopiowałeś już podkatalogu .git ~/www/my_site(jeśli tak, to powinno działać dobrze).

Ponieważ na serwerze docelowym nie ma już zainicjowanego repozytorium git, pierwszym krokiem byłoby utworzenie jednego:

> cd ~/www/my_site
> git init

Następnie z dowolnego hosta, który ma repozytorium z najnowszymi zmianami, które chcesz wdrożyć (jak sądzę, z twojego pudełka programistycznego), po prostu musisz zrobić coś takiego, aby wdrożyć:

> git push --all ssh://username@target_host:port/~/www/my_site/.git

Możesz zobaczyć takie ostrzeżenie, jeśli Twoje repozytorium target_hostnie jest jeszcze aktualne:

> 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'.

(W normalnym gitwykorzystaniu nigdy widzisz tę wiadomość, jak sądzę, bo jesteś normalnie popychanie do gołych repozytoriach. Ale ponieważ nasza zdalnego repozytorium w tym przypadku jest to normalny repo zarówno z drzewa pracy i indeksu, gitjest zrozumiałe zaniepokojenie, że może coś zepsuć.)

Myślę jednak, że możemy bezpiecznie ustawić opcję „ignoruj” na twoim serwerze, ponieważ prawdopodobnie nie będziesz dokonywał żadnych zmian bezpośrednio w repozytorium. (Wszystkie zatwierdzenia powinny prawdopodobnie pochodzić z repozytorium programisty, a następnie zostać przekazane na serwer).

Więc ustaw dalej, aby nie wyświetlać ostrzeżenia za każdym razem, gdy naciskasz:

> ssh target_host 'cd ~/www/my_site/; git config receive.denyCurrentBranch ignore'

Te pushsię jedynie aktualizacje indeks jednak NIE pliki w drzewie samej pracy. Aktualizacja tych plików to jednak tylko część tego, co próbujemy zrobić, więc nasze zadanie nie jest zakończone, dopóki nie wypiszemy gitzawartości indeksu do samego drzewa pracy, w następujący sposób:

> ssh target_host 'cd ~/www/my_site/; git reset --hard'

(Uwaga: wszelkie zmiany, które mogły zostać wprowadzone w drzewie pracy na serwerze, zostaną zastąpione przez zawartość repozytorium).

Postępowałem również zgodnie z sugestią Mattikusa i stworzyłem pilota dla mojego serwera:

> git remote add h9 ssh://username@target_host:port/~/www/my_site/.git

Teraz muszę tylko wdrożyć:

> git push --all --force h9
> ssh remote_host 'cd ~/www/my_site/; git reset --hard'

Posunąłem się nawet tak daleko, że wrzuciłem te polecenia do skryptu, który nazwałem, script/deploywięc za każdym razem, gdy chcę wdrożyć, mam tylko jedno polecenie do uruchomienia.

Daj mi znać, jeśli znajdziesz jakieś błędy w tej instrukcji lub znasz lepsze rozwiązanie.

Jestem zarówno SF, jak i godaddy n00b, więc proszę o wyrozumiałość, ale tak czy inaczej, bardzo się cieszę, że to tutaj omówione.

Tylko 0,02 $, próbowałem zbudować git (dynamicznie) na moim Linux-ie, podłączając go do mojego konta chrzestnego, a nawet jeśli próbuję jedynie pchnąć się do innej pasywnej maszyny chrzestnej, nie udaje się to z powodu braku opensl. Może jeśli spróbuję zbudować gita statycznie za pomocą openssl, ale wydaje mi się, że to zły pomysł.

$ git remote add godaddy ssh://[email protected]//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

Nie na temat, ale czy jest to rodzaj braku wsparcia, którego powinienem oczekiwać od chrzestnego, czy powinienem żałować, że nie wybrałem hostów marzeń?

Z pozdrowieniami CJ

PS. Nie odpowiedź, ale sugestia, że ​​gdy git-receive pracuje nad chrzestnym (prawda?), To repozytorium z odłączonym drzewem roboczym to świetny sposób na wdrożenie w Internecie: http://toroid.org/ams/git- strona internetowa-howto

Najłatwiej to zrobić, uruchamiając coś takiego na zdalnym serwerze:

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

Następnie przy kasie:

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

Nie wymaga serwera ani niczego innego i powinieneś być w stanie pobrać / pobrać z tego komputera, tak długo jak masz dostęp do ssh.

Jeśli masz również skonfigurowany plik .ssh / config, powinien skorzystać z tego i użyć dowolnych skonfigurowanych kluczy prywatnych.

Jeśli planujesz dużo wypychać aktualizacje, możesz dodać zdalne repozytorium do kasy deweloperskiej:

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

Od tego momentu możesz:

git push godaddy

Aby uzyskać więcej informacji, sprawdź dokumenty online nagit push lub uruchom, git push --helpaby uruchomić stronę podręcznika lokalnego.