Existen varias estrategias populares de ramificación que puedes adoptar, siendo dos de las más populares git-flow (también conocido como ramas de características de larga duración) y el trunk-based development (desarrollado basado en rama principal).
Además de la estrategia de ramificación, tenemos que tener en cuenta que se puede combinar con una estrategia de fusión, como la que comentamos en el artículo ship/show/ask. Ambas estrategias pueden ser más laxas o no, según el tamaño del proyecto y la experiencia de los desarrolladores.
Otros artículos git
Git Flow
En el modelo de desarrollo Git flow, tienes una rama de desarrollo principal con acceso estricto a ella. A menudo se le llama «develop».
Los desarrolladores crean ramas de características a partir de esta rama principal y trabajan en ellas. Una vez que terminan, crean PRs (Pull Request). En las PRs, otros desarrolladores comentan los cambios y pueden tener discusiones, a menudo bastante largas.
Se necesita cierto tiempo para ponerse de acuerdo sobre una versión final de los cambios. Una vez acordado, se acepta la PR y se fusiona en la rama principal. Una vez que se decide que la rama principal ha alcanzado suficiente madurez para ser lanzada, se crea una rama separada para preparar la versión final. La aplicación de esta rama se prueba y se aplican correcciones de errores hasta el momento en que esté lista para ser publicada a los usuarios finales. Una vez hecho esto, fusionamos el producto final en la rama principal y lo etiquetamos con la versión de lanzamiento. Mientras tanto, se pueden desarrollar nuevas características en la rama de desarrollo.
Las PRs se centran en la revisión de código solo en el código nuevo. En lugar de considerar el código en su conjunto y trabajar para mejorarlo como tal, solo revisan los cambios recién introducidos. En algunos casos, podrían llevar a una optimización prematura, ya que siempre es posible implementar algo para que funcione más rápido.
Además, las PRs podrían llevar a una extensa microgestión, donde el desarrollador principal administra literalmente cada línea de código. Si tienes desarrolladores experimentados en los que puedes confiar, pueden manejarlo, pero podrías estar desperdiciando su tiempo y habilidades. También podría desmotivar gravemente a los desarrolladores.
En organizaciones grandes es una preocupación la política de oficina durante las PRs, ya que puede que alguna persona que se encargue de aprobar las PRs pueda utilizar su posición para bloquear deliberadamente a ciertos desarrolladores para que no realicen cambios en el código base. Podrían hacerlo debido a una falta de confianza, mientras que otros podrían abusar de su posición para resolver conflictos personales.
Ventajas de Git Flow
- Cuando gestionas un proyecto de código abierto. Este estilo proviene del mundo de código abierto y funciona mejor allí. Dado que todos pueden contribuir, deseas tener un control muy estricto sobre todos los cambios. Quieres poder revisar cada línea de código, porque francamente no puedes confiar en las personas que contribuyen. Por lo general, estos no son proyectos comerciales, por lo que la velocidad de desarrollo no es una preocupación.
- Cuando tienes muchos desarrolladores junior. Si trabajas principalmente con desarrolladores junior, entonces querrás tener una manera de supervisar de cerca su trabajo. Puedes darles múltiples consejos sobre cómo hacer las cosas de manera más eficiente y ayudarles a mejorar sus habilidades más rápido. Las personas que aceptan las solicitudes de extracción tienen un control estricto sobre los cambios recurrentes, por lo que pueden prevenir la disminución de la calidad del código.
- Cuando tienes un producto establecido. Este estilo también parece funcionar bien cuando ya tienes un producto exitoso. En esos casos, el enfoque suele estar en el rendimiento de la aplicación y las capacidades de carga. Ese tipo de optimización requiere cambios muy precisos. Por lo general, el tiempo no es una limitación, por lo que este estilo funciona bien aquí. Además, las grandes empresas son ideales para este estilo. Necesitan controlar cada cambio de cerca, ya que no quieren dañar su inversión multimillonaria.
Desventajas de Git Flow
- Cuando estás comenzando. Si estás comenzando, Git flow no es para ti. Es probable que desees crear un producto mínimo viable rápidamente. Las solicitudes de extracción crean un cuello de botella enorme que ralentiza dramáticamente a todo el equipo. Simplemente no puedes permitírtelo. El problema con Git flow es el hecho de que las solicitudes de extracción pueden llevar mucho tiempo. No es posible proporcionar un desarrollo rápido de esa manera.
- Cuando necesitas iterar rápidamente. Una vez que hayas llegado a la primera versión de tu producto, es probable que necesites pivotar varias veces para satisfacer las necesidades de tus clientes. Nuevamente, las múltiples ramas y las solicitudes de extracción reducen drásticamente la velocidad de desarrollo y no se aconsejan en tales casos.
- Cuando trabajas principalmente con desarrolladores senior. Si tu equipo consiste principalmente en desarrolladores senior que han trabajado juntos durante un período de tiempo más largo, realmente no necesitas la microgestión de las solicitudes de extracción mencionada anteriormente. Confías en tus desarrolladores y sabes que son profesionales. Permíteles hacer su trabajo y no los ralentices con toda la burocracia de Git flow.
Desarrollo Basado en Trunk
En el modelo de desarrollo basado en trunk, todos los desarrolladores trabajan en una sola rama con acceso abierto a ella. A menudo, es simplemente la rama principal. Cometen código en ella y lo ejecutan. Es muy simple.
En algunos casos, crean ramas de características de corta duración. Una vez que el código en su rama se compila y pasa todas las pruebas, lo fusionan directamente en la rama principal. Esto asegura que el desarrollo sea verdaderamente continuo y evita que los desarrolladores creen conflictos de fusión difíciles de resolver.
La única forma de revisar el código en este enfoque es hacer una revisión completa del código fuente. Por lo general, las discusiones largas están limitadas. Nadie tiene un control estricto sobre lo que se está modificando en el código fuente, por lo que es importante tener un estilo de código aplicable en su lugar. Los desarrolladores que trabajan en este estilo deben tener experiencia para que sepas que no reducirán la calidad del código fuente.
Este estilo de trabajo puede ser excelente cuando trabajas con un equipo de desarrolladores de software experimentados. Les permite introducir nuevas mejoras rápidamente y sin burocracia innecesaria. También les muestra que confías en ellos, ya que pueden introducir código directamente en la rama principal. Los desarrolladores en este flujo de trabajo son muy autónomos: entregan directamente y se les revisa los resultados finales en el producto en funcionamiento. Definitivamente hay mucha menos microgestión y posibilidad de política de oficina en este método.
Si, por otro lado, no tienes un equipo experimentado o no confías en ellos por alguna razón, no deberías seguir este método; en su lugar, deberías elegir Git flow. Te ahorrará preocupaciones innecesarias.
En las ventajas y desventajas vamos a ver lo contrario que con Git Flow.
Ventajas del Trunk-based Development
- Cuando estás comenzando. Si estás trabajando en tu producto mínimo viable, entonces este estilo es perfecto para ti. Ofrece una velocidad de desarrollo máxima con una formalidad mínima. Dado que no hay solicitudes de extracción, los desarrolladores pueden entregar nueva funcionalidad a la velocidad de la luz. Solo asegúrate de contratar programadores experimentados.
- Cuando necesitas iterar rápidamente. Una vez que hayas llegado a la primera versión de tu producto y hayas notado que tus clientes quieren algo diferente, entonces no lo pienses dos veces y utiliza este estilo para pivotar en una nueva dirección. Aún estás en la fase de exploración y necesitas poder cambiar tu producto lo más rápido posible.
- Cuando trabajas principalmente con desarrolladores senior. Si tu equipo consiste principalmente en desarrolladores senior, deberías confiar en ellos y dejar que hagan su trabajo. Este flujo de trabajo les brinda la autonomía que necesitan y les permite ejercer su maestría en su profesión. Solo dales un propósito (tareas que realizar) y observa cómo crece tu producto.
Desventajas del Trunk-based Development
- Cuando gestionas un proyecto de código abierto. Si estás administrando un proyecto de código abierto, Git flow es la mejor opción. Necesitas un control muy estricto sobre los cambios y no puedes confiar en los contribuyentes. Después de todo, cualquiera puede contribuir. Incluidos los trols en línea.
- Cuando tienes muchos desarrolladores junior. Si contratas principalmente desarrolladores junior, es mejor controlar estrictamente lo que están haciendo. Las solicitudes de extracción estrictas les ayudarán a mejorar sus habilidades y encontrar posibles errores más rápidamente.
- Cuando tienes un producto establecido o gestionas equipos grandes. Si ya tienes un producto próspero o gestionas equipos grandes en una gran empresa, Git flow podría ser una mejor idea. Quieres tener un control estricto sobre lo que está sucediendo con un producto bien establecido que vale millones de dólares. Probablemente, el rendimiento de la aplicación y las capacidades de carga sean las cosas más importantes. Ese tipo de optimización requiere cambios muy precisos.
En resumen, al elegir una estrategia de rama tienes estas dos opciones para empezar, git-flow y trunk-based development, pero podrás ser más o menos ortodoxo en su aplicación y puedes mezclarlas con otras estrategías según tu infraestructura o sistema agile o organización del equipo…
