Tabla de Contenidos
Diariamente en plataformas como Github, BitBucket o GitLab se generan infinidad de Pull Request, pero ¿Cuáles son las buenas prácticas que debemos seguir al crearlos? ¡Aquí te cuento!
A medida que vamos utilizando un sistema de gestión de versiones, por ejemplo Github, surgen varios problemas que debemos resolver para trabajar de una forma más óptima con nuestro team o equipo de trabajo.
Si no sabes que es un Sistema de Control de Versiones o ¿por qué deberías de utilizar un Sistema de Control de Versiones? Aquí te cuento todos los detalles
Cuando creamos repositorio, este debe de almacenar nuestro código e irse actualizando a medida que realizamos actualizaciones, sin embargo, no es el único uso que le damos a nuestros repositorios, puesto que desde hacer varios años ya, se ha convertido en un entorno completo de CI/CD.
En este punto, empiezan a surgir algunas dudas que debemos de estandarizar por el bien del código y las buenas prácticas. Algunas dudas que nos pueden surgir son:
¿Los cambios los subo directo a main/master?, ¿Debo generar ramas?, ¿Cómo crear ramas?, ¿Qué es un Pull Request?, ¿Cuál es el proceso para generar Pull Request?, ¿Cómo nombrar ramas?, ¿Cómo crear commits?, ¿Qué tamaño debe de tener un commit?
En este artículo intentaré responder a cada una de estas dudas para tener un mejor contexto de como trabaja un Ingeniero de Software diariamente. Así que empecemos, por el inicio:
¿Qué es un Pull Request?
En palabras breves, un Pull Request en Github es solicitar a los compañeros de equipo que revisen tus cambios respecto a la actualización que estás realizando, esta revisión que tus compañeros realizarán se denomina Code Review, que abundaremos en otro artículo.
Cada Pull Request que hagamos deberá de estar en una rama independiente a la rama main o master, ya que la rama main o master está asociada siempre a cuestiones de integración y comúnmente se sincroniza con producción.
Es por ello que aquí viene la primera recomendación: Nunca debemos de hacer commits directamente a main, en su lugar, creamos una rama y si el equipo lo decide, podemos seguir alguna estrategia de ramas.
Las estrategias de ramas comúnmente se dividen en 2 grandes categorías: Mainline Based y Branch Base, no es el objetivo de este artículo mostrarte las diferencias entre una y otra, sino platicarte que existen y algunas características que utilizo diariamente.
¿Cómo crear ramas en git?
Para crear una rama basta con añadir desde consola el siguiente comando:
git checkout -b nombre-de-la-ramaGit checkout con el flag -b es el comando encargado de crear ramas, a esto se adiciona el nombre de la rama y es aquí donde nos surge un conflicto, ya que si trabajamos en equipo, cada persona deberá crear sus propias ramas y probablemente deberíamos seguir una convención, aquí te dejo unas recomendaciones:
Segunda recomendación: Puedes seguir la estructura: nombre-de-usuario/nombre-de-la-rama donde el nombre de usuario, es tu usuario de github o la plataforma que utilices y el nombre de la rama, comúnmente será una pequeña descripción en inglés de lo que harás en la rama, ejemplo:
git checkout -b 8devmx/add-readme-fileEs importante mencionar que con base a las estrategias de ramas, algunos autores sugieren añadir en lugar el nombre de usuario, el tipo de acción a realizar, por ejemplo: feature, fix, hotfix, etc… de nueva cuenta, son recomendaciones y yo te recomiendo el username para tener un mejor control de las actividades que cada integrante del equipo realiza.
Después de haber creado la rama, seguramente realizaremos una serie de actualizaciones a nuestro código, lo que terminará con un entregable que es el commit, aquí surge otra interrogante
¿Cómo hacer un commit en git?
Para poder crear un commit utilizaremos el commando git commit
git commit -m "feat(users): enable user profile"El flag -m agregado al comando git commit nos permitirá agregar un commit a la rama que estamos trabajando y de nueva cuenta aquí vuelve a existir otro conflicto, ya que si no tenemos estructuras, estándares o referencias para poder generarlos, seguramente se volverán un caos.
Ten en consideración lo siguiente: Probablemente el commit que generas hoy, lo tendrás que volver a revisar en algún tiempo: días, semanas, meses o años y si no damos la descripción adecuada, probablemente se vuelva un lío.
Para que esto no suceda, en la comunidad hay distintas sugerencias, sin embargo, una de las más utilizadas, se denomina conventional commits, te dejo la referencia en español.
En términos resumidos, conventional commits sugiere lo siguiente:
Tercera recomendación: El mensaje del commit deberá seguir una estructura, la cual es:
<tipo>[ámbito opcional]: <descripción>
[cuerpo opcional]
[nota(s) al pie opcional(es)]Por lo que las recomendaciones son:
Cuarta recomendación: El commit siempre deberá iniciar con un tipo, algunos de los tipos disponibles que comúnmente se pueden agregar son:
- feat: Agregar nueva funcionalidad.
- fix: Al arregla un error.
- chore: Tareas que no sean una nueva funcionalidad como: crear un gitignore, actualizar el readme file, agregar nueva librería o dependencia
- test: Agregar o modificar tests.
- docs: Agregar o modificar documentación.
- refactor: Refactorizar el código.
- perf: Mejorando el rendimiento o performance
Lo siguiente es que el ámbito puede ser opcional, como lo menciona la estructura, por ejemplo: podemos poner api, que significa que el ámbito es la api, o user, que significaría el módulo de usuarios, etc.
La quinta recomendación es: Se deberá agregar la descripción de commit, empezando siempre por un verbo en imperativo, por ejemplo: añade, crea, remueve, cambia, soluciona y la descripción que generemos, La sexta recomendación es: NO se usan puntos finales al término de la descripción y La séptima recomendación es: La descripción deberá tener como máximo hasta 50 caracteres.
Si necesitas añadir más contexto lo puedes hacer con otro flag -m después la descripción, esto te permitirá generar un cuerpo de mensaje en el cual podrás extender tu explicación.
También opcionalmente puedes agregar una nota de pie en donde comúnmente se específica si hay cambios que rompen la compatibilidad de la versión actual.
Una vez que se ha generado un buen naming de ramas y un buen commit, ya podremos hacer push a nuestro origin y para finalizar, poder crear nuestro Pull Request.
Como puedes observar, es un proceso que vale la pena tomar en consideración y seguir las recomendaciones pertinentes ya que muchas veces estamos tentados a escribir o hacer las cosas lo más rápido posible, pero sin duda debemos pensar a futuro.
Por último y para poder terminar con esto, ahora quiero darte unos consejos acerca de como crear tu Pull Request:
Como te comentaba hace un momento, esta será una revisión que tus compañeros le harán a tu código y en algunos casos se abrirá un debate de como lo habría hecho alguien más o una solución alterna, es por ello que La octava recomendación es: Los Pull Request deben ser pequeños con el objetivo de tomarle la seriedad necesaria al Code Review,
Pregúntate: ¿Quisieras leer 500 líneas de código de alguien más? Si la respues es NO, haz tus Pull Request pequeños
Escribe una buena descripción, Al igual que con tus commits, utiliza una buena descripción del PR, en dado caso puedes guiarte de tus commits para describir mejor de que se trata el Pull Request
Puedes crear plantillas para Pull Request, esto lo explicaré en otro artículo.
La novena recomendación es: Puedes poner capturas de pantalla del nuevo Feature que se agregó o como quedó la nueva interfaz, cosa que creéme, tus compañeros y tu mismo agradecerán ya que proporciona un mejor contexto a todo lo que revisemos. Ya si quieres verte muuuy pro, un video un GIF no caería nada mal.
En resumen
Los Pull Request están presentes diariamente en las actividades como Ingenierio de Software, recuerda, si no estás haciendo Pull Request diariamente, probablemente tus commits en general sean muy largos.
Tómate en serio esta actividad, seguramente lo agradecerás en un futuro.
Sigue estándares y buenas prácticas que la comunidad desarrolla constantemente.
Puedes apoyarte de herramientas como linters, plugins, extensiones y otras cosas que ayudan en el proceso.
Si te ha gustado este artículo te pido me sigas en mi:
🖥️ Youtube: https://www.youtube.com/@eightdev?sub_confirmation=1
🎵 Tik Tok: https://www.tiktok.com/@8devmx
✅ Facebook: https://www.facebook.com/8devmx/
📸 Instagram: https://www.instagram.com/8devmx/
Sin más, ¡nos vemos la próxima!
