¡Oh my git! – Branches

¡Bienvenidos un día más a un nuevo rootie queridos amigos! La semana pasada vimos en la segunda entrega sobre git los comandos básicos y hoy vamos a meternos en un tema muy interesante que os va a ayudar enormemente. Estoy hablando sobre las ramificaciones – a las que me voy a referir indistintamente como branch/es ramas -.

Además en el tema de hoy no sólo me voy a limitar a contaros cómo funciona y cómo usarlo, vamos a ver un poco de cómo git funciona internamente y os regalaré un briconsejo.

Branching (Ramificaciones).

Para entender cómo funcionan las ramas, primero debemos entender cómo funciona git internamente. Como recordaréis, los cambios en nuestros proyectos, se guardaban como un conjunto de instantáneas, no como una lista de cambios. Cuando se realiza un commit, git crea un punto de control que contiene: un apuntador (pointer) a la copia puntual de tus archivos preparados, los metadatos, el autor y el mensaje de confirmación.

Según se va trabajando y realizando confirmaciones, estas crearán apuntadores a las confirmaciones anteriores, tras varias confirmaciones, sencillas el registro es algo parecido a esto:

git-confirmaciones

Una rama o branch en git no es más que un apuntador móvil, apuntando a una de estas confirmaciones. El branch por defecto del repositorio es master, esta se crea cuando realizamos la primera confirmación.

git-branch-mindblow
Claro master es… WHAAAAT?

Con cada confirmación, la rama irá avanzando automáticamente. Entonces, todo este tochaco que os he metido que tiene que ver, pues básicamente para poder explicaros que cuando creáis una nueva rama, simplemente se crea un nuevo apuntador, que podréis mover libremente, desde un commit específico, lo que hará que todos los cambios siguientes, queden registrados en un histórico separado del resto de tus branches hasta el momento, claro está, que decidas fusionarlas.

git-branches-head
Aquí podemos ver un gráfico donde master esta por detrás de nuestra rama testing.

Branching, the good way.

Antes de seguir explicando las branches, es bueno hacer un inciso y daros un consejo sobre cómo trabajar con ellas. Normalmente cuando empezamos a trabajar con git y no tenemos mucha experiencia, solemos trabajar directamente en master, confirmando y pusheando todos archivos a master esto es una manera tan buena como cualquier otra de trabajar, pero hay una mejor, especialmente, cuando trabajas en equipo.

Cuando se trabaja bajo control de versiones, lo recomendado es no trabajar directamente en master, lo mejor es ir creando branches para cada funcionalidad o bug fix y una vez completado el trabajo previsto, fusionar la rama en master. Esto tiene varias ventajas, ya que ofrece una manera de aislar los bugs o el desarrollo de nuevas funcionalidades del desarrollo principal, que puede estar siendo usado en producción, etc. También evita que tu trabajo pueda interferir en el de otros miembros del equipo. La verdad es que esta es una de mis formas favoritas de trabajar, y por lo tanto no puedo dejar de recomendarla lo suficiente.

git-experto-ramas
Nuestro experto en ramas…

Creando branches (ramas).

Para crear una ramificación de nuestro repositorio simplemente deberemos ejecutar el siguiente comando:

Ejecutar este comando no producirá ningún mensaje, ni confirmación, para comprobar que nuestra rama esta creada usaremos el comando git branch, nos mostrará una lista de nuestras branches locales.

Como podemos ver aparecen master (con un asterisco a la izquierda, lo que indica que es la rama en la que nos encontramos) y nuestra nueva rama. Para empezar a trabajar en nuestra rama utilizaremos el comando git checkout <nombre-de-la-rama>

En el snippet superior vemos que el puntero del repositorio se ha movido de master merk/oh-my-root lo que hará que todos los cambios se registren en la nueva rama. Además, en mi repositorio no había confirmado ni pusheado el archivo de ejemplo, con lo que al cambiar de rama, este archivo y su estado se han movido a la rama. En este momento podremos trabajar en nuestra rama, con los mismos comandos que ya hemos visto.

Protip: si queremos crear una rama y automáticamente cambiar a la misma podemos ejecutar el siguiente comando:

Agregando el modificador -b nos creará la nueva rama a la que estamos intentando cambiar.

Fusionando ramas.

Una vez hemos finalizado el trabajo en nuestra rama y cuando tenemos todo nuestro contenido confirmado y pusheado, llega el momento de combinar esa nueva funcionalidad o ese fix a nuestra rama principal (o a cualquier otra), para ello utilizaremos el comando merge y nos ayudaremos del comando diff  para comparar nuestra rama con la rama de destino.

El primer paso, si queremos ser precavidos y ahorrarnos dolores de cabeza, es actualizar la rama de destino (ya sabes, git checkout <rama>, git pull origin <rama>) y una vez estamos seguros que tanto destino como origen no tienen ningún cambio pendiente, hacemos checkout a la rama de destino y ejecutamos git diff <rama_de_destino>..<rama_de_origen>

Como podemos ver, el resultado del comando nos muestra la diferencia entre ambas ramas de una forma bastante clara. En este caso podemos ver que está creando un nuevo fichero y nos muestra el contenido modificado.

git-merge-conflict
Automatic merge failed; fix conflicts and then commit the result.

Ahora que ya estamos seguros que todo lo que existe en nuestra rama, ha de ser fusionada en otra, vamos a usar git merge <nombre_del_origen> este comando nos fusionara la rama de destino, con la rama en la que nos encontremos y este es el resultado:

Un detalle importante acerca de la fusión de ramas, es que una vez que esta se ha realizado, no sólo los ficheros y los cambios se fusionarán, también lo hará el historial de confirmaciones (commits), lo que nos permitirá mantener un historial actualizado que nos será de gran ayuda a la hora de buscar en qué punto se hizo cierto cambio, o quién hizo determinado commit.

Por último, tendremos que hacer push de nuestra rama de destino para que todos los cambios queden registrados en el servidor.

Una buena práctica a tener en cuenta es borrar siempre las ramas que ya hayan sido fusionadas si no estimas que vayas a volver a necesitarlas, para ello tenemos dos comandos:

Para eliminar la rama del servidor remoto usaremos git push con una variación, delante del nombre de la rama agregaremos :

Y para eliminarla de nuestra máquina local:

Con estos dos simples comandos, nos aseguramos de mantener un repositorio limpio y ordenado, lo que hará mucho más fácil su mantenimiento.

Y hasta aquí, el post sobre las ramas. En nuestra próxima entrega sobre git hablaremos sobre comandos avanzados y los temibles conflictos. Para cualquier duda, pregunta, comentario, soborno o amenaza, podéis usar los comentarios o en nuestras redes sociales Facebook y Twitter.

One Comment

Deja un comentario

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