oficial - gitlab version control

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

Question

Recientemente hemos empezado a usar GitLab.

Actualmente usa un flujo de trabajo "centralizado".

Estamos considerando mudarnos a github-flow, pero quiero asegurarme.

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

Answer 1

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 una para un propósito diferente: master , develop , feature , release y hotfix .
El proceso de desarrollo de funciones o errores fluye de una rama a otra antes de que finalmente se lance.

Algunos de los encuestados indicaron que usan git-flow en general.
Algunos comenzaron con git-flow y se alejaron de él.

La razón principal para alejarse es que el proceso de git-flow es difícil de tratar en un modelo de implementación continuo (o casi continuo).
La sensación general es que git-flow funciona bien para los productos en un modelo de lanzamiento más tradicional, donde los lanzamientos se realizan una vez cada varias semanas, pero que este proceso se descompone considerablemente cuando se libera una vez al día o más .

En breve:

Comience con un modelo lo más simple posible (como tiende a ser el flujo 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 simple de ramificación git ", con los elementos principales siendo:

1. master siempre debe ser desplegable.
2. todos los cambios realizados a través de ramas de características (pull-request + merge)
3. rebase para evitar / resolver conflictos; fusionarse para master

Answer 2

He estado usando el modelo de 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, como GitHub tenemos una aplicación que tiene un flujo de desarrollo / despliegue rápido, implementamos todos los días, y algunas 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 un git estándar, por lo que podría ser, y cuando digo que lo harías, realmente quiero decir que encontrarás desarrolladores que no lo saben, y luego está la curva de aprendizaje, más oportunidad de estropear las cosas. También como se mencionó anteriormente, alguien desarrolló un conjunto de scripts para hacer más fácil el uso de git-flow, por lo que no tiene que recordar todos los comandos, le 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 era un hotfix o una característica, o peor aún, cuando no podían recordar el flujo y cosas así.

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

En estos días, me inclino más hacia el flujo de GitHub, debido a su simplicidad y fácil de administrar. Además, debido a "implementar implementación temprana a menudo" ...

Espero que esto ayude

Answer 3

No hay un flujo de trabajo milagroso donde todos deberían seguir, ya que todos los modelos no son óptimos. Una vez dicho esto, puede seleccionar el modelo adecuado para su software basado en los puntos siguientes;

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 oficina, aplicaciones personalizadas, etc.) puede usar git-flow. La razón principal es que necesita soportar 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 tiene una sola 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 complicar las cosas para el desarrollador. Una vez que el desarrollador finaliza una función o finaliza una corrección de errores, se la promociona inmediatamente a la versión de producción.

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

Software de gran tamaño como Facebook y Gmail, puede que necesite introducir ramas de implementación entre su sucursal y la sucursal maestra donde se podrían ejecutar las herramientas de CI / CD, antes de que entre en producción. Idea es introducir más protección a la versión de producción ya que es utilizada por millones de personas.