🛑 Esto es una traducción rápida al español del artículo de George Stocker publicado a través de su blog.. Esto es una traducción rápida al español del artículo de George Stocker publicado a través de su blog.. 👓
Git-flow es una metodología de ramificación y fusión popularizada por esta publicación de blog , titulada "Un modelo de ramificación Git exitoso".
En los últimos diez años, innumerables equipos han sido burlados por el titular y me atrevo a decir que les mentí .
Si lees la publicación del blog, el autor afirma que la introdujo con éxito en sus proyectos, pero a propósito no habla sobre los detalles del proyecto que la hicieron exitosa .
Y para el resto de nosotros, este es el error # 1 de confiar en la publicación del blog. Afirmaré que es obvio que no todas las estrategias funcionan en todas las situaciones, con todas las personas, en todos los contextos, y aplico esa misma lógica a este modelo de ramificación.
El final, ¿verdad? Bueno, no del todo. Puedo decir que algunos de ustedes no están convencidos por esta línea de razonamiento, así que profundicemos en por qué el modelo de ramificación gitflow debería morir en un incendio .
GitFlow es complicado en su cara
Incluso antes de pensar en Microservicios, o entrega continua, gitflow es complicado. Echa un vistazo a esta imagen y dime que es inmediatamente intuitiva:
Así que aquí tienes ramas de características, ramas de lanzamiento, master, desarrollo, una rama de revisión y etiquetas git. Estas son todas las cosas que deben rastrearse, comprenderse y contabilizarse en su proceso de compilación y lanzamiento.
Más que eso, también necesita hacer un seguimiento de qué rama es qué, todo el tiempo . El modelo mental que necesita conservar para que esto sea útil conlleva una alta carga cognitiva. He estado usando git durante 10 años, y ni siquiera estoy seguro de estar en el punto en que pueda seguir mentalmente lo que está sucediendo aquí.
Gitflow viola la regla de ramas de "vida corta"
En git, el número de conflictos de fusión con personas que se comprometen con una rama aumentará con el número de personas que trabajan en esa rama. Con git-flow, ese número aumenta aún más, porque hay otras tres ramas (de vidas variables) que se fusionan para desarrollarse: ramas de características, ramas de liberación y soluciones rápidas. Entonces, ahora el potencial de conflictos de fusión no es lineal, potencialmente triplicará las oportunidades para conflictos de fusión.
No gracias.
Si bien dudo en decir "Preocuparse por los conflictos de fusión" es una razón válida para no seguir una estrategia de ramificación como gitflow; la cantidad de complejidad potencial que se introduce cuando se juntan todas estas ramas es demasiado para pasarla por alto. Esto estaría bien si tiene una organización con una tasa de velocidad de compromiso baja; pero para cualquier organización o startup rápida y apreciable, este no será el caso.
Gitflow abandona el rebase
Reconozco que el rebase es un tema complejo; Pero es importante para esta conversación. Si persigue gitflow, tendrá que renunciar a rebase. Recuerde, el rebase elimina el compromiso de fusión, el punto donde puede ver dos ramas que se unen. Y con la complejidad visual de gitflow, necesitará rastrear visualmente las ramas, y eso significa que no necesita rebase si desea resolver un problema.
Gitflow hace improbable la entrega continua
La entrega continua es una práctica en la que el equipo se lanza directamente a producción con cada "check-in" (en realidad, una fusión para dominar), de manera automatizada. Mire el desorden que es gitflow y explíqueme cómo podrá entregar continuamente * eso *.
Todo el modelo de ramificación se basa en un ciclo de lanzamiento predecible a largo plazo; no fuera liberando nuevo código cada pocos minutos u horas. Hay demasiados gastos generales para eso; sin mencionar que una de las prácticas centrales de CD es avanzar con correcciones; y Gitflow trata las revisiones como una entidad separada para preservar, controlar y separar cuidadosamente de otros trabajos.
Es imposible trabajar con Gitflow en múltiples repositorios
Con la llegada de los microservicios; también ha habido un mayor impulso hacia la idea de los micro-repositorios (el comentarista que grita "son ortogonales entre sí"), donde los equipos individuales tienen control sobre sus repositorios y flujos de trabajo, y donde pueden controlar quién se registra sus repositorios y cómo funcionan sus flujos de trabajo.
¿Alguna vez * probó * un modelo de ramificación complejo como gitflow con varios equipos y esperaba que todos estuvieran en la misma página? No puede pasar Pronto, el sistema se convierte en un manifiesto de las diferentes revisiones de los diferentes repositorios, y las únicas personas que saben dónde está todo son las personas que golpean el YAML para actualizar los manifiestos. "Lo que está en producción" se convierte en una pregunta existencial, si no tienes cuidado.
Es imposible trabajar con Gitflow en un monorepo también
Entonces, si los micro-repos están fuera debido a la dificultad de coordinar los lanzamientos, ¿por qué no solo un gran flujo de trabajo de ramificación que todos los equipos de microservicios deben cumplir para los lanzamientos?
Esto funciona durante aproximadamente 3.2 segundos, o el tiempo que le toma a un equipo decir "Esto tiene que salir ahora", cuando los otros equipos no están listos para que sus cosas sean lanzadas. Si los equipos son independientes y los microservicios deberían implementarse de forma independiente, no puede vincular muy bien su flujo de trabajo al modelo de ramificación centralizado que creó en su mono-repos.
¿Quién debería (y no debería) usar Gitflow?
Si su organización está en un ciclo de lanzamiento mensual o trimestral y es un equipo que trabaja en varios lanzamientos en paralelo, Gitflow puede ser una buena opción para usted. Si su equipo es una startup, o un sitio web o aplicación web con conexión a Internet, donde puede tener múltiples lanzamientos en un día; gitflow no es bueno para ti. Si su equipo es pequeño (menos de 10 personas), gitflow pone demasiada ceremonia y gastos generales en su trabajo.
Si sus equipos, por otro lado, son más de 20 personas trabajando en lanzamientos paralelos, gitflow presenta la ceremonia suficiente para asegurarse de que no arruine las cosas.
Ok, entonces mi equipo no debería usar gitflow. ¿Qué debemos usar?
No puedo responder eso. No todos los modelos de ramificación funcionan para todos los equipos, en todos los contextos y todas las culturas. Si practicas CD, quieres algo que agilice tu proceso tanto como sea posible. Algunas personas juran por el desarrollo sin troncos y cuentan con banderas. Sin embargo, esos me asustan muchísimo desde una perspectiva de prueba.
El punto crucial que estoy haciendo es hacer preguntas a su equipo: ¿Qué problemas nos ayudará a resolver este modelo de ramificación? ¿Qué problemas creará? ¿Qué tipo de desarrollo fomentará este modelo? ¿Queremos fomentar ese comportamiento? En última instancia, cualquier modelo de ramificación que elija tiene como objetivo hacer que los humanos trabajen juntos más fácilmente para producir software, por lo que el modelo de ramificación debe tener en cuenta las necesidades de los humanos en particular que lo usan, no es algo que alguien escribió en Internet y afirmó que fue 'exitoso '.
Nota final del autor: pensé en usar el apodo 'considerado dañino' que es tan común en publicaciones como esta; pero luego realicé una búsqueda en Google y me di cuenta de que alguien más ya había escrito que Gitflow lo consideraba perjudicial . Ese artículo también vale tu tiempo.
Fuente: Georgestocker.com por George Stocker
Read more:
Source: https://georgestocker.com
|
|
|
|
|
|
|
|
|
|
Posted using AltYes browser extension.