Git y GitHub. Submódulos y depuración.

Una vez ya hemos visto lo referente al trabajo con ramas en Git que comentamos en los artículos anteriores, Ramificaciones, flujo de trabajo y etiquetas, estamos en disposición de enfrentarnos a cualquier proyecto cuyo control de versiones se realice con GIT. Sin embargo, no quería terminar esta serie de artículos sobre GIT y GitHub, sin comentar un aspecto muy interesante, como son los submódulos, y las posibilidades que nos ofrecen.

Es habitual, cuando estás trabajando en un proyecto, apoyarte en el trabajo de terceros. Utilizar bibliotecas externas a tu proyecto, iconos, temas, o lo que consideres. En este caso, lo interesante es poder tener este otro proyecto dentro del tuyo propio pero sin que un proyecto afecte al otro. ¿Cual sería el objetivo? Realizar el control de versiones del proyecto principal de forma independiente al proyecto secundario.

¿Como resolver esta situación? Para esto tenemos los submódulos en Git.

Los submódulos en Git

El concepto

Tal y como he comentado en la introducción, el problema de mantener un proyecto Git dentro de otro, se resuelve con el uso de submódulos. Esto nos permite mantener un repositorio Git como un directorio de otro repositorio Git. Es decir, podemos clonar un repositorio dentro de otro repositorio, pero manteniendo ambos por separado.

Manteniendo el control de versiones de ambos proyectos por separado, los cambios y modificaciones que se realizan en uno de los proyectos no afecta al otro. De esta manera, si queremos incorporar un cambio en uno de los submódulos, lo podemos realizar, sin problema alguno, tal y como lo hacemos de forma habitual. Y lo mismo para el caso del proyecto principal.

Añadir un submódulo a nuestro proyecto

Una vez tenemos claro el concepto, y lo que queremos hacer, es decir, mantener ambos proyectos de forma separada, vamos a meternos en harina.

Supongamos que tenemos un proyecto al que queremos añadir una serie de funcionalidades que han sido desarrolladas por un tercero en un proyecto independiente. Este es el momento de confiar en los submódulos.

Vamos a añadir este proyecto como un submódulo de nuestro proyecto principal. Para ello, lo que vamos a hacer es clonar este repositorio dentro de un directorio de nuestro proyecto. La solución es tan sencilla como ejecutar la orden:

git submodule add URL DIRECTORIO

donde:

• URL es la dirección del repositorio de esta biblioteca que queremos incorporar a nuestro proyecto.
• DIRECTORIO es el directorio en el que queremos clonar esta biblioteca.

Dentro de este DIRECTORIO podemos trabajar tal cual trabajamos en cualquier otro repositorio Git. Es decir, podemos realizar nuestros propios cambios, hacer commit, etc. Todo de forma independiente a nuestro proyecto principal.

De esta manera, si bien DIRECTORIO se encuentra dentro de nuestro proyecto principal, Git lo contempla en todo momento como un submódulo. De esta manera, para el control de cambios del proyecto principal, no se tiene en cuenta este directorio. Este directorio tiene su propio control de cambios.

Clonar un proyecto con submódulos

Cuando clonamos un proyecto que tiene submódulos, estos los encontraremos vacíos. Aunque DIRECTORIO esté presente, no contendrá nada. A menos que cuando clonemos el proyecto principal lo tengamos en cuenta. ¿Cómo? Para ello, ejecutaremos la siguiente orden:

git clone --recusive URL

donde URL es la dirección del repositorio principal.

En otro caso, una vez hemos clonado el repositorio principal, tendremos que actuar sobre los submódulos. Para ello, ejecutaremos las siguientes órdenes:

git submodule init
git submodule update

Depuración en Git

Es indudable que esto de tener varias ramas en paralelo, la de producción, la desarrollo, donde corregimos pequeños errores, etc, pueden y seguro que llevarán a cometer errores. Esto es inevitable.

En un momento determinado del desarrollo de una aplicación, puede suceder que algo que anteriormente funcionaba, o funcionaba de una determinada manera, deje de funcionar, o al menos no lo haga como lo debería hacer.

En estas circunstancias, es interesante poder mirar atrás, y ver que es lo que hicimos, para que aquello dejara de funcionar. Así, Git nos ofrece algunas herramientas, que nos ayudan a localizar dónde podría estar el error.

Con la orden git blame podemos ver en cualquier archivo que tengamos bajo nuestro sistema de control de versiones, cuando se ha escrito o modificado una línea. El aspecto sería algo como el que puedes ver en la siguiente imagen:

Si te fijas en la imagen anterior, lo que aparece al principio de cada línea es parte del código de confirmación (commit) SHA-1, y luego el nombre del autor que lo realizó y cuando se realizó.

Esto nos puede dar suficientes pistas para tener una idea aproximada de si el problema está en este archivo o no, en función de quién realizó los cambios o cuándo se realizaron.

Existe otro método, algo más complicado, que es git bisect. Este nos permite realizar una búsqueda binaria. Este se utiliza para el caso de que el número de confirmaciones sea muy elevado, y localizar dónde o cuándo se produjo el error sea mas complicado.

Conclusiones

Con esto hemos visto una aproximación al trabajo con submódulos. Sin embargo, y como te puedes imaginar, esto se puede complicar sobremanera. Solo piensa, en el momento de hacer cambios en submódulos, confirmaciones, etc. Sin embargo, utilizando la depuración como hemos visto, puede ayudarnos a paliar estos problemas.

Sin embargo, es una muy buena solución para trabajar de forma aislada en proyectos interdependientes, pudiendo colaborar en todos ellos de forma simultánea.

En el siguiente artículo, y para terminar esta serie, veremos cómo relacionarnos con servicios externos como pueden ser GitHub y GitLab.