Como utilizar GIT con hostgator

Buscando una forma que no sea el uso de FTP para subir archivos encontre que muchos hostings utilizan git git y si lo pensamos un poco es una excelente forma de manejar nuestros despliegues a producción. Para lograr hacerlo en mi hosting Hostgator tuve que renegar un poco ya que no lo trae por defecto , pero todo lo que aprendi lo volque en este artículo que les enseñará como utilizar git con hostgator que espero les sirva

Como usar GIT con Hostgator

Para subir nuestros archivos al hosting no hay nada mejor que usar git, es rápido seguro , mantiene el historial de los cambios, y en lugar de ir pasando archivo por archivo como lo hace ftp permitiendo lugar a errores, git busca cuales fueron los archivos modificados los sube al hosting y una vez que los tiene arriba hace el deploy de todos juntos de manera que el cambio es rápidisimo y seguro.

Hostgator es uno de los hostings mas populares , es el que yo uso y pienso que es uno de los mejores en relación precio beneficio, es por eso que me gusto la idea de unir git y hostgator aunque este artículo también aplica perfectamente en cualquier hosting que tenga acceso ssh.

Lo primero que tenemos que ver es nuestro plan hostgator, solo podremos utilizar git si compramos el plan business o superior, ya que el baby o anteriores no tienen soporte ssh.
Sin soporte ssh tendriamos que utilizar git por medio de ftp y la verdad que lo probé y no funciona bien. Asi que si estas en un plan baby , pasate a business, son unos dolares más pero vale la pena.

Una vez en plan business , tendrás que iniciar un live chat en hostgator para que te habiliten el ssh, si bien hay un tutorial que te indica como activarlo desde la página, parece no funcionar , y la única forma que queda es pidiendo a soporte técnico que lo haga, puedes hacerlo por el chat o enviando un ticket.

Teniendo el acceso ssh ya podemos conectarnos al server, si usas windows tedrás que bajarte el programa putty, para poder hacerlo.

La conexión al server se realiza por el puerto 2222, por lo general es el puerto 22 pero hostgator lo cambio asi que si usan putty recuerden cambiar el puerto a 2222
el host de conexión es su dominio principal, ingresan estos datos y les pedirá usuario y pass, el usuario es el usuario de hostgator y el pass es el pass de hostgator también.

Con esto deberían estar adentro , si hacen un
pwd
Deberian ver que se encuentran en el home

cd public_html
ls

y deberian ver sus archivos y carpetas web.

Para hacer funcionar git como herramienta deploy tenemos dos formas de hacerlo, sobre una working copy directamente en el server o separando el repositorio de los archivos que lee apache, a continuación voy a explicar como hacerlo de ambas formas, luego veremos las ventajas y desventajas.

1 – Sobre la working copy

Algo realmente beneficioso seria hacer push directamente sobre la copia que apache esta leyendo de manera que se actualicen los archivos , pero hay que tener en cuenta algo muy importante, git solo permite hacer push sobre repositorios bare, los repositorios bare son repositorios que no mantienen una copia de nuestros archivos, y lamentablemente no nos sirven ya que lo que necesitamos es un repo con todo el contenido en el hosting de manera que apache pueda leer los archivos y ejecutarlos.

Al no permitir hacer push nos impide desde nuestra pc subir los cambios al server , es por eso que tenemos que configurar el directorio para poder hacerlo.

en primer lugar hostgator ya contiene instalado git , lo que nos deja muy bien para poder ejecutar comandos directamente en el hosting y preparar los directorios

Supongamos que nuestra página web apunta a la carpeta public_html/sitioWeb
Lo primero es inicializar git en el directorio , para esto hacemos

(nos movemos a la carpeta)
cd sitioWEb

(creamos el repositorio)
git init

(habilitamos la posibilidad de hacer push en el directorio)
git config receive.denyCurrentBranch ignore

Este último comando ejecutado modifica automáticamente el archivo .git/config agregando el ignore necesario para permitir los push sobre esa working copy que casualmente es la que lee el apache.

si utilizan windows , por las diferencias de fin de linea entre windows y linux (CRLF/ LF), git marca siempre los archivos en windows como si hubieran sido modificados, es por eso que es importante avisarle a git que se encargue de manejar esto automáticamente para no tener problemas.
ejecutamos
git config –global core.autocrlf true

y ejectuamos
git config –global core.whitespace cr-at-eol

esto hace que git quede configurado para manegar automáticamente el fin de linea

Un comentario al margen es que esto del fin de linea es uno de los grandes problemas con los que nos enfrentamos cuando tenemos diferentes entornos, git marca el cambio de fin de linea como un cambio en el archivo sin hacer nada tendremos muchos archivos para comitear sin cambios.

Si usan netbeans les dejo un plugin que les permite ver el fin de linea y cambiarlo en caso que sea necesario (plugin)
Recuerden que el fin de linea CRLF corresponde a windows y LF a linux/unix

agregamos los archivos a commitear en el repo

git add .

y hacemos commit

git commit -m”Primer commit”

con esto tenemos setado el repo en hostgator como una working copy.

Para completar el circuito nos hace falta un paso más. supongamos que clonamos el repo en nuestra pc local, modificamos , comiteamos y hacemos push, esto mueve los cambios al hosting, pero los mueve al repositorio del hosting, los cambios No se ven reflejados en la working copy, para esto es necesario hacer un checkout del repositorio, digo checkout y no pull porque los cambios realmente estan en repositorio solo que el head apunta a una version anterior, es por eso que se necesita el checkout para movernos a la cabecera que tiene los últimos cambios

git checkout -f

Con el parametros -f pisamos cualquier cambio local. si bien las imagenes logs y todos los archivos que se generen con el mismo uso del sitio NO se van a borrar, quedense tranquilos, lo que SI se borran o mejor dicho se Pisan son los cambios en archivos locales que commiteamos y pasan al servidor , estos archivos existen en el repositiorio a diferencia de los logs o imagenes (generados en el server), y es por eso que el checkout pisa los mismos archivos que estan en el server sin importar si fueron modificados ahi ,dejando la versión commiteada.

Para explicar mejor esto seria, si un usuario sube una foto al server , esta foto se encuentra en la working copy del server de manera que no podremos verla localmente pero tampoco se perdera con el checkout. ahora si un usuario modifica un archivo de texto en el server y nosotros commiteamos el mismo archivo de texto con cambios localmente , al hacer push el archivo que prevalece pisando al otro es el nuestro el que se commiteo localmente , esto es por la opcion -f que fuerza a pisar archivos con modificaciones, no forzar el checkout puede ser más peligroso aún ya que podrian darse conflictos que rompan los archivos que esta corriendo el server.

Si optamos por utilizar GIT es importante no utilizar más ftp y asegurarse que los archivos temporales no sean commiteados en el repo.

para evitar tener que entrar al hosting a hacer un checkout todas las veces que hacemos push , lo que conviene hacer es crear un hook que lo haga por nosotros.
para esto vamos a la carpeta .git/hooks que esta dentro de sitioWeb

cd .git/hooks

ahi creamos un archivo con el nombre post-receive

touch post-receive

si se fijan en el directorio hooks hay muchos otros archivos de ejemplos que le permitiran crear hooks para otras cosas si lo necesitan, por ahora vamos a crear el post-receive que se ejecuta luego de recibir data.

abrimos el archivo post-receive y agregamos las siguientes 2 lineas

#!/bin/sh
GIT_WORK_TREE=../ git checkout -f

esto ejecuta el checkout automáticamente luego de recibir un push.

guardamos el archivo y le damos permisos de ejecucion

sudo chmod +x post-receive

Con esto queda listo el hosting , ahora necesitamos clonar el repo en nuestras pcs
para ello podemos hacerlo cual cualquier interprete git como netbeans, git tortoise o con la consola en la pc local escribiendo la siguiente linea

(si usan windows al instalar git les instala una consola para ejecutar comandos bash que casualmente se llama “git bash”)

git clone ssh:[email protected]:2222/home/user/public_html/sitioWeb

*Deben reemplazar user por su usuario en las dos apariciones, antes de la @ y en el directorio.

*Deben reemplazar dominio por su dominio

esto les pide usuario y clave que son las mismas que usan para loguearse en hostgator.
y volá, traen el directorio con todos los cambios
si modifican , hacen commit y ejecutan

git push
todo aparece en producción, en el server hostgator muy rápido y completamente seguro

Para agilizar las cosas podemos hacer un archivito bash, que haga todas las tareas en el directorio que le pasamos, yo lo hice y se los doy para descargar, la idea es que descompriman y copien los dos archivos

gitinit.sh
post-receive

en su directorio home/user del servidor
luego si queremos inicializar un directorio hacemos

. gitinit.sh public_html/miSitioWeb

y listo , todo pasa automáticamente, se crea el directorio git, se cambian las configuraciones se agregan los archivos el hook etc.

aquí les dejo el script lo pueden ver y modficar como gusten.
Descargar GitInit

Segunda Opción Duplicando el repositorio

A diferencia del otro método , este es mucho más efectivo y natural ya que no requiere configurar la working copy para permitir pushes sobre ella , cosa que es peligroso y fue inhabilitado a proposito en las ultimas versiones de git.

El método es muy simple consite en crear un repositorio bare en el mismo server con el contenido del sitio web
inicializamos git en la carpeta web como se describio en los pasos anteriores luego clonamos el repo a un repo bare

git clone –bare sitioWeb sitioWeb.git

en este caso la carpeta sitioWeb.git pasa a ser nuestro repositorio principal como es bare no contiene los archivos fisicamente solo se encuentra el repositorio
luego como ya tenemos nuestro repo principal podemos elimiar el repositorio inicial de la carpeta sitioWeb

cd sitioWeb
rm -rf .git

eso elimina el repostorio de sitioWeb quedando solo el repo de sitioWeb.git
ahora en sitioWeb.git agregamos un hook para hacer el checkout sobre sitioWeb de manera que cada vez que hagamos push sobre sitioWeb.git se haga automaticamente el
checkout sobre sitioWeb.

cd ..
cd sitioWeb.git
cd hooks
touch post-receive

editamos el archivo
vi post-receive

y agregamos

!#/bin/sh
GIT_WORK_TREE=[ruta completa a sitioweb] git checkout -f

reemplazamos [ruta completa a sitioweb] por la ruta a la carpeta SitioWeb que lee el apache.
guardamos
lo hacemos ejecutable

chmod +x post-receive

y listo , para trabajar localmente clonamos el repositorio sitioWeb.git , que es nuestro repo bare
Cada vez que hagamos push sobre este los cambios se reflejaran en sitioWeb , es la carpeta interpretada por apache

Ventajas y desventajas

Como ventaja el primer método tenemos todo en el mismo lugar lo que simplifica las cosas donde estan los archivos esta el repo donde se reflejan los cambios y es el que clonamos , como el repo esta en el mismo directorio que el sitio , cualquier cambio de los usuarios puede ser fácilmente actualizado en el server con solo hacer un commit. Como desventaja apache corre sobre nuestro repo principal cualquier problema afecta directamente el repo , cualquier issue de seguridad también como por ejem si la carpeta .git es accesible desde la web podriamos perder nuestro código fuente.

El segundo método tiene como ventaja que el repo esta separado de los archivos que lee apache como asi también no necesitamos setear variables para ignorar el comportamiento normal , como desventaja el hook requiere setear explicitamente donde se encuentra el sitio web donde hacer checkout y requiere que para cada sitio que subamos tener que modificar a mano estos valores, en lugar de copiar el hook que creamos la primera vez.
Otra desventaja de esta segunda opcion es que al no tener el el repo vinculado no podriamos commitear archivos de usuarios en el server directamente, tendriamos que buscarle una vuelta para poder hacerlo.

This entry was posted in GIT. Bookmark the permalink.

One thought on “Como utilizar GIT con hostgator

  1. Estoy empezando con git ya que ahora tengo gente trabjando en proyecto y supongo es la forma más ordenada. Buscando como configurar bitbucket en el server di con esta web http://brandonsummers.name/blog/2012/02/10/using-bitbucket-for-automated-deployments/ que creo que es algo similar a lo que explicas. Yo todavía no lo implemente ya que no me queda muy claro como hacerlo. Hasta el momento veniamos 2 programadores trabajando sobre el server por ftp.
    Es un wordpress por lo que solo modificamos la carpeta de wp-content/themes e instalabamos algun que otro plugin. Lo que no me queda claro es como transformar eso en un repositorio, debo ahcerlo de todo el sitio o solo estas carpetas que trabajamos? Y luego de forma local como se configura para que el server local use estos archivos? ME parece que me falta lectura. Gracias por la info de todas formas

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>