¿Cuáles son los pros y los contras de git-flow vs github-flow? [cerrado]

Recientemente hemos comenzado a usar GitLab.

Actualmente utilizando un flujo de trabajo "centralizado".

Estamos considerando pasar al flujo de github, pero quiero asegurarme.

¿Cuáles son los pros y los contras de git-flow vs github-flow ?

Como se discutió en el episodio 17 de GitMinutes, por Nicholas Zakas en su artículo sobre " Flujos de trabajo de GitHub dentro de una empresa ":

Git-flow es un proceso para gestionar cambios en Git creado por Vincent Driessen y acompañado de algunas extensiones de Git para gestionar ese flujo.
La idea general detrás de git-flow es tener varias ramas separadas que siempre existen, cada uno con un propósito diferente: master, develop, feature, release, y hotfix.
El proceso de desarrollo de características o errores fluye de una rama a otra antes de que finalmente se lance.

Algunos de los encuestados indicaron que usan git-flowen general.
Algunos comenzaron git-flowy se alejaron de él.

La razón principal para alejarse es que el git-flowproceso es difícil de manejar en un modelo de implementación continua (o casi continua).
La sensación general es que git-flowfunciona bien para productos en un modelo de lanzamiento más tradicional, donde los lanzamientos se realizan una vez cada pocas semanas, pero que este proceso se rompe considerablemente cuando se lanza una vez al día o más .

En breve:

Comience con un modelo lo más simple posible (como suele ser el flujo de GitHub) y avance hacia un modelo más complejo si es necesario.

Puede ver una ilustración interesante de un flujo de trabajo simple , basado en GitHub-Flow en:
" Un modelo de ramificación git simple ", cuyos elementos principales son:

1. master siempre debe ser desplegable.
2. todos los cambios realizados a través de ramas de características (solicitud de extracción + fusión)
3. rebase para evitar / resolver conflictos; unirse conmaster

Para un flujo de trabajo real más completo y robusto, vea gitworkflow (una palabra) .

No hay flujo de trabajo de bala de plata donde todos deberían seguir, ya que todos los modelos son subóptimos. Dicho esto, puede seleccionar el modelo adecuado para su software en función de los siguientes puntos;

Varias versiones en producción: use Git-flow

Si su código tiene múltiples versiones en producción (es decir, productos de software típicos como sistemas operativos, paquetes de Office, aplicaciones personalizadas, etc.), puede usar git-flow. La razón principal es que necesita admitir continuamente versiones anteriores en producción mientras desarrolla la próxima versión.

Versión única en software simple de producción: use Github-flow

Si su código solo tiene una versión en producción en todo momento (es decir, sitios web, servicios web, etc.), puede usar github-flow. La razón principal es que no necesita cosas complejas para el desarrollador. Una vez que el desarrollador finaliza una función o finaliza una corrección de errores, se promociona inmediatamente a la versión de producción.

Versión única en producción pero software muy complejo: use Gitlab-flow

Con un software grande como Facebook y Gmail, es posible que deba introducir ramas de implementación entre su rama y la rama maestra donde podrían ejecutarse las herramientas de CI / CD>, antes de que entre en producción. La idea es introducir más protección a la versión de producción, ya que es utilizada por millones de personas.

He estado usando el modelo git-flow durante más de un año y está bien.

Pero realmente depende de cómo se desarrollará y desplegará su aplicación.

Funciona bien cuando tiene una aplicación que tiene un flujo lento de desarrollo / implementación.

Pero, por ejemplo, al igual que GitHub, tenemos una aplicación que tiene un flujo de desarrollo / implementación rápido, implementamos todos los días, y a veces varias veces al día, en este caso, git-flow tiende a ralentizar todo en mi opinión, y uso GitHub fluir.

La otra cosa a tener en cuenta es que git-flow no es git estándar, por lo que podría, y cuando digo que sí, quiero decir, encontrará desarrolladores que no lo saben, y luego está la curva de aprendizaje, más oportunidad de estropear las cosas. Además, como se mencionó anteriormente, alguien desarrolló un conjunto de scripts para facilitar el uso de git-flow, por lo que no tiene que recordar todos los comandos, lo ayudará con los comandos, pero recordar el flujo real es su trabajo , Me he encontrado más de una vez cuando un desarrollador no sabía si se trataba de una revisión o característica, o incluso peor cuando no pueden recordar el flujo y rellenar las cosas.

Hay al menos una GUI que admite git-flow para Mac y Windows SourceTree .

En estos días, me estoy inclinando más hacia el flujo de GitHub, debido a su simplicidad y facilidad de administración. Además, debido a "desplegar despliegue temprano a menudo" ...

Espero que esto ayude