Ramas

Ramas

Al crear un repositorio en git estamos trabajando con ramas de manera indirecta, es decir, git crea una rama por defecto para llevar un registro de las modificaciones que tiene el repositorio a través del tiempo. Esa rama se llama master.

Mencioné que trabajamos de manera indirecta porque resulta práctico trabajar directamente sobre la rama por defecto para enfocarnos en el proyecto pero habrá ocasiones en que nos gustaría tener algunos cambios en el repositorio conservando la versión que tenemos del proyecto.

Es ahí cuando podemos utilizar las ramas. Una manera de pensar las ramas es como una variación del contenido del repositorio.

Al crear una rama, el proyecto comparte toda su historia hasta ese momento. En el momento en que creamos una rama y nos posicionamos en ella para trabajar, podemos realizar cambios y, al mismo tiempo podemos tener la seguridad de conservar una versión del código sin las modificaciones que estamos haciendo.

Por ejemplo en una rama llamada staging podemos tener código con funcionalidad adicional en comparación con el código que está en la rama principal master.

Una vez que estemos seguros de que la funcionalidad es la que queremos podemos unir esos cambios a la rama principal y utilizar esta última como la versión estable del código.

Mostrar una rama.

# Muestra la(s) rama(s) del repositorio 
# que se encuentran en el equipo
$ git branch

# Muestra todas la(s) rama(s) del repositorio
# incluyendo las remotas
$ git branch --all

Crear rama

# Crear una rama en el repositorio
$ git branch <nombre_rama>

Utilizar rama para trabajar.

# Una vez creada la rama 
# se utiliza checkout para cambiarnos 
# a esa rama y trabajar ahí
$ git checkout <nombre_rama>

Crear rama y posicionarse en la rama para trabajar en ella.

# Al utilizar checkoub -b se crea una rama si no existe
# Si la rama existe va a marcar error 
# (tendríamos que usar checkout sin la opción -b)
$ git checkout -b <nombre_rama>

Unir cambios de una rama a otra

Para unir los cambios de una rama en otra rama hay que posicionarse en la rama donde se van a unir los cambios y después se unen con la instrucción merge *.

# Regresar a la rama princial - "master"
$ git checkout master

# Una vez que estamos posicionados en la rama "master"
# vamos a unir los cambios de otra rama
$ git merge <nombre_rama_a_unir>

* También se puede utilizar rebase pero eso lo dejamos para otra ocasión.

Borrar una rama

# Regresar a la rama princial - "master"
$ git checkout master

# Borrar la rama con el nombre indicado. 
# NOTA: 
# Utilizar esto como último recurso porque se van a borrar
# los cambios que no se unieron a alguna otra rama.
$ git branch -D <nombre_rama>

¿Cuántas ramas es conveniente tener en cada repositorio?

En algunos proyectos – para sitios sin backend y algunos de PHP / WordPress – únicamente utilizo la rama principal – master – para llevar el registro del proyecto. Los cambios que realizo durante el desarrollo pueden quedar “flotando” y cuando están listos los integro al repositorio.

En otros proyectos – sobre todo de rails – utilizo una rama por ambiente en el cual se va a desplegar el código – production / staging -.

Hay otros acercamientos para flujos de trabajo más completos como gitflow. En mi caso considero contraproducente utilizar un flujo de trabajo que considero amplio / extendido para aplicaciones relativamente pequeñas.

El número de ramas puede variar dependiendo del número de personas en el proyecto, de la familiaridad que tienen con git y del tamaño del proyecto. Recomendaría (si no tienen un flujo de trabajo definido) tratar de utilizar el menor número de ramas (una o dos) para tener en mente qué parte del proyecto se está trabajando en cada rama y que la administración del repositorio no se interponga en el avance del proyecto.