Configurar un repositorio git en mi plan de alojamiento GoDaddy

Tengo un proyecto que está controlado por la versión usando git.

Lo que quiero poder hacer es configurar un repositorio en mi paquete de alojamiento compartido GoDaddy (habilitado para ssh) para que pueda implementarlo con solo presionar en lugar de arrastrar y soltar en FTP.

Cualquier consejo sería apreciado. Lo mejor sería una cuenta de alguien que ya lo haya hecho, pero personalmente no pude encontrar ninguna en línea.

Me encontré con el mismo problema con un sitio que había alojado en un paquete de alojamiento compartido HostNine. También le dan sshacceso, pero desafortunadamente no se han gitinstalado y ni siquiera le dan acceso para ejecutar gcc, lo que dificulta la descarga e instalación de git para su usuario.

La única forma en que podía pensar para evitar estas restricciones era copiar los binarios de git desde otra computadora que los tuviera. Quizás la misma solución funcionaría para usted y su host compartido GoDaddy. Esto es lo que hice:

Primero descubra qué arquitectura tiene su servidor. En mi caso fue de 32 bits (i386). Aquí hay un par de formas de resolverlo:

# 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

A continuación, debe encontrar otra computadora que ejecute Linux con la misma arquitectura y con git instalado. Ni siquiera tienen que estar ejecutando la misma distribución o versión de Linux, siempre y cuando tengan la misma arquitectura y pueda encontrar los archivos binarios y la biblioteca que necesita.

Para encontrar la ubicación del binario git principal:

> which git
/usr/local/bin/git

Algunos otros archivos binarios importantes (como git-receive-pack) también residen en el mismo directorio, por lo que recomiendo simplemente copiar todo /usr/local/bin/git*para asegurarse de obtener todo lo que necesita.

Otros archivos importantes son de los que depende git están bajo un directorio 'libexec' en algún lugar del sistema fuente. Si no los copia, es posible que reciba un mensaje de error sorprendente cuando intente hacer git push, como hice yo:

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

Para encontrar el directorio que contiene las bibliotecas principales de git en target_host, puede usar esto:

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

Recomendaría copiar esos archivos primero y luego intentar ejecutar git para ver si se queja de las bibliotecas compartidas faltantes. Si no es así, entonces eres (presumiblemente) bueno para ir. Si es así, sigue leyendo. (No use copiar sobre bibliotecas compartidas si ya existen en el host de destino y son la versión correcta).

Puede copiar los archivos con scp, rsync, ftp, o lo que usted se sienta cómodo. Solía scpalgo como esto:

> 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

Luego ssh a target_host. Deberá agregar algunas líneas como estas a su ~/.bashrc:

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

Si olvida este paso, es posible que se sorprenda al ver este error cuando hace un git push:

git-receive-pack: command not found

Esto está documentado en las preguntas frecuentes de Git en git.or.cz:

Básicamente, el problema es que 'git-recibir-paquete' no está en el $ PATH predeterminado en el extremo remoto.

...

• Asegurarse de que tiene la ruta correcta configurada .bashrc(no solo .bash_profile)

GIT_EXEC_PATHestá documentado en 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.

Fuente de su nuevo ~/.bashrc. Ahora intenta correr git.

Esto es lo que me dio la primera vez:

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

Pude averiguar la ubicación de las bibliotecas compartidas para copiar ejecutando esto en la máquina de origen:

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

En mi caso, yo sólo tenía que copiar /lib/libcrypto.so.4a ~/libmi target_hosty todo estaba bien.

¡Ahora debería trabajar giten su servidor de alojamiento compartido y debería poder impulsarlo!

Ahora debe crear un nuevo repositorio git y un árbol de trabajo en su servidor o copiar su repositorio / árbol de trabajo existente.

Por cierto, no creo que un repositorio desnudo sea lo que desea en el servidor en este caso, ya que dijo que quería implementar los archivos de contenido reales (en lugar de solo los config HEAD objects/ refs/archivos que se incluirían en un repositorio desnudo) siempre tu haces a git push.

toolmantim.com explica la diferencia entre un repositorio git regular y un repositorio simple :

Un repositorio git predeterminado asume que lo usará como su directorio de trabajo, por lo que git almacena los archivos reales del repositorio desnudo en un directorio .git junto con todos los archivos del proyecto. Los repositorios remotos no necesitan copias de los archivos en el sistema de archivos a diferencia de las copias de trabajo, todo lo que necesitan son los deltas y las cosas binarias del repositorio en sí. Esto es lo que "desnudo" significa git. Solo el repositorio en sí.

Asumiré por el momento que ya ha creado un directorio en el target_hostque desea implementar su sitio web (o lo que sea que esté implementando). Llamemos a ese directorio ~/www/my_site. Es posible que incluso haya ftp'd sobre todos sus archivos ~/www/my_site already. (Tener o no tener no es importante). También asumiré por el momento que aún no ha copiado el subdirectorio .git ~/www/my_site(aunque debería funcionar bien si lo ha hecho).

Como todavía no hay un repositorio de git inicializado en target_host, su primer paso sería crear uno:

> cd ~/www/my_site
> git init

Luego, desde el host que tenga el repositorio con los últimos cambios que desea implementar (su cuadro de desarrollo, supongo), solo tiene que hacer algo como esto para implementar:

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

Es posible que vea una advertencia como esta si su repositorio target_hostno está actualizado:

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

(En el gituso normal , nunca ves ese mensaje, creo, porque normalmente estás presionando a repositorios desnudos . Pero dado que nuestro repositorio remoto en este caso es un repositorio normal con un árbol de trabajo y un índice, gites comprensiblemente preocupado de que pueda estropear algo.)

Sin embargo, creo que es seguro para nosotros configurarlo para 'ignorar' en su servidor, porque no es probable que realice ninguna confirmación directamente en el repositorio allí. (Todos los commits probablemente deberían originarse en su repositorio de desarrollo y luego ser enviados al servidor).

Así que adelante y configure esto para que no vea la advertencia cada vez que presiona:

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

El pushsolo actualiza el índice, sin embargo, NO los archivos en el árbol de trabajo. Sin embargo, actualizar esos archivos es solo el punto completo de lo que estamos tratando de hacer, por lo que nuestro trabajo no se realiza hasta que le indiquemos gitque escriba el contenido del índice en el árbol de trabajo, así:

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

(Nota: Cualquier cambio que haya tenido en su árbol de trabajo en el servidor será sobrescrito por lo que está en el repositorio).

También seguí la sugerencia de mattikus y creé un control remoto para mi servidor:

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

Así que ahora todo lo que tengo que hacer para implementar es:

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

Incluso fui tan lejos como para lanzar estos comandos en un script que nombré, script/deployasí que cada vez que quiero implementar solo tengo que ejecutar un comando.

Avíseme si encuentra algún error en estas instrucciones o si conoce una solución mejor.

Soy SF y GoDaddy n00b, así que tengan paciencia conmigo, pero de todos modos, estoy muy feliz de ver esto discutido aquí.

Solo mis $ 0.02, intenté construir git (dinámicamente) en mi caja de linux, manchándolo a mi cuenta godaddy, e incluso si solo intento empujar a la máquina godaddy pasiva, falla debido a la falta de openssl. Tal vez si intento construir git estáticamente con openssl, pero también parece una mala idea.

$ 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

Fuera de tema, pero ¿es este el tipo de falta de apoyo que debería esperar de GoDaddy, debería arrepentirme de no haber elegido Dreamhosts?

Saludos cordiales CJ

PD. No es una respuesta, sino una sugerencia de que una vez que git-reciben funciona en godaddy (¿o sí?), Un repositorio con un árbol de trabajo separado es una excelente manera de implementarlo en la web: http://toroid.org/ams/git- sitio web

La forma más fácil de hacer esto es ejecutar algo como esto en su servidor remoto:

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

Luego, en su caja de desarrollo:

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

No se requiere servidor ni nada más, y debería poder obtener / extraer de esa máquina siempre que tenga acceso ssh.

Si también tiene configurado su .ssh / config, debería aprovecharlo y usar las claves privadas que haya configurado.

Si planea enviar muchas actualizaciones, puede agregar un repositorio remoto a su pago de desarrollo:

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

Entonces a partir de ese momento puedes:

git push godaddy

Para obtener más información, consulte los documentos en líneagit push o ejecútelos git push --helppara iniciar la página de manual en su local.