Git+Bitbucket: mi almacen de dotfiles

Estándar

¿Quién dijo que Git era sólo un software de control de versiones para código? No soy el único, ni el primero, que usa este control de versiones para algo más que gestionar las fases del desarrollo en sus proyectos, como por ejemplo como almacen centralizado de dotfiles, los archivos de configuración de algunas aplicaciones del mundo Linux.

Los dotfiles, que reciben su nombre por el convenio que hace que el nombre los ficheros ocultos de linux comienzan por un punto, son los ficheros de texto corrientes que pretenden aislar la configuración de algunas aplicaciones en *NIX para favorecer el traslado de dichas configuraciones entre distintas instalaciones. Algunos de los programas que uso y que configuran las propiedades de la aplicación a través de este tipo de ficheros son zsh, vim o tmux.

Si usamos Git como almacén y algún tipo de alojamiento de repositorios online, como Bitbucket, y haciendo uso de la característica de submódulos de git podemos alcanzar un buen nivel de organización y, sobre todo, una portabilidad bastante cómoda. Vamos a hablar un poco de los submodulos de Git.

Un submodulo no es mas que una referencia a otro repositorio Git dentro de un repositorio. La única diferencia entre hacer un clone y añadir un submodulo a un repositorio es que el repositorio principal, el que contiene el módulo, tiene conocimiento del módulo y una referencia al commit en el que está en ese momento. Por lo tanto, si modificamos algo en la copia del submodulo y mandamos esos cambios al servidor, el proyecto principal también cambiará y tendremos que actualizarlo también.

Pero, ¿cómo añadimos nuevos submodulos a nuestro proyecto? Fácil, usando la instruccion git submodule add

git submodule add url_del_repositorio {carpeta_del_submodulo}

Si obviamos el último argumento, el comando realizará un clon del repositorio en la carpeta de nuestro proyecto con el mismo nombre que el que tiene el repositorio. El segundo argumento lo usamos para cambiar la carpeta de destino y/o el nombre del la carpeta que se creará con la copia local del repositorio a clonar. Esta acción creará un fichero llamado .gitmodules si es la primera vez que la ejecutamos en nuestro proyecto y que contiene las referencias a los módulos registrados en nuestro proyecto.

¿Y si queremos realizar cambios en el submodulo? Lo podemos hacer como lo haríamos normalmente. Cambiamos los ficheros necesarios, realizamos el commit pertinente y mandamos los cambios al repositorio con la orden push. Pero esta vez hay algo que cambia en nuestro proyecto principal, el estado del repositorio nos marca que hemos cambiado algo y es que al haber cambiado el commit en el que se encuentra el submodulo en ese momento el proyecto principal también hay que actualizarlo. Esto conlleva hacer un commit y un push en el repositorio principal.

Si lo que queremos en cambio es actualizar los módulos que tenemos ya agregados a nuestro repostorio la cosa se complica un poco más. El punto en el que más se complica es al hacer un pull del submódulo debido a que los módulos trabajan en un modo llamado detached HEAD, lo que significa que no trabajan en ninguna rama en concreto, sino que son simplemente un copia del último commit relizado en el servidor del cual clonamos el repositorio. Por ello si ejecutamos la órden pull sin estar en una rama en concreto no veremos el resultado esperado. El siguiente flujo de órdenes actualizará los repositorios disponibles en el fichero .gitmodules.

git submodule update --init #para asegurarnos de que el módulo esta registrado

#Esta órden recorre todos los módulos y ejecuta la orden que le digamos
#en este caso el pull necesario
git submodule foreach git pull origin master

#En caso de haber algún cambio en los módulos
git commit -am"Submódulos actualizados"
git push

Con esta serie de órdenes bajaremos los cambios de la rama master de cada submódulo y actualizaremos la copia que tenemos en nuestro proyecto.

Con estas sencillas órdenes podemos fácilmente distribuir nuestros dotfiles a través de distintos repositorios y añadirlos como submódulos a un repositorio principal para tenerlos organizados de manera jerárquica. En mi caso, mi repositorio de Vim contiene a su vez un submodulo por cada plugin que quiero tener disponible en Vim, y usando nuestor querido Pathogen podemos manejar nuestro conjunto de plugins.

Consideraciones a tener en cuenta al usar submódulos en Git

Existen algunos problemas a la hora de usar submódulos en Git (no todo iban a ser ventajas), como por ejemplo:

    • Si realizamos un push en el proyecto principal modificando el commit al que apunta un submódulo, pero no hemos hecho un push en el submódulo de ese commit en particular, si alguien baja ese repositorio Git no será capaz de encontrar el commit y tendremos problemas de referencias.
      Hay que tener muy en cuenta el tema de la detached HEAD cuando se trabaja directamente en un submódulo. Si hacemos cambios que no pertenezcan a ninguna rama, no hacemos commit y acto seguido realizamos un git submodule update Git se cargará todos nuestro cambios y será dificil volver a recuperarlos. Es aconsejable cambiar a una rama existente o crear una nueva cuando bajamos a trabajar directamente sobre un submódulo.
  • Un saludo y hasta el siguiente post! 🙂

    Anuncios

    Un comentario en “Git+Bitbucket: mi almacen de dotfiles

    1. Pretty nice post. I just stumbled upon your blog and wanted to say that I have really enjoyed browsing your blog posts.
      After all I’ll be subscribing in your rss feed and I’m hoping you write once more soon!

    Responder

    Introduce tus datos o haz clic en un icono para iniciar sesión:

    Logo de WordPress.com

    Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

    Imagen de Twitter

    Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

    Foto de Facebook

    Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

    Google+ photo

    Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

    Conectando a %s