A podar ramas: Master-only Git Workflow ✂️🌳 | Flujos de trabajo con Git 6/7

🔥 ¡Aprovecha la oferta del Black Friday de CodelyTV Pro!
---
Analizamos #MasterOnlyWorkflow: Un flujo de trabajo NO en ramas para #Git muy popular y que se diferencia totalmente de #GitFlow. TODO el trabajo se hace en master pero… más allá de lo evidente ¿qué pasa con esos beneficios que obteníamos del trabajo en ramas? ¿Ya no hay Pull Requests con revisiones de código? ¿Cómo compartimos conocimiento técnico y del dominio? ¿Qué pasa con las pipelines de integración continua que se ejecutan al hacer merge a master?
¡Lo vemos en el vídeo!

Importante: Cabe destacar que estamos totalmente sesgados por los entornos donde hemos trabajado (letgo, Akamon, Uvinum, etc) y damos una versión totalmente opinionada en base a esto. El contexto marcará si realmente es útil en cada caso y, al igual que con todo, los workflows de Git serán buenos o no según dónde se apliquen 👼

🔗 Enlaces relacionados:

{▶️} CodelyTV

[CodelyTV]

🔗 Enlaces relacionados:

{▶️} CodelyTV

[elProdigio]

Para mí es el antiflow. Venía de usar SVN y como usar branches es bastante infernal, todos acabábamos subiendo a "trunk". Ahora hemos migrado a Git y usamos una especie de Git-flow pero sin usar la rama "release" para detectar bugs, si no, que esa fase de detección de bugs, la vamos haciendo directamente en "develop". He de reconocer, tras el primer periodo de adaptación, estamos muy a gusto trabajando así.

[feyaluciano]

Para mi es este Master-only flow, si el equipo de trabajo es chico creo que seria el mas sencillo

[Albarranator]

Para mí que su favorito es el Trunk-based flow y el que detestan al 1000 es el GitFlow

[andresco]

Su contenido es EXCELENTE, de verdad lo digo... pero por la forma en que hablan (tanto en expresiones como en velocidad) a veces de verdad que me cuesta entenderles... seria algo bueno para trabajar en el 2020!!!

[TaresPhi]

Este no me aplica, se suele tener doferencias en distintos ambientes al mismo tiempo alli como ?

[lechuck]

Este es el que me pareció peor de todo por lejos. Solamente se me ocurrira usarlo en proyectos muy chicos con equipos muy chicos(2 devs o 3 estirando). Lo más lindo de Git es lo barato que es crear una branch nueva y esto propone ir para atras. Tampoco me parece bien abusar de Features Flags para todo lo que estamos haciendo la administracion de esto asume más y más complejidad y en definitiva criticaron git flow porque tiene mucha burocracia y es propenso a errores y esto me parece que es todo lo opuesto un caos absoluto y mas propenso a errores ya que ponemos la complejidad del versionado en el codigo como FF.
Solo me imagino que puede "servir" en caso de un producto que este pronto, estemos en mantenimiento, el equipo se achico demasiado y no se planea nuevas features, solo correccion de errores.