Estrategia de sucursal de Git para equipo de desarrollo pequeño [cerrado]


186

Tenemos una aplicación web que actualizamos y lanzamos casi a diario. Utilizamos git como nuestro VCS, y nuestra estrategia de ramificación actual es muy simple y está rota: tenemos una rama maestra y verificamos los cambios con los que nos sentimos "bien". Esto funciona, pero solo hasta que verifiquemos un cambio importante.

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

  1. Funciona bien para equipos de 2 a 3 desarrolladores.
  2. Ligero, y no demasiado proceso
  3. Permite a los desarrolladores aislar el trabajo en la corrección de errores y características más grandes con facilidad
  4. Nos permite mantener una rama estable (para esos momentos 'oh mierda' cuando tenemos que hacer que nuestros servidores de producción funcionen)

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

Respuestas:


247

Podría beneficiarse del flujo de trabajo que Scott Chacon describe en Pro Git . En este flujo de trabajo, tiene dos ramas que siempre existen, master y desarrollo .

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

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

Desde la rama de desarrollo , puede crear ramas de temas para trabajar en arreglos y características individuales. Una vez que su función / arreglo está listo para funcionar, lo fusiona en desarrollo , en ese momento puede probar cómo interactúa con otras ramas temáticas en las que sus compañeros de trabajo se han fusionado. Una vez que el desarrollo esté en un estado estable, combínelo en maestro . Siempre debe ser seguro implementarlo 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 una considerada más estable después de las pruebas y la aprobación general de su equipo.

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

  1. Necesitas arreglar un error.
  2. Cree una rama llamada myfix que se base en la rama de desarrollo .
  3. Trabaje en el error en esta rama de tema hasta que se solucione.
  4. Combinar myfix en desarrollar . Ejecute pruebas.
  5. Usted descubre que su arreglo entra en conflicto con otro hisfix de rama de tema en el que su compañero de trabajo se fusionó para desarrollar mientras trabajaba en su arreglo.
  6. Realice más cambios en la rama myfix para lidiar con estos conflictos.
  7. Combinar myfix en desarrollar y ejecutar pruebas de nuevo.
  8. Todo funciona bien Fusionarse para convertirse en maestro .
  9. Implemente en 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.


77
También de Scott Chacon tiene un excelente artículo en su sitio sobre cómo funciona el flujo de trabajo de Github con Git - scottchacon.com/2011/08/31/github-flow.html
program247365

71
Creo que esto es genial, excepto que si creas ramas de corrección de errores desde la rama de desarrollo, estás forzando que no puedas fusionarlo en maestro y desplegarlo sin también fusionar todo lo demás "nuevo" que aún no has lanzado, que podría ser un verdadero dolor si hay algo en esa rama que necesita documentar / cambios en la base de datos o algo más difícil de hacer. Creo que para los "hotfixes" urgentes, deberías hacer tu rama desde master.
Richard

55
¿Qué sucede si estamos desarrollando 2 características separadas, F1 y F2, donde F1 se lanzará en una semana pero F2 se lanzará en 2 semanas, suponiendo que el desarrollo de F1 y F2 coincida? ¿Alguna sugerencia sobre eso?
Murat Derya Özen

44
El developes una 'solución' innecesario a un problema que no tiene git. Por lo que puedo decir, el éxito se debe a un artículo bien escrito, si está mal dirigido, sin comentarios permitidos. Aquí hay un contra-artículo barro.github.io/2016/02/…
Tim Abell

55
En el paso 8, fusionar la rama de desarrollo en maestro parece una mala idea dado que parte del código en desarrollo podría no estar listo para entrar en producción. ¿No sería mejor fusionar la rama de características en maestra?
Todd

45

Después de llegar como un novato tratando de encontrar una estrategia directa para enseñar a otros desarrolladores que nunca han usado el control de la fuente. Este es el que se ajusta a http://nvie.com/posts/a-successful-git-branching-model/ Intenté usar el flujo de trabajo estándar de GIT que está en las páginas del manual, pero me confundió un poco y a mi audiencia por completo.

En los últimos 6 meses solo he tenido que arreglar conflictos dos veces. He agregado pasos para probar siempre después de una fusión y para 'buscar y fusionar "o' extraer --rebase" mucho (una vez por la mañana y por la tarde) al desarrollar funciones. También usamos github.com como el lugar central para extraer el último código.


Ese es un excelente enlace! Ese flujo de trabajo funciona muy bien para nuestro pequeño equipo que siempre trabaja de forma remota y paralela en múltiples versiones de lanzamiento a la vez. Muy bien documentado Gracias embrague!
keithxm23

Ah, entonces aquí es donde encontré ese enlace :-) Miré varias estrategias de Git antes de configurar mi primer proyecto de Git (me he mudado de SCCS a CVS a SVN a lo largo de los años y ahora quería probar Git para un nuevo proyecto ) y este fue el que tenía más sentido para mí. Reconozco tu publicación, así que estoy bastante seguro de que es aquí donde la encontré. Así que gracias, ¡funciona maravillosamente bien!
Boise

44
Muero un poco por dentro cada vez que veo a alguien recoger esa publicación de blog. Aquí hay una refutación: barro.github.io/2016/02/…
Tim Abell

Comparto el mismo sentimiento contigo @TimAbell; Creo firmemente que no está bien cuando default master branchNO se usa con mayor frecuencia como desarrollador en estoA successful Git branching model
Nam G VU

35

(Hice mi comentario arriba es 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 maestra es desplegable
  • Para trabajar en algo nuevo, cree una ramificación con nombre descriptivo fuera del maestro (es decir: new-oauth2-scopes)
  • Comprométase con esa rama localmente y empuje regularmente su trabajo a la misma rama 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 otra persona haya revisado y firmado la función, puede fusionarla en master
  • Una vez que se fusiona y se empuja a "maestro", puede y debe desplegarse inmediatamente

Vea el artículo completo para más detalles: http://scottchacon.com/2011/08/31/github-flow.html

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


44
Con un equipo más pequeño y desarrolladores menos experimentados con git, la simplicidad de este flujo de trabajo gana. Lo único que hacemos de manera diferente es tener una rama de "puesta en escena" entre la rama de características y el maestro que actúa como un sitio de control de calidad en vivo para que los no desarrolladores autoricen la característica en un entorno similar a la producción.
Escuadrones

@Squadrons suena como si necesitaras un despliegue de pulpo para eso, que tiene compuertas incorporadas para aceptar / negar construcciones que llegan a diferentes entornos y no contamina tu control de fuente con tales cosas.
Tim Abell

Está bien crear ramificaciones de características del maestro y luego fusionarlas nuevamente para su implementación, siempre que tenga una etiqueta para que haya un punto de reversión seguro. Las implementaciones no siempre van de acuerdo al plan. Si crees en "avanzar solo" no importa mucho cuando estás sufriendo una hemorragia de dinero.
Razor

15

Use la masterrama como su rama de desarrollo y cree ramas de lanzamiento para realizar correcciones de errores.

Cualquier característica nueva continuará masterdurante la ventana de desarrollo (ya sea confirmada directamente o como rama temática con solicitudes de extracción, depende de usted, no se muestra en el gráfico). Una vez que se implementen todas las funciones planificadas, ingrese el congelamiento de funciones y realice las pruebas. Cuando estés contento, etiqueta el lanzamiento mastercomo v1.0.

Con el tiempo, sus usuarios encontrarán errores, v1.0por lo que querrá crear una rama a partir de esa etiqueta (por ejemplo, nombrarla después del lanzamiento 1.0) y corregir esos errores en la rama. Cuando hayas solucionado suficientes errores que creas que justifica una nueva versión, etiquétala como v1.0.1y únela nuevamente master.

Mientras tanto, puede estar ocurriendo una nueva ventana de desarrollo en la masterrama que eventualmente se etiquetará como v1.1.

Enjuague y repita.

Esto sigue la lógica de numeración de versiones semánticas .

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

55
No olvides fusionar tus 1.0.1cambios nuevamentemaster
kwahn

Y siempre tenga en cuenta volver a crear una base 1.1maestra después de la fusión 1.0.1, esto ayuda a minimizar la conficción.
Nam G VU

@ NamGVU No lo recomendaría. 1.1es una rama de lanzamiento y tiene etiquetas que representan el estado exacto de uno o más lanzamientos. Rebasar esa rama te haría perder esa representación. Recomiendo encarecidamente configurar sus ramas de liberación para negar los empujes forzados para evitar esto.
Leif Gruenwoldt

1
No. ¡No fusionar las ramas de liberación nuevamente en el maestro! Puede darle todo tipo de dolores de cabeza que no necesita (fusionarse en material solo de lanzamiento, fusionar conflictos con lanzamientos más recientes, romper compilaciones, historial no lineal, etc. Créame, lo he visto suceder más de una vez) . En cambio, trate los lanzamientos como tenedores. Ver bitsnbites.eu/a-stable-mainline-branching-model-for-git
m-bitsnbites

44
cherry-pick es una mejor opción para recuperar los cambios de lanzamiento en master
BartoszKP

4

En un VCS, tener solo una rama "maestra" muestra rápidamente sus límites porque no puede realizar 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 ramas que mantiene locales en sus repositorios, y ramas a las que está empujando o tirando.

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

  • prod es una rama pública de solo lectura con el código en producción. Todos podrían sacarlo para:
    • reorganizar su desarrollo actual por encima (para pruebas locales o para integrar en el repositorio de desarrollo local un hotfix realizado en el repositorio de productos en la rama de productos)
    • ramificarse para hacer nuevas funciones (de un código estable conocido)
    • rama para comenzar la próxima rama de lanzamiento (la que debe estar en producción)
      nadie debe presionar directamente para producir (por lo tanto, solo lectura)
  • Release es una rama de consolidación de lectura y escritura, donde los commits relevantes son seleccionados para ser parte de la próxima versión.
    Todos pueden presionar para liberar para actualizar la próxima versión.
    Todos pueden sacar de dicho lanzamiento para actualizar su proceso de consolidación local.
  • featureX es una rama privada de lectura y escritura (en el sentido de que no necesita ser empujada al repositorio de productos central), y puede ser empujada / extraída entre los repositorios de desarrollo. Representa un esfuerzo a medio y largo plazo, diferente del desarrollo diario.
  • master representa el desarrollo actual, y se empuja / tira entre los repositorios de desarrollo.

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


3

Lea el flujo de trabajo Git 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 asegurarse de que todo lo que pueda ser potencialmente inestable entre en algún tipo de rama. Vuelva a fusionarse con master cuando esté listo para que todos los que trabajan fuera de la rama de características lo usen.

Nota: esta estrategia no es específica de git, pero git hace que implementar esta estrategia sea bastante fácil.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.