Cómo gestionar bien el control de versiones con Git

1. Establecer una sola estrategia de ramas

   • Cuando miembros del equipo con conocimientos en distintas especialidades trabajan juntos, pueden surgir conflictos en la forma de abordar el flujo de trabajo
   • Para evitarlo, el líder debe definir una sola estrategia de ramas y comunicarla a todos
   • La decisión sobre el flujo de trabajo de ramas puede variar según varios factores, como el tamaño del equipo, el nivel de experiencia, las necesidades de escalabilidad y las limitaciones del trabajo
   • El equipo de desarrollo puede seguir un flujo de trabajo ya definido, pero también puede crear uno adaptado a las necesidades del equipo
   • Lo que puede incluir el flujo de trabajo
     • Flujo de trabajo centralizado: existe un solo repositorio y una sola rama maestra. Hay riesgo de sobrescribir cambios
     • Rama de funcionalidad: cada vez que se agrega una nueva funcionalidad, se crea una nueva rama. Los commits relacionados con esa función se hacen en esa rama feature
     • Git Flow: una forma extrema del uso de ramas de funcionalidad. En el desarrollo con Git Flow existen una rama maestra y una rama de desarrollo separada. Soporta ramas de funcionalidad, de release y de hotfix. El desarrollo se realiza en la rama de desarrollo, luego pasa a una rama de release y se hace merge en la rama maestra
     • Desarrollo task-branch: GitLab Flow es un ejemplo de este tipo de desarrollo. Es una forma de desarrollo centrado en funcionalidades que combina las ramas feature con el seguimiento de issues. GitLab Flow mantiene varios entornos, como staging, pruebas de producción y producción, usando ramas dedicadas separadas. Esto permite que los cambios commiteados se prueben en todos los entornos
   • Efecto en la colaboración:
     • Cuando todos trabajan en armonía bajo el mismo flujo de trabajo, se reducen los casos de sobrescribir código o dañar la rama maestra
     • Todos los participantes se familiarizan con el proceso de desarrollo y despliegue, lo que facilita que los miembros del equipo contribuyan al trabajo de los demás
     • Una estrategia de ramas clara y concisa conduce a un ciclo positivo de hacer merge de nuevo código y hacer avanzar el proyecto
     • Este entorno ayuda a los miembros del equipo a organizar reuniones y gestionar plazos y carga de trabajo
     • Cómo afecta cada flujo de trabajo a la colaboración
       • Flujo de trabajo centralizado: es efectivo para equipos pequeños (menos de 5 desarrolladores) que pueden comunicarse bien para evitar que dos desarrolladores trabajen al mismo tiempo de forma duplicada sobre el mismo código
       • Rama de funcionalidad y GitFlow: conectan a equipos más diversos porque requieren más revisiones de código, reglas de push, aprobadores de código y pruebas más amplias
       • Desarrollo task-branch: permite que los miembros del equipo dividan los requisitos en pequeños bloques de funcionalidad que se transfieren a ramas de tarea. Este flujo de trabajo incluye prácticas colaborativas como fragmentos de código, revisión de código y pruebas unitarias. Si una prueba falla, los miembros del equipo colaboran para identificar qué salió mal

2. Hacer commits frecuentes en unidades pequeñas

   • Si se prioriza demasiado el nivel de completitud, es posible que solo se hagan commits grandes cuando el proyecto esté casi terminado
   • Si se omiten validaciones simples de funcionalidad y pequeños pasos intermedios, se puede terminar desarrollando una función incorrecta o perdiendo tiempo en una dirección equivocada
   • Haz un commit cada vez que tengas pruebas funcionales y código que funcione
   • Hay que simplificar el proyecto en pasos pequeños y encontrar la forma de lograr un objetivo grande mediante commits frecuentes
   • Efecto en la colaboración:
     • Cuando se establece una cultura de commits frecuentes, todos tienen visibilidad del repositorio de código y pueden entender fácilmente en qué están trabajando los demás
     • Si se comparte el trabajo mediante una rama de funcionalidad o un merge request, se puede evitar el trabajo duplicado de otros miembros del equipo
     • Aunque todavía no esté listo para revisión, conviene hacer push frecuentemente a la rama de funcionalidad
     • Compartir el trabajo antes de que esté terminado activa la discusión y el feedback, lo que permite mejorar la calidad incluso antes de la revisión de código
     • Dividir el trabajo en varios commits puede servir como información útil para futuras revisiones de código por parte de desarrolladores y otros equipos
     • Se puede identificar con claridad, commit por commit, cómo fue desarrollada una funcionalidad
     • También permite dejar intacto el historial de cambios no relacionados, volver a un momento específico y revertir selectivamente solo ciertos cambios de código

3. Escribir mensajes de commit detallados

   • Un mensaje de commit debe reflejar no solo el contenido del commit, sino también la intención del desarrollador
   • El mensaje de commit debe explicar por qué ocurrió el cambio
   • Ejemplo de un buen mensaje de commit: “Se combinan plantillas para reducir el código duplicado en la interfaz de usuario”
   • Palabras como “cambio”, “mejora”, “corrección” o “reestructuración” dentro de un mensaje de commit no aportan información útil por sí solas
   • Efecto en la colaboración:
     • Los mensajes de commit detallados aumentan la transparencia y dan visibilidad del progreso, ayudando a miembros del equipo, clientes y futuros contribuidores a entender el proceso de desarrollo
     • Al realizar revisiones de código, los mensajes de commit ayudan a seguir procedimientos repetidos y a verificar cambios surgidos después de un release, una discusión o un cambio de requisitos
     • Los mensajes detallados también ayudan a QA y al equipo de seguridad a identificar áreas problemáticas al inspeccionar el código y a revertir cambios específicos
     • Escribir mensajes de commit detallados evita trabajo duplicado entre otros miembros del equipo y minimiza retrasos, ayudando a mantener un avance estable del proyecto

4. Desarrollar usando ramas

   • Desarrollar en una rama equivale a trabajar sobre una copia del estado actual tomada desde una rama específica
   • Usar ramas permite modificar el código sin afectar la base de código principal
   • El historial de cambios se gestiona dentro de la rama
   • Cuando el código está listo, puede hacerse merge a la rama maestra
   • Programar en ramas permite abordar el desarrollo de forma más estructurada
   • Se puede separar y gestionar por aparte un borrador en desarrollo del código maestro estable que ya pasó pruebas confiables
   • Efecto en la colaboración:
     • Permite que los integrantes prueben soluciones innovadoras y experimentos para resolver problemas complejos
     • El equipo de desarrollo puede asumir retos creativos sin la ansiedad de afectar la rama maestra
     • Antes de hacer merge a la rama maestra, el equipo puede colaborar para verificar que la solución funcione correctamente
     • Los equipos de operaciones, QA y seguridad pueden revisar el código antes del despliegue, garantizando que todos tengan oportunidad de aportar ideas y discutir posibles problemas antes del release

5. Realizar revisiones de código periódicas

   • Garantiza la mejora continua y evita código inestable
   • Cuando haya código para revisar, se debe solicitar revisión a colegas, miembros del equipo o expertos del área que conozcan bien el proyecto
   • Aspectos a tener en cuenta al hacer una revisión de código:
     • Explicar qué cambios son necesarios
     • Proponer alternativas, pero asumiendo que el desarrollador ya las consideró
     • Incluso en el proceso de resolver problemas, hay que buscar formas de simplificar el código
   • Efecto en la colaboración:
     • La revisión de código aporta otras opiniones sobre la resolución de problemas y la implementación
     • Aporta otra mirada para detectar bugs, problemas de lógica o posibles corner cases
     • Ayuda a mitigar problemas que pueden aparecer al atravesar issues difíciles mientras se avanza hacia el release
     • Permite revisar soluciones, dar opiniones y colaborar entre miembros del equipo durante la revisión
     • Se pueden aprender distintos estilos de programación, buenas prácticas de flujo de trabajo y nuevas formas de resolver problemas