Recomendaciones para el manejo de ramas
Tags: github, bestpractices, git, gitbranch
Published: 2019-11-12 21:14:09

Durante el desarrollo de un proyecto es muy común que el equipo tenga la necesidad de crear branches/ramas para poder trabajar de manera aislada todos los cambios, correcciones y nuevas características del proyecto a realizar esto para no afectar el flujo de trabajo de terceros, esto evitará mezclar código de distintas líneas de desarrollo. Por lo que como se comenta en el post anterior llamado **[Recomendaciones para generar un buen commit](https://dev.to/konami12/recomendaciones-para-generar-un-buen-commit-544i)**, para el manejo de branches también es recomendable contar con una guía de buenas prácticas.

### 🚨Recordatorio

Siempre que un `branch` ya sea utilizado es necesario borrarla del repositorio esto es con la finalidad de contar con un repositorio limpia y evitar tener muchos `branches` que no sean útiles.

### 🏗 Estructura

El nombre de una `rama` se estructura de 2 partes diferentes el `tipo` y `nombre` estas partes son divididas usando / como se muestra en nuestra en el ejemplo siguiente.


![Ejemplo estructura de una rama (**Fig-01**).](https://cdn-images-1.medium.com/max/2720/1*8qn1iKK7kzYcEmhGg-6Aug.png)*Ejemplo estructura de una rama (**Fig-01**).

> **Nota:** Los nombres de las ramas tienen que ser escritos en **lowerCamelCase**.

### 🔖 Type/Tipo

El tipo es la primer parte de la estructura del `branch` y este puede ser ser de los siguientes tipos.

* **add:** Se generan una nuevas funcionalidades.

* **fix:** Se realizan correción de Bugs.

* **refactor:** Refactorización de funcionalidades y mejoras.

* **delete:** Se eliminan funciones o archivos.

* **docs:** Se generar cambios en la documentación.

* **hotfix:** Esta tipo se utiliza cuando se quiere hacer un contrato con el diablo jaja, practicamente es cuando queremos meter cambios directamente a la rama de producción.

como podemos ver los tipos son similares a los que manejamos en los **[commits](https://medium.com/@jmz12/buenas-pr%C3%A1cticas-para-commits-5eb4c86b9a47)** la pequeña diferencia es que estos tiene que ser escritos en minúsculas.

> **🔖 Nota:** los tipos que se recomiendan en este caso pueden varias dependiendo del proyecto.

### 🗂 Name/Nombre

El nombre es la segunda parte de la estructura del `branch` y este tiene que ser subjetivo y el nombre de una rama no tiene que ser mayor a `30 caracteres`.

### **🔖 Ejemplo**

Tomando en cuentas las reglas anteriores podemos ver que nuestra rama la estructura de nuestro `branch` quedaría de la manera siguiente.

![Estructura final del branch(**Fig-02**).](https://cdn-images-1.medium.com/max/2720/1*6ij4N939mZyCOPhMG8thuA.png)*Estructura final del branch(**Fig-02**).*

### 💻 Generando ramas

Para poder generar una rama se recomienda siempre se tiene que tomar como base el `branch` en el cual se tienen que generar los cambios por ejemplo podríamos tomar como base la rama **master **y así nuestra nuevo **branch **contará con los últimos cambios, para crear el nuevo `branch` se utilizarán los comandos siguientes.

![Comandos para crear nuestra nueva rama (**Fig-03**).](https://miro.medium.com/max/2720/1*ucD2B--INktIXwkp6q8J7g.png)*Comandos para crear nuestra nueva rama (**Fig-03**).*

usando los comandos anteriores verificamos que el `branch` cuente con los últimos cambios, mientras se generan los cambios se recomienda actualizar constantemente el `branch `esto para estar al día con los cambios para esta tarea podemos utilizar el siguiente comando.

![Comando para actualizar el branch (**Fig-04**)](https://cdn-images-1.medium.com/max/2720/1*FmPqgvNa5ja0jp8q93DceQ.png)*Comando para actualizar el branch (**Fig-04**)*

Asi siempre nuestra rama contará con los últimos cambios que tenga `master` y también reducirá el riesgo de tener conflictos al momento de mandar los cambios que se realicen.

> 🔖**Nota:** Al generar una nueva rama se recomienda no mezclarla con otros desarrollos.

### 🗞Extras

Cuando generamos un nuevo repositorio es recomendable contar con ciertas ramas creadas por defecto las cuales pueden ser.

* **Develop :** Esta rama es utilizada por el equipo de desarrollo principalmente para probar todos los nuevos desarrollos o refactors grandes, prácticamente es nuestro parque de diversiones.

* **Staging :** Esta rama es utilizada para que el equipo encargado de realizar el `QA `se encargue de generar todas las pruebas pertinentes que correspondan a nuevos desarrollos y correcciones, en ocasiones los cambios que pasan a esta rama pueden provenir de la rama `develop` y esto puede pasar cuando el equipo de desarrollo terminó de realizar pruebas en el `branch`.

* **UAT :** También conocido como `User Acceptance Tests,` en este punto el **QA** realizado en **Staging** a finalizado satisfactoriamente y los cambios están listo para que los usuarios finales puedan dar su `Vo Bo` y dependiendo de su `Re-Test` validar si los cambios pasan a la rama `master`**(producción)**, o se tiene que realizar alguna corrección.

* **Master :** Haste este punto todos los cambios y correcciones se encuentran listos para ser mandados a un ambiente de producción.

> **📓 Nota**: Es muy común que las ramas de que utilizamos en el repositorio del proyecto cuenten con integración continua, la rama `develop` puede ser opcional esto depende del modo de trabajo de cada equipo.

## 😺 Conclusión

Contar con estándares y reglas dentro de nuestro equipo de trabajo al momento de manejar `branches` es algo que nos puede evitar muchos dolores de cabeza, las recomendaciones mostradas anteriormente pueden ser modificadas ya que la intención es brindar una base para poder generar nuestras propias reglas.