Git
Análisis de tipos de flujos de trabajo.

Observaciones

Gitflow Workflow

Propuesto originalmente por Vincent Driessen , Gitflow es un flujo de trabajo de desarrollo que utiliza git y varias sucursales predefinidas. Esto puede verse como un caso especial del flujo de trabajo de rama de entidad .

La idea de este es tener sucursales separadas reservadas para partes específicas en desarrollo:

• master rama master es siempre el código de producción más reciente. El código experimental no pertenece aquí.
• develop rama contiene todos los últimos desarrollos . Estos cambios de desarrollo pueden ser prácticamente cualquier cosa, pero las funciones más grandes están reservadas para sus propias sucursales. El código aquí siempre se trabaja y se combina en la release anterior a la versión / implementación.
• hotfix sucursales de la hotfix son para correcciones de errores menores, que no pueden esperar hasta la próxima versión. hotfix sucursales de hotfix salen del master y se fusionan de nuevo con el master y el develop .
• release ramas de release se utilizan para liberar nuevos desarrollos, desde develop hasta master . Todos los cambios de última hora, como los números de versión bumping, se realizan en la rama de la versión, y luego se fusionan de nuevo en master y develop . Al implementar una nueva versión, el master debe etiquetarse con el número de la versión actual (p. Ej., Con el uso de versiones semánticas ) para referencia futura y fácil restauración.
• feature ramas de feature están reservadas para funciones más grandes. Estos se desarrollan específicamente en las sucursales designadas y se integran con el develop cuando se termina. Dedicados feature ramas ayudan a separar el desarrollo y para poder desplegar prestaciones realizadas de forma independiente el uno del otro.

Una representación visual de este modelo:

La representación original de este modelo:

Flujo de trabajo de bifurcación

Este tipo de flujo de trabajo es fundamentalmente diferente de los otros mencionados en este tema. En lugar de tener un repositorio centralizado al que todos los desarrolladores tienen acceso, cada desarrollador tiene su propio repositorio que se bifurca del repositorio principal. La ventaja de esto es que los desarrolladores pueden publicar en sus propios repositorios en lugar de un repositorio compartido y un mantenedor puede integrar los cambios de los repositorios bifurcados en el original cuando sea apropiado.

Una representación visual de este flujo de trabajo es la siguiente:

Flujo de trabajo centralizado

Con este modelo de flujo de trabajo fundamental, una rama master contiene todo el desarrollo activo. Los contribuyentes deberán estar especialmente seguros de sacar los últimos cambios antes de continuar con el desarrollo, ya que esta rama cambiará rápidamente. Todos tienen acceso a este repositorio y pueden enviar cambios directamente a la rama maestra.

Representación visual de este modelo:

Este es el paradigma clásico de control de versiones, sobre el cual se construyeron sistemas más antiguos como Subversion y CVS. Los softwares que funcionan de esta manera se denominan sistemas de control de versiones centralizados o CVCS. Si bien Git es capaz de trabajar de esta manera, existen desventajas notables, como ser requerido para preceder cada tirón con una combinación. Es muy posible que un equipo trabaje de esta manera, pero la resolución constante de conflictos de fusión puede terminar consumiendo mucho tiempo valioso.

Es por esto que Linus Torvalds creó Git no como un CVCS, sino como un DVCS , o un Sistema de Control de Versiones Distribuido , similar a Mercurial. La ventaja de esta nueva forma de hacer las cosas es la flexibilidad demostrada en los otros ejemplos de esta página.

Rama de trabajo del flujo de trabajo

La idea central detrás del flujo de trabajo de la rama de características es que todo el desarrollo de funciones debe tener lugar en una rama dedicada en lugar de la rama master . Esta encapsulación facilita que los desarrolladores múltiples trabajen en una característica particular sin molestar al código base principal. También significa que la rama master nunca contendrá código roto, lo que es una gran ventaja para los entornos de integración continua.

El desarrollo de la característica de encapsulación también hace posible aprovechar las solicitudes de extracción, que son una forma de iniciar discusiones en torno a una rama. Le dan a otros desarrolladores la oportunidad de firmar una función antes de que se integre en el proyecto oficial. O, si se queda atascado en medio de una función, puede abrir una solicitud de extracción solicitando sugerencias de sus colegas. El punto es que las solicitudes de extracción hacen que sea increíblemente fácil para su equipo comentar sobre el trabajo de cada uno.

basado en los tutoriales de Atlassian .

GitHub Flow

Popular dentro de muchos proyectos de código abierto pero no solo.

La rama principal de una ubicación específica (Github, Gitlab, Bitbucket, servidor local) contiene la última versión de envío. Para cada nueva característica / corrección de errores / cambio arquitectónico, cada desarrollador crea una rama.

Los cambios suceden en esa rama y se pueden discutir en una solicitud de extracción, revisión de código, etc. Una vez aceptados, se fusionan con la rama maestra.

Flujo completo por Scott Chacon:

• Cualquier cosa en la rama maestra es desplegable
• Para trabajar en algo nuevo, cree una rama con nombre descriptivo fuera del maestro (es decir: new-oauth2-scopes)
• Comprométase con esa sucursal localmente y envíe su trabajo regularmente a la misma sucursal nombrada en el servidor
• Cuando necesite comentarios o ayuda, o si cree que la sucursal está lista para fusionarse, abra una solicitud de extracción
• Después de que alguien más haya revisado y desactivado la función, puede combinarla en el maestro
• Una vez que se fusiona y se empuja a 'maestro', puede y debe implementar de inmediato

Presentado originalmente en el sitio web personal de Scott Chacon .

Imagen cortesía de la referencia de GitHub Flow.