Git entra en juego después de que se hayan concretado las funciones, se hayan añadido a una hoja de ruta de producto y el equipo de desarrollo esté listo. Llegados a este punto, nos desviamos un poco para dar un curso acelerado de desarrollo de funciones ágiles: los equipos de producto, diseño, control de calidad (QA) e ingeniería celebran una reunión de lanzamiento de funciones para llegar a un entendimiento compartido de lo que será una función (es decir, en los requisitos que tendrá), el alcance del proyecto y en qué tareas se tiene que desglosar la función para completarla. Estas tareas, que también se conocen como historias de usuario, se asignan entonces a los desarrolladores individuales.

Git empieza a encajar en tu flujo de trabajo de metodología ágil en este punto. En Atlassian, creamos una rama nueva para cada una de las incidencias. Tanto si se trata de una nueva función o de una corrección de error como si es una pequeña mejora a un código ya existente, todos los cambios de código tienen su propia rama.

La creación de ramas es sencilla y permite a los equipos colaborar fácilmente dentro de una base de código central. Cuando un desarrollador crea una rama, a todos los efectos cuenta con su propia versión aislada de la base de código en la que aplicar los cambios. Para un equipo de metodología ágil, esto significa que al dividir las funciones en historias de usuario y, después, en ramas, el equipo de desarrollo tiene la capacidad de asumir tareas de forma individualizada y trabajar de manera más eficiente en el mismo código, pero en repositorios distintos. Se acabaron las tareas duplicadas y, dado que los individuos son capaces de centrarse en pequeños trabajos en repositorios distintos al principal, no existen tantas dependencias que ralenticen el proceso de desarrollo.

Una vez que las ramas se consideran terminadas y listas para las revisiones del código, Git desempeña otro papel clave en el flujo de trabajo del desarrollo ágil: la realización de pruebas. Los equipos ágiles y de DevOps con mejores resultados practican revisiones de código y configuran pruebas automatizadas (integración continua o entrega continua). Para ayudar con las revisiones de código y las pruebas, los desarrolladores pueden informar fácilmente al resto de su equipo de que el trabajo de la rama está listo para su revisión y de que esta debe hacerse a través de una solicitud de incorporación de cambios. En pocas palabras, una solicitud de incorporación de cambios es una forma de solicitar a otro desarrollador que haga una fusión de una de las ramas en la rama principal y de informarle de que está lista para las pruebas.

Con las herramientas adecuadas, tu servidor de integración continua puede compilar y probar tus solicitudes de incorporación de cambios antes de que las fusiones. Así, tendrás la seguridad de que no surgirán problemas tras la fusión. Esta seguridad facilita la reorientación de las correcciones de errores y de los conflictos en general, dado que Git conoce la diferencia entre la rama y la base de código principal, ya que las ramas han variado.

La historia de Git y de la metodología ágil se basa en la eficacia, las pruebas, la automatización y la agilidad general. Una vez que hayas fusionado una rama con la rama principal, tu flujo de trabajo de metodología ágil está terminado. Del mismo modo, fusionar código mediante las solicitudes de incorporación de cambios significa que cuando el código está terminado, tienes la documentación para saber con confianza que tu trabajo tiene luz verde, que otros miembros del equipo han aprobado el código y que está listo para su publicación. Esto permite que los equipos ágiles se muevan rápidamente y con confianza para publicar a menudo, lo cual es una característica de los grandes equipos ágiles.