No se me ocurren motivos para no usar un sistema de control de versiones para código, Git es el más utilizado y aunque pareciera que es sencillo de aprender y de utilizar, hay formas correctas, formas incorrectas y formas raras de utilizarlo. En este capítulo hablaremos de algunos de los escenarios más comunes y otros nuevos.
Como senior trabajarás de forma continua con Git, es probable que tengas que ayudar a otros a resolver los problemas que enfrenten con Git, en este capítulo repasaremos algunos escenarios comunes a los cuales te enfrentaras, no pretendo enseñarte Git avanzado, sino decirte a que te puedes enfrentar y que será mejor que practiques.
Usa la terminal
Usar la terminal para controlar Git a diferencia de alguna herramienta de interfaz de usuario es algo a lo que te tienes que acostumbrar como senior, te ayudará a conocer de arriba a abajo como funciona Git y poderlo hacer de forma más limpia.
Pienso que debemos usar herramientas que nos hagan más productivos, pero en el caso de Git, me parece que la terminal es bastante user friendly, simplemente no estamos acostumbrados a usarla.
Al usar la terminal es más probable que tengas control sobre tus acciones en Git, a veces los GUI ejecutan 2 pasos en 1, y es posible que no obtengas los resultados que deseas.
Dominar la terminal te ayudará a que en las situaciones en las que no cuentes con tu GUI de confianza igual podrás trabajar de forma eficiente.
Commits con mensajes de calidad
Personalmente creo que es importante el mensaje que colocas al commit, es la historia que dejas en el repositorio, algo que describe lo que hiciste y el porqué lo hiciste.
Ejemplo de mensaje malo: “bug corregido”
Mensaje adecuado: “Se corrigió problema en botón”
Mensaje bueno: “Corregido problema en botón principal, al dar doble click enviaba el formulario dos veces”
Squash Commits
Era una práctica que yo no tenía de hecho normalmente cada que avanzaba hacia commit, lo cual me permitía poderme regresar hasta ese punto en caso de que mis siguientes esfuerzos no funcionarán, dejar commits es como colocar guías mientras escalas, así aunque te caigas, la última guía te detendrá y podrás volverlo a intentar.
En proyectos open source es muy común el que se haga squash de commits, squash significa apretar.
¿Por qué es bueno hacer squash de commits?
Es más sencillo para otras personas el entender en que consistió el trabajo, imagina si tus commits se veían como:
- Agregar textos e información de base de datos
- Alinear elementos a la izquierda
- Cambiar color por colores institucionales
- Agregar logo
- Corrección de defecto en consulta a base de datos.
En cambio es más fácil si el mensaje se lee: Agregar página de información general con colores y logo institucionales.
Es recomendable que ese squash de commits sea ya justo antes de que planees hacer el merge con la rama principal, en el inter esos pasos te pueden servir para poder hacer cambios.
Recuerda al hacer el squash, no hay una regla que indique cada cuántos commits deberías de tener que comprimir, es simplemente algo que debes de definir cuando veas que hay elementos relacionados que valga la pena integrar.
No olvides dejar buenos mensajes en el commit final.
Flujos de trabajo (workflows)
Git a pesar de ser una herramienta de control de versiones ampliamente usada, ofrece demasiada flexibilidad, la cual a veces hace que no se use forma consistente entre equipos de trabajo.
Los workflows de Git establecen una especie de receta de cocina a seguir para trabajar utilizando Git de forma consistente, son un marco de trabajo para los equipos de trabajo.
Te invito a que investigues algunos de los workflows más famosos:
- Centralized Workflow
- Feature Branch Workflow
- Gitflow Workflow
- Forking Workflow
- Trunk Based Development
Recuerda que los workflows de Git son guías, no son reglas concretas que nunca se pueden dejar de seguir. Como senior debes conocer al menos la teoría de los Git workflows y tener experiencia usando alguno.
Rebase vs Merge
Una de las funcionalidades más útiles de Git es el uso de Git rebase, el cual jala los commits más nuevos de la rama master y coloca tu código encima de ellos. Ayuda a mantener limpia la historia del repositorio.
Depende de que tanto sufre cambios master será la frecuencia con la que es recomendable que hagas el proceso de rebase, cuando tu rama esté lista para el merge igual deberás hacer un último rebase, así el historial de commits pondrá tus cambios hasta arriba.
La diferencia principal con merge, es que cuando haces merge de tu rama a master el proceso entrelazará los commits de acuerdo a su antigüedad, el proceso de solución de conflictos puede ser más molesto. Pero creo sobre todo la limpieza en el historial de tu proyecto es algo que perderás.
Revert
Dicen que no se puede aprender a andar en bicicleta sin caerse, no te puedes volver senior con un historial perfecto de logros o sin haberte caido, con PROD caido.
El comando de revert es ese comando que cuando lo ejecutas sabes que te equivocaste, permite regresar una rama a un commit en específico, normalmente el último commit en el cual se sabe que la rama era estable. Todos los commits que se encontraban después de ese commit se deshacen.
A veces el reto es saber si es mejor hacer un revert para poder dejar estable la rama principal o si es mejor corregir y agregar un nuevo commit con la corrección. Creo depende de cuanto tarde uno contra lo otro, y depende de la gravedad del problema que se encuentra en la rama principal.
Manejo de Conflictos de merge
Esto es algo frustrante, me parece va por el sentimiento que pones al desarrollar y ver que tienes que resolver cosas que parecería que no te corresponde.
Los conflictos ocurren cuando dos personas cambian las mismas líneas o archivos, por ejemplo si un programador borra un archivo mientras otro lo estaba modificando, en esos casos Git no puede determinar de forma automática qué es lo correcto. La persona que hará el merge será la encargada de resolver este conflicto, el resto del equipo de trabajo no es involucrado en el proceso. Git marcará el archivo con conflictos y pausará el merge hasta que sea resuelto el conflicto.
El proceso de resolver conflictos puede ser algo intimidante y frustrante, si no tienes mucha experiencia te recomiendo usar una interfaz gráfica, como senior debes estar acostumbrado a trabajar y no frustrarte tanto en este proceso.
Los conflictos ocurren cuando trabajas en equipo, dependiendo de la organización y tamaño del equipo será que tengas que lidiar seguido o no tan seguido con esto.
Cherry-Picking
Recoger cerezas… me encanta que en tecnología los nombres normalmente dan una expectativa de lo que hacen, en este caso el recolectar cerezas es una actividad de precisión y justo eso es lo que haremos cuando hagamos cherry pick.
git cherry-pick es un comando poderoso que permite seleccionar commits de Git por referencia y moverlos de una rama a otra.
Por ejemplo tienes varias ramas de trabajo, y una funcionalidad la realizas en la rama equivocada, puedes seleccionar ese commit y moverlo a la otra rama sin tener que deshacer tus cambios y volverlos a hacer en la otra rama.
No son muchos los escenarios en los cuales será útil el usar git cherry-pick, pero otro sería por ejemplo cuando tienen un defecto urgente de corregir en la rama principal y este ya se encuentra corregido en otra rama, podrían seleccionar ese commit y moverlo a la otra rama, para traer de forma más inmediata ese ajuste.
Pull Request
Este mecanismo con el cual notificas a tu equipo de trabajo que has completado un feature o un bug. Este proceso solicita (request) a otro miembro de tu equipo que deberá de obtener (pull) tu código para validarlo y ofrecer feedback.
Este es un proceso con el cual los seniors se sienten cómodos, no solo haciendo el code review en Github, GitLab o Bitbucket, sino descargándolo, probándolo, etc.
El proceso de pull request puede cambiar un poco dependiendo de la estrategia de Git que se utilice en tu repositorio, pero en general el proceso es el siguiente:
- Un desarrollador crea una funcionalidad en una rama dedicada la cual se encuentra en su repositorio local.
- El desarrollador empuja (push) la rama al repositorio público (Github, Gitlab, Bitbucket, etc.)
- El desarrollador crea un pull request a través del repositorio público.
- Miembros del equipo revisan el código, lo discuten, lo alteran.
- Alguien hace el merge hacia el repositorio principal y cierra el pull request.
Los pull request son el pan nuestro de cada día, yo diría que pueden generar el mismo nivel de frustración o superior que los conflictos.
Revisar código es difícil
Cuando entrevisto personas les pregunto cómo ha sido su proceso de revisión de código o que elementos buscan al hacerlo, normalmente esta pregunta me lleva a algunos escenarios comunes:
- LGTM, Looks Good To Me, no te voy a dar feedback dale merge, todo bien.
- Mientras no fallen las pruebas y el análisis de código, todo bien, los humanos no tenemos que hacer nada..
- Cambia todo tu código, nada que ver. Todo está mal… no sabes nada , y yo mando.
Seguro hay más, pero el proceso de revisión de código pone en confrontación al menos a dos personas y su propiedad intelectual, y esto genera que haya muchos momentos en los que podría haber problemas.
El proceso de revisión de código no deber ser el momento para hacer cambios por completo a la solución, previamente debió de haber existido alguna sesión de diseño o discusión en donde se acordó la forma de implementación.
¿Por qué es difícil?
Imagina que un programador te envía una lista de cambios que hará en el código, ese programador considera que estos cambios están muy bien hechos.
No es fácil para alguien que escribe código recibir críticas sobre su trabajo, podría parecer que es una persona incompetente.
La persona da la crítica tiene el reto de que en el proceso de escritura se pueda malinterpretar el mensaje, no se pueda notar si hay algún tono de voz o lenguaje corporal que explique la intención del mensaje.
Sigo trabajando en mis productos con el fin de ayudar de forma más estructurada a la comunidad de TI, si te interesan pásale a mi perfil de Gumroad
- 📕 Líder Técnico
- 📘 De Junior a Senior
- 🗓 Mentorías
- 📑 Revisión de C.V.
Te invito a que me sigas en Twitter para que te enteres de todo el contenido que hago normalmente 🙃.
También soy creador del podcast Chile, Mole & Tech(https://dev.to/chilemoleytech), el cual esta en todas las plataformas(https://linktr.ee/chilemoleytech).
Top comments (0)