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, 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*).

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 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).

💻 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).

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

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 QAse 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.