Git branch strategy for small dev team

Question

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 git branch favorito para equipos pequeños que cumple los siguientes requisitos:

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

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

Answer 1

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

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

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

Desde la rama desarrollar, crea ramas de tema para trabajar en funciones y correcciones individuales. Una vez que su función/corrección está lista para irse, la combina en desarrollando, momento en el cual puede probar cómo interactúa con otras ramas de tema en las que se han fusionado sus compañeros de trabajo. Una vez que desarrolle, establézcalo en maestro. Siempre debe ser seguro implementar en producción desde maestro.

Scott describe estas ramas de larga ejecució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, el flujo de trabajo bajo este modelo podría tener este aspecto:

1. que debe arreglar un error.
2. Crear una rama llamada myfix que se basa en la rama desarrollar.
3. Trabaja en el error en esta rama de tema hasta que se solucione.
4. Merge myfix en desarrollar. Ejecuta pruebas.
5. Descubrirá que su arreglo está en conflicto con otra rama de tema hisfix que su compañero de trabajo combinó en desarrollando mientras estaba trabajando en su solución.
6. Realice más cambios en la rama myfix para hacer frente a estos conflictos.
7. Merge myfix en desarrollan y vuelven a ejecutar las pruebas.
8. Todo funciona bien. Fusionar desarrollar en maestro.
9. Implementar en producción desde maestro en cualquier momento, porque sabe que es estable.

Para obtener más información sobre este flujo de trabajo, consulte el capítulo Branching Workflows en Pro Git.

Answer 2

En un VCS, que tiene sólo una rama "master" muestra rápidamente sus límites porque usted no puede perseguir todo el esfuerzo de desarrollo al mismo tiempo en una rama.
Eso significa que necesita saber when to branch.

Pero en un DVCS (como en "descentralizada" VCS), también tiene un publication issue, con ramas a mantener a los repositorios locales, y las ramas que están empujando o tirando de.

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

• prod es una sucursal pública de solo lectura con el código en producción. Todo el mundo podría tirar de ella con el fin de:
  • rebase su desarrollo actual en la parte superior de la misma (para pruebas locales, o para la integración en el dev local de Repo una revisión realizada en el repositorio prod en la rama prod)
  • rama para hacer nuevas características (de un código estable conocido)
  • rama para iniciar la siguiente rama liberación (la que es estar en producción)
    nadie debe empujar directamente para empujar (de ahí el de sólo lectura)
• versión es una rama de consolidación de lectura-escritura, donde el relev Ant commits son escogidos para ser parte de la próxima versión.
  Todos pueden presionar para liberar para actualizar la próxima versión.
  Todos pueden obtener de dicha versión 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 hacia el almacén central de prod), y puede ser empujada/tirada entre dev repos. Representa un esfuerzo de mediano a largo plazo, diferente del dev diario
• maestro representa el desarrollador actual, y se empuja/tira entre los repos de dev.

Existen otros procesos de gestión de versiones, como este SO question attests.

Answer 3

leer a través de Reinh Git flujo de trabajo para equipos ágiles aquí: http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

Esto funciona muy bien para los 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 lo usen.

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

Answer 4

Después de venir como un principiante tratando de encontrar una estrategia directa para enseñar a otros desarrolladores que nunca han utilizado el control de código 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 en las páginas man, pero me confundió un poco y mi público 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 combinación y para 'buscar y combinar' 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.

Answer 5

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

Cualquier nueva característica funcionará en master durante la ventana de desarrollo (ya sea directamente o como ramas de tema con solicitudes de extracción, depende 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 master como v1.0.

Con el tiempo, los usuarios encontrarán errores en v1.0, por lo que querrá crear una bifurcación a partir de esa etiqueta (por ejemplo, nombrarla después del lanzamiento 1.0) y corregir esos errores en la sucursal. Cuando haya reparado suficientes errores que cree que merecen una nueva versión, márquelo como v1.0.1 y vuelva a fusionarlo en master.

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

Enjuague & repetir.

Sigue la lógica de numeración Semantic Versioning.

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

Answer 6

(Hecho mi comment por encima de su propia respuesta, como debería haberlo hecho al principio.)

partir de Scott Chacon de Github:

Cómo lo hacemos así, cuál es GitHub Flow?

• Cualquier cosa en la rama principal es desplegable
• para trabajar en algo nuevo, crear una rama con nombres descriptivos fuera del maestro (es decir: nueva OAuth2-alcances)
• Commit a esa rama a nivel local y regularmente empujar a su trabajo a la misma rama llamada en el servidor
• Cuando necesite retroalimentación o ayuda, o si piensa que la rama está listo para la fusión, abra una solicitud tirón
• Después de que alguien más ha revisado y firmado en la función , puede combinar en maestro
• Una vez que se fusionó y empujó a 'maestro', que puede y debe implementar inmediatamente

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

tenga en cuenta que "tirar de las solicitudes" son un invento Github, y es algo que se cuece en su sitio web, no Git sí: https://help.github.com/articles/using-pull-requests/