En el articulo anterior vimos como inicializar un repositorio con git y utilizar sus comandos mas básicos. En esta ocasión, veremos que son las ramas, para qué nos sirven y como podemos trabajar con ellas.

Una rama es un entorno de desarrollo independiente donde se genera un nuevo área de trabajo, la cual cuenta con su propia área de preparación y sus propios commits. El objetivo de trabajar con ramas es poder agregar nuevas funcionalidades o realizar pruebas sin afectar al entorno original.

Para empezar vamos a ver algunos comandos útiles para trabajar con ramas:
- git branch

lista las ramas del repositorio

- git branch <nombre>

crea una nueva rama con el nombre que le indiquemos

- git branch -d <nombre>

elimina la rama indicada siempre y cuando no tengas cambios
sin fusionar.

- git branch -D <nombre>

Elimina la rama forzadamente.

- git branch -m <nuevo-nombre>

Renombra la rama actual por el nombre indicado

- git branch -a

Enumera las ramas del repositorio remoto.

- git checkout <nombre>

Nos permite cambiar de rama a la que le indiquemos.

- git checkout -b <nombre>

Crea una nueva branch con el nombre indicado a partir de la actual

- git checkout -b <nueva-rama> <rama-existente>
Crea una nueva rama a partir de otra existente que le indiquemos

Fusión entre ramas

- git merge <rama-a-fusionar>
Es el comando que nos sirve para fusionar una o mas ramas dentro de la rama activa.

A la hora de fusionar ramas, es muy normal encontrarnos con conflictos. Estos ocurren cuando en una fusión dos personas cambian las mismas líneas de un archivo o bien si se eliminó un archivo que otra persona estaba modificando. Dado que git no sabe como resolverlos, delega la responsabilidad
en el desarrollador, dejando la fusión en "stand by" hasta que el conflicto se resuelva manualmente.

¿Cómo se resuelven?
Cuando se genera un conflicto en un archivo, veremos algo así:

<<<<<<< HEAD
Caso de prueba
=======
Otro caso de prueba
>>>>>>> prueba

Donde HEAD hace referencia al directorio de trabajo actual (donde estamos parados, es decir el branch actual) y prueba es la rama con la cual estamos queriendo fusionar.
De esta manera, git nos enseña el código existente en esa línea conflictiva que tenemos en la rama actual y el que viene de la rama "entrante".

Esto lo vamos a resolver dejando en la zona del conflicto el código que deseemos, ya sea el actual, el de la rama entrante o alguna combinación entre ambos. Una vez hayamos terminado, para completar la fusión agregamos los cambios al área de staging y luego los confirmamos con un commit.

$ git add .
$ git commit -m "Solucion de conflictos en merge"

 

Flujos de trabajo con ramas

Cuando hablamos de flujos de trabajo, nos referimos a una forma de aprovechar git que nos permita trabajar en un proyecto de forma eficiente y productiva, donde cada desarrollador sepa de que manera agregar nuevas funcionalidades, sin generar conflictos con las que ya existen, probarlas y luego fusionarlas.
Para que un flujo de trabajo sea considerado exitoso, debe ofrecer:

- Facilidad para volver atrás en caso de existir errores al publicar nuevos cambios
- Escalabilidad acorde al tamaño del equipo
- Facilidad a la hora de comprender su funcionamiento, para que todos los integrantes del equipo se adapten a el rápidamente.

Para finalizar, vamos a ver de un flujo de trabajo conocido: Enviroment based o basado en ambientes.
Como su nombre indica, esta estrategia es ideal para cuando tenemos distintos ambientes en un proyecto y queremos asegurarnos de que cada nueva funcionalidad que desarrollemos se agregue a ellos una vez esté completa y testeada.
Las funcionalidades nuevas que creemos vamos a trabajarlas sobre nuevas ramas especificas y una vez estén terminadas y testeadas, las fusionaremos con las ramas de los ambientes que usamos.

Por ejemplo, supongamos que tenemos 3 ambientes: desarrollo, certificación y producción, cada uno de ellos con sus respectivas ramas.

En master tendremos únicamente lo que ya se encuentre en un ambiente productivo.

En la rama de certificación vamos a tener todas las nuevas funcionalidades certificadas y probadas, listas para ser puestas en producción.

La rama desarrollo la utilizaremos para probar el funcionamiento de lo que vamos agregando y ver como se integra con el resto de funcionalidades.

Como conclusión, podemos decir que para un equipo de desarrollo resulta fundamental utilizar un flujo de trabajo, ya que permite mejorar los procesos, ahorrar tiempo, eliminar errores y aumentar nuestra productividad.