128 votos

Git branch estrategia para los pequeños dev team

Tenemos una aplicación web que nos actualización y liberación casi a diario. Usamos git como nuestro VCS, y nuestro actual ramificación de la estrategia es muy simple y roto: tenemos una rama master y comprobamos que los cambios que se " sienten bien acerca de'. Esto funciona, pero sólo hasta que se compruebe en un cambio de hora.

¿Alguien tiene una de las favoritas git branch estrategia 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 para aislar el trabajo de correcciones de errores y a grandes rasgos con facilidad
  4. Nos permite mantener una rama estable (para los 'oh, mierda' momentos cuando tenemos que conseguir que nuestros servidores de producción de trabajo)

Lo ideal es que me encantaría ver, paso por paso el proceso para un desarrollador trabajando en un nuevo error

153voto

Jimmy Cuadra Puntos 13499

Usted podría beneficiarse del flujo de trabajo de Scott Chacon describe en Pro Git. En este flujo de trabajo, tiene dos ramas que existen siempre, maestro y desarrollar.

el maestro representa la versión más estable de su proyecto y sólo puedes implementar la producción de esta rama.

desarrollar contiene los cambios que están en curso y no necesariamente puede estar listo para la producción.

Desde el desarrollar rama, crear tema ramas de un trabajo individual de características y correcciones. Una vez que su característica/revisión está listo para ir, que lo integrará en desarrollar, en el cual se puede comprobar cómo interactúa con otro tema ramas que sus compañeros de trabajo se han fusionado en. Una vez que se desarrollan está en un estado estable, se funden en maestro. Debe ser siempre seguro para implementar la producción de maestro.

Scott describe estos larga duración con ramas de "los silos" de código, donde el código en una forma menos estable de la rama eventualmente "graduados" a uno considera más estable después de las pruebas y la aprobación general por su equipo.

Paso a paso, su flujo de trabajo bajo este modelo podría tener este aspecto:

  1. Necesita arreglar un error.
  2. La creación de una rama llamada myfix que se basa en el desarrollar de la rama.
  3. Trabajo en el error en esta rama hasta que esté arreglado.
  4. Combinación de myfix a desarrollar. Ejecutar las pruebas.
  5. Descubre que su arreglar los conflictos con otro tema rama hisfix que su compañero de trabajo se fusionaron en desarrollar mientras estaba trabajando en su corrección.
  6. Hacer más cambios en el myfix rama de abordar estos conflictos.
  7. Combinación de myfix en desarrollar y ejecutar pruebas de nuevo.
  8. Todo funciona bien. Combinación de desarrollar en el maestro.
  9. Implementar la producción de maestro en cualquier momento, porque usted sabe que es estable.

Para más detalles sobre este flujo de trabajo, retirar la Ramificación de los flujos de trabajo capítulo en Pro Git.

31voto

Clutch Puntos 2094

Después de venir como un novato tratando de encontrar una recta de avance de la estrategia para enseñar a otros desarrolladores que no han utilizado nunca el control de código fuente. Este es uno de los que caben http://nvie.com/posts/a-successful-git-branching-model/ he intentado utilizar el estándar de GIT flujo de trabajo eso es en el hombre páginas, pero es que me confunde un poco y mi público totalmente.

Durante los últimos 6 meses sólo he tenido que arreglar los conflictos de dos veces. He añadido los pasos de probar siempre después de una combinación y de " buscar y combinar" o " pull --reajuste" un lote (una en la mañana y en la tarde), mientras que el desarrollo de las funciones. También hemos utilizado github.com como lugar central para tirar el último código.

20voto

program247365 Puntos 1203

(De hecho mi comentario anterior es propia respuesta, tal y como era al principio.)

De Scott Chacon de Github:

¿Cómo Lo Hacemos Así, ¿cuál es GitHub Flujo?

  • Nada en la rama master es implementable
  • Para trabajar en algo nuevo, crear un nombre descriptivo de la rama de master (es decir: nuevo-oauth2-ámbitos)
  • Se comprometen a que la rama local y regularmente empuje de su trabajo con el mismo nombre de la sucursal en el servidor
  • Cuando usted necesita retroalimentación o ayuda, o si usted cree que la rama está listo para la fusión, abrir un solicitud de extracción
  • Después de que alguien ha revisado y firmado en la característica, usted puede combinar en master
  • Una vez que se combinan y empujó a 'master', usted puede y debe implementar de inmediato

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

Tenga en cuenta que "pull requests" son una Github invención, y es algo que se cocía en su sitio web, no Git sí mismo: https://help.github.com/articles/using-pull-requests/

6voto

Leif Gruenwoldt Puntos 3583

El uso de la master rama de su rama de desarrollo. Ninguna de las nuevas características que ir allí durante el desarrollo de la ventana. Cuando haya terminado la implementación de sus nuevas características.k.una. función de congelación) crear una nueva rama de maestro con la versión de lanzamiento (por ejemplo, 1.0). Realizar las pruebas y la release candidate de trabajo. A partir de ese punto sólo cometer correcciones de errores para su 1.0 rama. Cuando estás feliz con él etiqueta como v1.0. Combinar la 1.0 rama de vuelta en el master (no se muestra). Con el tiempo que sus usuarios los encontrarán errores en v1.0 por lo que usted quiere corregir estos en la 1.0 rama. Cuando tienes suficiente errores corregidos que se justifica una nueva versión de la etiqueta como v1.0.1. Mientras tanto, la 1.1 desarrollo de la ventana que estaba sucediendo en la master rama. Enjuague y repita.

De esta manera se sigue Semántica de control de Versiones de numeración lógica.

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

3voto

VonC Puntos 414372

En un VCS, acabo de tener un "maestro" de la rama muestra rápidamente sus límites porque no se puede perseguir todos los esfuerzos de desarrollo, al mismo tiempo, en una rama.
Eso significa que usted necesita saber cuándo rama.

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

En este contexto, comenzar por la identificación de su desarrollo simultáneo de esfuerzo y decide, en una publicación (push/pull). Por ejemplo (y esta no es la única manera):

  • prod es de sólo-lectura pública de la rama con el código de la producción. Todo el mundo podría tirar de él con el fin de:
    • reajuste de su desarrollo actual en la parte superior (para pruebas locales, o para la integración en el local dev repo de una revisión realizada en la prod repo en el orden de producción de la rama)
    • rama para hacer nuevas características (a partir de un conocido de código estable)
    • rama para iniciar la próxima versión de la rama (el que está en producción)
      nadie debería ir directamente a la prod (de ahí el sólo lectura)
  • es una versión de lectura-escritura de consolidación de la rama, donde las pertinentes comete en palmitas a ser parte de la próxima versión.
    Todo el mundo puede presionar para liberar la actualización a la siguiente versión.
    Todo el mundo puede tirar de dicha liberación, con el fin de actualizar su local en proceso de consolidación.
  • featureX es un privado de lectura-escritura de la rama (en la que no se necesita ser el empuje a la central prod repo), y puede ser empujado/tirado entre dev repos. Representa a medio-largo plazo el esfuerzo, diferente de la cotidiana dev
  • el maestro representa el actual dev, y se empuja/tira entre el dev repos.

Otras emisiones de procesos de gestión de existir, ya que en este ASÍ que la pregunta da fe.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X