Cómo manejar webs configurables con Git

Cuanto más utilizo Git más me gusta. Lo último es la solución que he encontrado para manejar las configuraciones de la Red de Blogs de Montaña (RBM) usando Git. Para poneros en situación rápidamente, la RBM consta de varios blogs (8 en estos momentos) cuyo elemento estructural en común es un único «theme» de WordPress configurado con distintos colores (por ejemplo ver el blog de senderismo o el blog de espeleología). Mi problema era cómo manejar las actualizaciones de los themes sin volverme loco realizando 8 veces los mismos pasos para cada blog.

La solución al problema se llama Git y además es una solución universal que se puede aplicar a cualquier problema de este tipo (una base común y diferentes conjuntos de ficheros añadidos necesarios para cada solución final).

La idea es hacer que Git controle en su rama «master» la última versión de las páginas de la RBM en su forma básica y crear tantas ramas como configuraciones del proyecto base queramos. Tras cada release del proyecto simplemente con un «git rebase» sincronizaremos las ramas y tendremos el resultado configurado para todos los blogs.

Mejor será verlo con un ejemplo. Para simplificar he creado un proyecto «prueba» con un fichero que modificaremos (imaginemos que es el styles.css dónde se guardan los colores a personalizar). En un proyecto real existirán más ficheros que difieran, obviamente, pero el tratamiento es el mismo. Así está al principio el repositorio en el que hemos llegado a una versión 1.0 estable (creamos una etiqueta para marcarlo si queremos):

En este punto tenemos una configuración base lista para ser configurada y releaseada. Sobre esta base podemos simplemente configurar el primer blog (lo que sea: cambiamos colores, añadimos gráficos, modificamos código…). Cuando tengamos la primera versión configurada crearemos una rama nueva dejando que el master apunte a la base:

git commit -a -m «version A lista»
git branch versionA
git reset –hard HEAD^

quedando el siguiente resultado:

Y se puede repetir tantas veces como se quiera (tantas configuraciones como se deban realizar). Por ejemplo, añadamos un par de configuraciones más (modificar los ficheros base y lanzar las 3 instrucciones de arriba):

Una vez creadas las ramas ya tenemos preparado el entorno para siempre. Si queremos la versionB de la web simplemente escribimos:

git checkout versionB

y ¡voila! el contenido del directorio del proyecto es ahora la versión B. Y si a esa versión le detectamos cualquier problema, simplemente lo corregimos y hacemos el commit correspondiente:

Una vez se ha terminado la versión 1.0 del proyecto (o a mitad) podemos trabajar en la siguiente versión. Situándonos sobre la rama master (git checkout master) podemos ir haciendo cambios en el set de páginas base de nuestro proyecto. Llegará el momento en el que consideremos que hemos terminado y que tenemos lista la version 1.1:

¿Que hacemos ahora para integrar los cambios con las distintas configuraciones? Nada más fácil:

git checkout versionA
git rebase master

Y esto se debe repetir por cada configuración que tengamos. El arbol queda ahora así:

Para terminar le podemos añadir una etiqueta para conservar la versión y actualizar con el repositorio remoto:

git checkout master
git tag v1.1
git push –all

Muy importante hacer el push con el modificador –all para que las ramas con las versiones se actualicen.

Además todo lo explicado es muy fácil automatizarlo con scripts para hacer deploys rápidos en el servidor. También se puede usar Git Extensions desde Windows para ver gráficamente las ramas (de ahí se han sacado las capturas).

¿Como lo hubierais hecho con vuestro SCM favorito? Lo dicho, ¡pobre Perforce!