Git makes software development, well, easier

Three tips to make Git fit into your agile workflow (and vice versa)

Laura Daly Laura Daly

Git is the de facto standard for agile software development when it comes to version control systems. This well-supported open source project is flexible enough to support a range of workflows that suit the needs of any given software team. Its distributed -- rather than centralized – nature gives it superior performance characteristics and allows developers the freedom to experiment locally and publish their changes only when they're ready for distribution to the team.

Además de los beneficios de la flexibilidad y la distribución, hay funciones clave de Git que respaldan y mejoran el desarrollo ágil. Piensa en Git como un componente del desarrollo ágil; echar atrás cambios en el canal de despliegue puede ser más rápido que trabajar con versiones monolíticas y sistemas de control de versiones centralizados. Git trabaja del mismo modo que lo hace el equipo ágil (y debe esforzarse en que así sea). 

Pro Tip:

Git is Distributed Version Control System (DVCS). Unlike CVS or Subversion (SVN) repositories, Git allows developers to create their own, personal copy of the team's repository, hosted alongside the main codebase. These copies are called forks and when work is complete on a fork, it's easy to bring changes back to the main codebase.

Ramificación de Git | Orientador ágil de Atlassian

Tip 1: Start thinking about tasks as Git branches

Git comes into play after features have been fleshed out, added to a product roadmap, and the development team is ready. But to take a step back here is a quick crash course in agile feature development: product, design, quality assurance (QA), and engineering hold a feature kick-off meeting to come up with a shared understanding of what a feature will be (think requirements), scope of the project, and what tasks that the feature needs to be broken down into to complete it. These tasks – are also known as user stories – are then assigned to individual developers.

Git starts fitting into your agile workflow at this point. At Atlassian, we create a new branch for every single issue. Whether it's a new feature, a bug fix, or a small improvement to some existing code, every code change gets its own branch.

La ramificación es sencilla y permite a los equipos colaborar fácilmente dentro de una base de código central. Cuando un desarrollador crea una rama, cuenta con su propia versión aislada de forma eficaz del código base en la que aplicar los cambios. Para un equipo ágil esto significa que al dividir las funcionalidades 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 de repositorios distintos al principal, no existen tantas dependencias que ralenticen el proceso de desarrollo.  

Pro Tip:

Existen otros tipos de ramificaciones de Git además de las ramificaciones de tareas, y no son mutuamente excluyentes. Puedes crear ramas para una versión, por ejemplo. Esto permite a los desarrolladores estabilizar y endurecer el trabajo programado para una versión concreta, sin retrasar a otros desarrolladores que están trabajando en futuras versiones.

 

Una vez que has creado una rama de versiones, necesitarás hacer merges con ella de forma habitual en tu rama principal ("master") para garantizar que el trabajo con funcionalidades también lo haga en versiones futuras. Para minimizar la sobrecarga, lo mejor es crear la rama de versiones lo más cerca posible de la fecha de publicación programada. 

Vista de detalles de rama de Git | Orientador ágil de Atlassian

Consejo 2: Muchas ramas se pueden probar individualmente, así que aprovéchalo

Una vez las ramas se consideran hechas y listas para las revisiones del código, Git desempeña otro papel clave en el workflow del desarrollo ágil: realización de pruebas. Los exitosos equipos ágiles practican revisiones de código y configuran pruebas automatizadas (integración continua o desarrollo continuo). 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 pull request. En pocas palabras, una pull request es una forma de solicitar a otro desarrollador que haga un merge 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 crear y probar tus solicitudes "pull request" antes de hacer un merge con ellas. Así, tendrás la seguridad de que no surgirán problemas tras el merge. 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 master, ya que las ramas han variado. 

Pro Tip:

A long running feature branch that is not merged to the master branch may hurt your ability to be agile and iterate. If you have a long running feature branch remember that you effectively have two divergent versions of your code base, which will result is more bug fixes and conflicts. But the best solution is to have short-lived feature branches. This can be achieved through decomposing user stories into smaller tasks, careful sprint planning, and merging code early to ship as dark features. 

Consejo 3: Git proporciona transparencia y calidad en el desarrollo ágil

The Git/agile story is one about efficiency, testing, automation, and overall agility. Once you’ve merged a branch to the master branch, your agile workflow is done. Likewise, merging code through pull requests means that when code is done, you have the documentation to confidently know that your work is green, that other team members have signed off on the code, and that it is ready to release. This keeps agile teams moving at a speed and with confidence to release often: a sign of a great agile team.

Pro Tip:

Adoptar una cadencia de publicación regular es fundamental para el desarrollo ágil. Para lograr que Git funcione con tu workflow ágil, debes asegurarte de que tu rama principal siempre está verde. Esto significa que si una funcionalidad no está lista, es mejor esperar a la siguiente publicación. Si pones en práctica ciclos de publicación más cortos, esto no debería suponerte, ni te supondrá, ningún problema.

Up Next
Ramas