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 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)
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 ramadevelop
y esto puede pasar cuando el equipo de desarrollo terminó de realizar pruebas en elbranch
.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 suVo Bo
y dependiendo de suRe-Test
validar si los cambios pasan a la ramamaster
(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.
Top comments (0)