Desarrollo basado en troncos frente a Git Flow

Para desarrollar software de calidad, necesitamos poder rastrear todos los cambios y revertirlos si es necesario. Los sistemas de control de versiones cumplen esa función al rastrear el historial del proyecto y ayudar a fusionar los cambios realizados por varias personas. Agilizan enormemente el trabajo y nos dan la posibilidad de encontrar errores más fácilmente.

Además, trabajar en equipos distribuidos es posible principalmente gracias a estas herramientas. Permiten que varias personas trabajen en diferentes partes de un proyecto al mismo tiempo y luego unan sus resultados en un solo producto. Echemos un vistazo más de cerca a los sistemas de control de versiones y expliquemos cómo surgió el desarrollo basado en troncales y el flujo de Git.

Cómo los sistemas de control de versiones cambiaron el mundo

Antes de que se crearan los sistemas de control de versiones, las personas confiaban en realizar copias de seguridad manuales de versiones anteriores de proyectos. Estaban copiando archivos modificados a mano para incorporar el trabajo de múltiples desarrolladores en el mismo proyecto.

Costó mucho tiempo, espacio en el disco duro y dinero.

Cuando miramos la historia, podemos distinguir ampliamente tres generaciones de software de control de versiones.

Echemos un vistazo a ellos:

Notamos que a medida que maduran los sistemas de control de versiones, existe una tendencia a aumentar la capacidad de trabajar en proyectos en paralelo.

Uno de los cambios más innovadores fue pasar de bloquear archivos a fusionar cambios. Permitió a los programadores trabajar de manera más eficiente.

Otra mejora considerable fue la introducción de sistemas distribuidos. Git fue una de las primeras herramientas en incorporar esta filosofía. Literalmente permitió que floreciera el mundo del código abierto. Git permite a los desarrolladores copiar todo el repositorio, en una operación llamada bifurcación, e introducir los cambios deseados sin tener que preocuparse por los conflictos de combinación.

Más tarde, pueden iniciar una solicitud de incorporación de cambios para fusionar sus cambios en el proyecto original. Si el desarrollador inicial no está interesado en incorporar esos cambios de otros repositorios, puede convertirlos en proyectos separados por su cuenta. Todo es posible gracias al hecho de que no existe el concepto de almacenamiento central.

Estilos de desarrollo

Hoy en día, el sistema de control de versiones más popular es definitivamente Git, con una participación de mercado de alrededor del 70 por ciento en 2016.

Git se popularizó con el surgimiento de Linux y la escena de código abierto en general. GitHub, actualmente el almacenamiento en línea más popular para proyectos públicos, también contribuyó considerablemente a su prevalencia. Le debemos la introducción de solicitudes de extracción fáciles de administrar a Git.

En pocas palabras, las solicitudes de extracción son solicitudes creadas por un desarrollador de software para combinar los cambios que crearon con el proyecto principal. Incluye un proceso de revisión de esos cambios. Los revisores pueden insertar comentarios en cada parte que crean que podría mejorarse o que consideren innecesaria.

Después de recibir comentarios, el creador puede responder a ellos, crear una discusión o simplemente seguirlos y cambiar su código en consecuencia.

Git es simplemente una herramienta. Puedes usarlo de muchas maneras diferentes. Actualmente, los dos estilos de desarrollo más populares que puede encontrar son el flujo de Git y el desarrollo basado en troncos. Muy a menudo, las personas están familiarizadas con uno de esos estilos y pueden descuidar el otro.

Echemos un vistazo más de cerca a ambos y aprendamos cómo y cuándo debemos usarlos.

Flujo Git

En el modelo de desarrollo de flujo de Git, tiene una rama de desarrollo principal con acceso estricto a ella. A menudo se le llama la rama de develop .

Los desarrolladores crean ramas de funciones a partir de esta rama principal y trabajan en ellas. Una vez que terminan, crean solicitudes de extracción. En las solicitudes de extracción, otros desarrolladores comentan los cambios y pueden tener discusiones, a menudo bastante largas.

Lleva algún tiempo ponerse de acuerdo sobre una versión final de los cambios. Una vez que se acuerda, la solicitud de incorporación de cambios se acepta y se fusiona con la rama principal. Una vez que se decide que la rama principal ha alcanzado la madurez suficiente 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 publicarse para los usuarios finales. Una vez hecho esto, fusionamos el producto final con la rama master y lo etiquetamos con la versión de lanzamiento. Mientras tanto, se pueden desarrollar nuevas funciones en la rama de develop .

A continuación, puede ver el diagrama de flujo de Git, que representa un flujo de trabajo general:

Una de las ventajas del flujo de Git es el control estricto. Solo los desarrolladores autorizados pueden aprobar los cambios después de analizarlos detenidamente. Garantiza la calidad del código y ayuda a eliminar errores antes de tiempo.

Sin embargo, debe recordar que también puede ser una gran desventaja. Crea un embudo que ralentiza el desarrollo de software. Si la velocidad es su principal preocupación, entonces podría ser un problema grave. Las características desarrolladas por separado pueden crear ramas de larga duración que pueden ser difíciles de combinar con el proyecto principal.

Además, las solicitudes de extracción se centran en la revisión del código únicamente en el código nuevo. En lugar de mirar el código como un todo y trabajar para mejorarlo como tal, solo verifican los cambios recién introducidos. En algunos casos, pueden conducir a una optimización prematura, ya que siempre es posible implementar algo para que funcione más rápido.

Además, las solicitudes de incorporación de cambios pueden dar lugar a una microgestión extensa, en la que el desarrollador principal gestiona literalmente cada línea de código. Si tiene desarrolladores experimentados en los que puede confiar, ellos pueden manejarlo, pero es posible que esté desperdiciando su tiempo y sus habilidades. También puede desmotivar severamente a los desarrolladores.

En organizaciones más grandes, la política de la oficina durante las solicitudes de extracción es otra preocupación. Es concebible que las personas que aprueban las solicitudes de extracción puedan usar su posición para bloquear deliberadamente que ciertos desarrolladores realicen cambios en la base del código. Podrían hacer esto debido a la falta de confianza, mientras que algunos pueden abusar de su posición para saldar cuentas personales.

Ventajas y desventajas de Git Flow

Como puede ver, hacer solicitudes de incorporación de cambios puede no ser siempre la mejor opción. Deben usarse solo cuando sea apropiado.

¿Cuándo funciona mejor Git Flow?

• Cuando ejecuta un proyecto de código abierto.
  Este estilo proviene del mundo del código abierto y funciona mejor allí. Dado que todos pueden contribuir, desea tener un acceso muy estricto a todos los cambios. Desea poder verificar cada línea de código porque, francamente, no puede confiar en las personas que contribuyen. Por lo general, esos no son proyectos comerciales, por lo que la velocidad de desarrollo no es una preocupación.

• Cuando tienes muchos desarrolladores junior.
  Si trabaja principalmente con desarrolladores junior, entonces querrá tener una forma de verificar su trabajo de cerca. Puede darles múltiples sugerencias sobre cómo hacer las cosas de manera más eficiente y ayudarlos a mejorar sus habilidades más rápido. Las personas que aceptan solicitudes de extracción tienen un control estricto sobre los cambios recurrentes para que puedan evitar el deterioro 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 tales 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 restricción, por lo que este estilo funciona bien aquí. Además, las grandes empresas se adaptan perfectamente a este estilo. Necesitan controlar cada cambio de cerca, ya que no quieren arruinar su inversión multimillonaria.

¿Cuándo puede Git Flow causar problemas?

• Cuando estás empezando.
  Si recién está comenzando, Gitflow no es para usted. Lo más probable es que desee crear un producto mínimo viable rápidamente. Hacer solicitudes de extracción crea un gran cuello de botella que ralentiza drásticamente a todo el equipo. Simplemente no te lo puedes permitir. El problema con el flujo de Git es el hecho de que las solicitudes de extracción pueden llevar mucho tiempo. Simplemente no es posible proporcionar un desarrollo rápido de esa manera.

• Cuando necesite iterar rápidamente.
  Una vez que llegue a la primera versión de su producto, lo más probable es que necesite modificarlo varias veces para satisfacer las necesidades de sus clientes. Una vez más, las múltiples ramas y las solicitudes de extracción reducen drásticamente la velocidad de desarrollo y no se recomiendan en tales casos.

• Cuando trabajas principalmente con desarrolladores senior.
  Si su equipo está formado principalmente por desarrolladores sénior que han trabajado juntos durante un período de tiempo más largo, entonces realmente no necesita la microgestión de solicitudes de incorporación de cambios antes mencionada. Confías en tus desarrolladores y sabes que son profesionales. Deje que hagan su trabajo y no los retrase con toda la burocracia del flujo de Git.

Flujo de trabajo de desarrollo basado en troncales

En el modelo de desarrollo basado en troncos, todos los desarrolladores trabajan en una sola rama con acceso abierto a ella. A menudo es simplemente la rama master . Le asignan código y lo ejecutan. Es súper 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 para master . Garantiza que el desarrollo sea verdaderamente continuo y evita que los desarrolladores creen conflictos de combinación que son difíciles de resolver.

Echemos un vistazo al flujo de trabajo de desarrollo basado en troncales.

La única forma de revisar el código con este enfoque es realizar una revisión completa del código fuente. Por lo general, las discusiones largas son limitadas. Nadie tiene un control estricto sobre lo que se modifica en la base del código fuente, por eso es importante tener un estilo de código ejecutable. Los desarrolladores que trabajan con ese estilo deben tener experiencia para saber que no reducirán la calidad del código fuente.

Este estilo de trabajo puede ser excelente cuando trabaja 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ía en ellos, ya que pueden introducir código directamente en la rama master . Los desarrolladores en este flujo de trabajo son muy autónomos: entregan directamente y se verifican los resultados finales en el producto de trabajo. Definitivamente hay mucho menos microgestión y posibilidad de políticas de oficina en este método.

Si, por otro lado, no tiene un equipo experimentado o no confía en ellos por alguna razón, no debería usar este método; debería elegir Git flow en su lugar. Te ahorrará preocupaciones innecesarias.

Ventajas y desventajas del desarrollo basado en troncales

Echemos un vistazo más de cerca a ambos lados del costo: los mejores y los peores escenarios.

¿Cuándo funciona mejor el desarrollo basado en troncos?

• Cuando estás empezando.
  Si está trabajando en su producto mínimo viable, entonces este estilo es perfecto para usted. Ofrece la máxima velocidad de desarrollo con la mínima formalidad. Dado que no hay solicitudes de incorporación de cambios, los desarrolladores pueden ofrecer nuevas funciones a la velocidad de la luz. Solo asegúrese de contratar programadores experimentados.

• Cuando necesite iterar rápidamente.
  Una vez que llegó a la primera versión de su producto y notó que sus clientes quieren algo diferente, no lo piense dos veces y use este estilo para girar en una nueva dirección. Todavía está en la fase de exploración y necesita poder cambiar su producto lo más rápido posible.

• Cuando trabajas principalmente con desarrolladores senior.
  Si su equipo está formado principalmente por desarrolladores sénior, debe confiar en ellos y dejar que hagan su trabajo. Este flujo de trabajo les da la autonomía que necesitan y les permite ejercer el dominio de su profesión. Solo dales un propósito (tareas a realizar) y observa cómo crece tu producto.

¿Cuándo puede causar problemas el desarrollo basado en troncos?

• Cuando ejecuta un proyecto de código abierto.
  Si está ejecutando un proyecto de código abierto, Git flow es la mejor opción. Necesita un control muy estricto sobre los cambios y no puede confiar en los colaboradores. Después de todo, cualquiera puede contribuir. Incluidos los trolls en línea.

• Cuando tienes muchos desarrolladores junior.
  Si contrata principalmente a desarrolladores junior, entonces es una mejor idea controlar estrictamente lo que están haciendo. Las solicitudes de extracción estrictas les ayudarán a mejorar sus habilidades y encontrarán errores potenciales más rápidamente.

• Cuando haya establecido un producto o gestione grandes equipos.
  Si ya tiene un producto próspero o administra grandes equipos en una gran empresa, entonces el flujo de Git podría ser una mejor idea. Desea tener un control estricto sobre lo que sucede con un producto bien establecido que vale millones de dólares. Probablemente, el rendimiento de la aplicación y las capacidades de carga son las cosas más importantes. Ese tipo de optimización requiere cambios muy precisos.

Usa la herramienta correcta para el trabajo correcto

Como dije antes, Git es solo una herramienta. Como cualquier otra herramienta, debe usarse adecuadamente.

El flujo de Git administra todos los cambios a través de solicitudes de incorporación de cambios. Proporciona un estricto control de acceso a todos los cambios. Es ideal para proyectos de código abierto, grandes empresas, empresas con productos establecidos o un equipo de desarrolladores junior sin experiencia. Puede verificar con seguridad lo que se está introduciendo en el código fuente. Por otro lado, podría conducir a una microgestión extensa, disputas relacionadas con la política de la oficina y un desarrollo significativamente más lento.

El desarrollo basado en troncos otorga a los programadores plena autonomía y expresa más fe en ellos y en su juicio. El acceso al código fuente es gratuito, por lo que realmente necesita poder confiar en su equipo. Proporciona una excelente velocidad de desarrollo de software y reduce los procesos. Estos factores lo hacen perfecto a la hora de crear nuevos productos o cambiar una aplicación existente en una dirección completamente nueva. Funciona de maravilla si trabaja principalmente con desarrolladores experimentados.

Aún así, si trabaja con programadores junior o personas en las que no confía completamente, Git flow es una alternativa mucho mejor.

Equipado con este conocimiento, espero que pueda elegir el flujo de trabajo que se adapte perfectamente a su proyecto.