Desarrollando con git
Desarrollar es un trabajo pesado, eso lo sabemos todos. Sobre todo, si queremos cumplir con todas las buenas prácticas que deberíamos.
Una de esas buenas prácticas es llevar un control de versiones de tu software. No porque necesites separar la versión 1 de la 2, sino porque llevar un control de versiones exhaustivo te ayudará después a encontrar errores, a poder revertir cambios, y a que otros (o tú mismo dentro de dos meses) puedan revisar tu código para ayudarte a mejorar.
Muchos de nosotros, cuando estamos desarrollando algo, lo hacemos en un estado que llamamos de preproducción. Esto sólo quiere decir que nuestro desarrollo no está abierto a todos, visible. Por tanto, es un sitio de pruebas, donde nos da igual que se escupan errores por pantalla, o que la página esté descuadrada.
Cuando estamos haciendo ese trabajo podemos hacer 100-200 cambios al día, y llevar un control de versiones de cada uno de los cambios que hacemos se puede convertir en algo pesado. ¿Cómo lo convertimos en algo asequible? Automatizándolo.
El scripting
Soy de los que usan git (y SVN) desde consola. Para mí es mucho más rápido porque juego con el scripting.
Por un lado, tengo una serie de alias definidos:
- alias fp=’git format-patch’
- alias ga=’git add .’
- alias gc=’git commit -a -m’
- alias gp=’git push origin master’
- alias log=’git log –pretty=oneline’
- alias sinc=’sh /Users/raven/Git/sinc’
- alias st=’git status’
De esta forma, cada vez que tengo un cambio nuevo, los comandos a ejecutar son los siguientes:
> ga
> gc "mensaje de descripción del commit"
> gp
Mi estructura de directorios incluye, en mi carpeta de usuario, una carpeta /Git donde tengo todos los repositorios de trabajo. Para cada uno de ellos tengo un pequeño script que lanza una sincronización con el servidor, de forma que si he cambiado algo allí, ese cambio se reflejará en mi directorio local.
Así, sólo tendré que ejecutar un comando, y se actualizará mi copia local. Todos los scripts de actualización los tengo en la carpeta /Git, en vez de dentro de cada uno de los repositorios, para que no interfieran con las copias.
git/raven.es> sh ../raven.sh
Ese archivo raven.sh tiene el siguiente contenido, que cambia para cada uno de los repositorios:
expect -c 'spawn rsync -avrhz -e "ssh -p" --progress --delete --exclude-from "/Users/raven/Git/exclude.txt" MIUSER@MISERVER:MIDIRECTORIO/raven.es/ /Users/raven/Git/raven.es/ ; expect password ; send "MIPASSWORD;\n" ; interact'
Este archivo exclude.txt tiene, en cada línea, nombres de archivos o directorios que se ignorarán en la sincronización, y puede tener el contenido que necesitéis. En mi caso, el archivo tiene el siguiente contenido:
sources
public_html/database.*
core.*
.svn
.git
stats
backup_site
backup
*/backup
versiones-backup
uploads
blogs.dir
upgrade
logs
cgi-bin
*.tar.gz
hiccup
wp-content/uploads/
wp-content/blogs.dir/
wp-content/upgrade/
error_log
*/error_log
cache
*/cache
Automatizando aún más
En mi directorio Git también tengo un archivo, sinc, que lanza la sincronización de todos los repositorios, lanzando uno a uno los sincronizadores individuales.
Aquí las posibilidades son múltiples. Dependiendo de vuestra forma de trabajar, os puede interesar lanzar la sincronización y el git add en la misma orden, o hacerlo todo en bloque. Podéis fabricaros vuestro propio script a medida.
Lo que tenéis que recordar es una cosa importante. Si hay algo que hacéis muchas veces de forma parecida, invertid tiempo en automatizarla. En muy poco tiempo notaréis la diferencia.
Deja un comentario