Estrategia de Git branch para pequeños equipos de desarrollo [cerrado]

Después de entrar como un novato 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 encaja 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 de manual, pero me confundió ligeramente y a mi audiencia completamente.

En los últimos 6 meses solo he tenido que solucionar conflictos dos veces. He añadido pasos para probar siempre después de una fusión y para 'fetch and merge" o 'pull reb rebase" mucho (una vez por la mañana y por la tarde) mientras desarrolla características. También utilizamos github.com como el lugar central para extraer el último código.

(Hice mi comentario arriba de 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 master es desplegable
• Para trabajar en algo nuevo, cree una rama descriptivamente nombrada fuera de master (ie: new-oauth2-scopes)
• Confírmese a esa rama localmente y envíe regularmente su trabajo a la misma rama con nombre en el servidor
• Cuando si necesita comentarios o ayuda, o si cree que la rama está lista para fusionarse, abra una pull request
• Después de que alguien más haya revisado y firmado el característica, se puede fusionar en master
• Una vez que se fusiona y se empuja a 'master', 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 "pull requests" son un Github invento, y es algo que se cuece en su sitio web, no Git en sí: https://help.github.com/articles/using-pull-requests /

Use la rama master como su rama de desarrollo y cree ramas release para realizar correcciones de errores.

Cualquier característica nueva se activará master durante la ventana de desarrollo (ya sea enviada directamente o como ramas temáticas con pull-requests, depende de usted not no se muestra en el gráfico). Una vez que se implementen todas las funciones planificadas, ingrese congelación de funciones y realice pruebas. Cuando estés contento, etiqueta el lanzamiento en master como v1.0.

Con el tiempo sus usuarios encontrarán errores en v1.0 así que querrás 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 tengas suficientes errores corregidos que creas que garantiza una nueva versión, etiquétalo como v1.0.1 y mézclalo de nuevo en master.

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

Enjuague y repita.

Esto sigue Versionado semántico lógica de numeración.

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

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

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

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

• prod es una rama 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 encima de él (para pruebas locales, o para integrar en el repositorio local dev un hotfix hecho en el repositorio prod en la rama prod)
  • rama para hacer nuevas características (desde un estable conocido código)
  • branch para iniciar la siguiente rama de release (la que va a estar en producción)
    nadie debe empujar directamente a prod (de ahí el solo lectura)
• release es una rama de consolidación de lectura-escritura, donde las confirmaciones relevantes son seleccionadas para ser parte de la próxima versión.
  Todo el mundo puede presionar para liberar para actualizar la próxima versión.
  Todo el mundo puede sacar de dicha liberación con el fin de actualizar su/su proceso de consolidación local.
• featureX es un rama privada de lectura-escritura (en la que no necesita ser push al repositorio central prod), y puede ser empujado/tirado entre repositorios dev. Representa un esfuerzo a medio y largo plazo, diferente del daily dev
• master representa al dev actual, y es empujado/tirado entre los repositorios dev.

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

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 podría ser potencialmente inestable vaya a una rama de algún tipo. Solo merge de nuevo a 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 la implementación estrategia bastante fácil.