tag - que es un repositorio git

Estrategia de la sucursal de Git para el pequeño equipo de desarrollo (6)

Tenemos una aplicación web que actualizamos y lanzamos casi a diario. Usamos git como nuestro VCS, y nuestra estrategia de bifurcación actual es muy simple y está rota: tenemos una rama principal y comprobamos los cambios en los que "nos sentimos bien". Esto funciona, pero solo hasta que verifiquemos un cambio de rotura.

¿Alguien tiene una estrategia favorita de sucursal git para equipos pequeños que cumpla con los siguientes requisitos:

Funciona bien para equipos de 2 a 3 desarrolladores
Ligero, y no demasiado proceso
Permite a los desarrolladores aislar el trabajo de las correcciones de errores y las funciones más grandes con facilidad
Nos permite mantener una sucursal estable (para esos momentos de ''oh mierda'' cuando tenemos que hacer funcionar nuestros servidores de producción)

Idealmente, me encantaría ver su proceso paso a paso para un desarrollador que trabaja en un nuevo error

(Hice mi comment anterior sobre su propia respuesta, como debería haberlo hecho inicialmente).

De Scott Chacon de Github:

Cómo lo hacemos Entonces, ¿qué es GitHub Flow?
Cualquier cosa en la rama principal es desplegable
Para trabajar en algo nuevo, crea una rama designada con nombre descriptivo de maestro (es decir: new-oauth2-scopes)
Comprométase con esa sucursal localmente y periódicamente envíe su trabajo a la misma sucursal con nombre 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 otra persona haya revisado y firmado la función, puede fusionarla en principal
Una vez que se fusiona y se empuja a ''maestro'', puede y debe implementar de inmediato

Consulte el artículo completo para obtener más información: scottchacon.com/2011/08/31/github-flow.html

Tenga en cuenta que las "solicitudes de extracción" son una invención de Github, y es algo que está incluido en su sitio web, no en Git: https://help.github.com/articles/using-pull-requests/

Después de ingresar como novato, intentaba encontrar una estrategia sencilla para enseñar a otros desarrolladores que nunca usaron el control de fuente. Este es el que encaja http://nvie.com/posts/a-successful-git-branching-model/ Traté de usar el flujo de trabajo GIT estándar en las páginas man, pero me confundió un poco y mi audiencia por completo.

En los últimos 6 meses solo tuve que arreglar conflictos dos veces. He agregado pasos para probar siempre después de una combinación y para ''buscar y fusionar'' o ''extraer --rebase'' mucho (una vez en la mañana y en la tarde) mientras desarrollé funciones. También utilizamos github.com como el lugar central para extraer el último código.

En un VCS, tener solo una rama "maestra" muestra rápidamente sus límites porque no se puede perseguir todo el esfuerzo de desarrollo al mismo tiempo en una rama.
Eso significa que necesita saber cuándo ramificarse .

Pero en un DVCS (como en el VCS "Descentralizado"), también tiene un problema de publicación , con sucursales que mantiene localmente en sus repositorios, y ramas a las que está presionando o tirando.

En este contexto, comience por identificar su esfuerzo de desarrollo concurrente y decida sobre un proceso de publicación (push / pull). Por ejemplo (y esta no es la única manera):

prod es una sucursal pública de solo lectura con el código en producción. Todos podrían sacarlo para:
- rebase su desarrollo actual encima (para pruebas locales, o para integrar en el desarrollo local una revisión hecha en el prod repo en la rama prod)
- rama para hacer nuevas características (de un código estable conocido)
- rama para iniciar la siguiente rama de la versión (la que va a estar en producción)
  nadie debe presionar directamente para prod (por lo tanto, el de solo lectura)
release es una rama de consolidación de lectura y escritura, donde los commit relevantes se seleccionan para formar parte de la próxima versión.
Todos pueden presionar para lanzar para actualizar la próxima versión.
Todos pueden aprovechar dicho lanzamiento para actualizar su proceso de consolidación local.
featureX es una rama de lectura y escritura privada (en el sentido de que no necesita ser presionada para el almacén central de prod), y puede ser empujada / tirada entre dev repos. Representa un esfuerzo de medio a largo plazo, diferente del desarrollo diario
master representa el desarrollador actual, y se empuja / tira entre los repos de dev.

Existen otros procesos de gestión de versiones, como lo atestigua esta pregunta SO .

Lea atentamente el flujo de trabajo de ReinH para equipos ágiles aquí: http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

Esto funciona muy bien para equipos pequeños. El objetivo aquí es asegurarnos de que todo lo que sea potencialmente inestable entre en una rama de algún tipo. Únase de nuevo al maestro cuando esté listo para que todos los que trabajen fuera de la rama de características puedan usarlo.

Nota: esta estrategia es poco específica, pero git hace que la implementación de esta estrategia sea bastante fácil.

Puede beneficiarse del flujo de trabajo que Scott Chacon describe en Pro Git . En este flujo de trabajo, tiene dos ramas que siempre existen, dominar y desarrollar .

master representa la versión más estable de su proyecto y solo se implementa en producción desde esta rama.

develop contiene cambios que están en progreso y pueden no estar necesariamente listos para la producción.

Desde la rama de desarrollo , crea ramas temáticas para trabajar en funciones y soluciones individuales. Una vez que su función / corrección está lista para continuar, la fusiona para desarrollarse , momento en el que puede probar cómo interactúa con otras ramas temáticas en las que se han fusionado sus compañeros de trabajo. Una vez que el desarrollo se encuentre en estado estable, fusiónelo en maestro . Siempre debe ser seguro implementar en producción desde el maestro .

Scott describe estas ramas de larga duración como "silos" de código, donde el código en una rama menos estable eventualmente se "graduará" a uno considerado más estable después de las pruebas y la aprobación general de su equipo.

Paso a paso, su flujo de trabajo en este modelo podría verse así:

Necesitas arreglar un error.
Crea una rama llamada myfix que se basa en la rama de desarrollo .
Trabaja en el error en esta rama de tema hasta que se solucione.
Fusionar myfix en desarrollar . Ejecuta pruebas.
Descubres los conflictos de arreglos con otra rama de tema hisfix en la que se fusionó tu compañero de trabajo mientras trabajabas en tu solución.
Haga más cambios en la rama myfix para lidiar con estos conflictos.
Fusiona myfix en desarrollar y ejecutar pruebas nuevamente.
Todo funciona bien Fusionar desarrollar en maestro .
Despliegue a producción desde el maestro en cualquier momento, porque sabe que es estable.

Para obtener más detalles sobre este flujo de trabajo, consulte el capítulo Flujos de trabajo de ramificación en Pro Git.

Utilice la rama master como su rama de desarrollo y cree ramas de publicación para realizar correcciones de errores.

Todas las funciones nuevas se ejecutarán master durante la ventana de desarrollo (ya sea directamente o como ramas de tema con solicitudes de extracción, dependiendo de usted, no se muestra en el gráfico). Una vez que se hayan implementado todas las características planificadas, ingrese el congelamiento de características y realice las pruebas. Cuando esté satisfecho, marque el lanzamiento en el master como v1.0 .

Con el tiempo, los usuarios encontrarán errores en v1.0 por lo que querrá crear una rama a partir de esa etiqueta (p. Ej. Nombrarla después de la versión 1.0 ) y corregir esos errores en la rama. Cuando haya reparado suficientes errores que cree que merecen una nueva versión, v1.0.1 como v1.0.1 y v1.0.1 fusionarlos en master .

Mientras tanto, puede estar ocurriendo una nueva ventana de desarrollo en la rama master que eventualmente será etiquetada como v1.1 .

Enjuague y repita.

Esto sigue la lógica de numeración de la versión semántica .

---------(v1.0)--------------------------------(v1.1)-----------------------------> master / / ---(v1.0.1)---(v1.0.2)---> 1.0 ---(v1.1.1)---(v1.1.2)---> 1.1