remota - git con ramas de desarrollo, puesta en escena y producción
git push (5)
Este artículo parece interesante, pero estoy bastante seguro de que los diagramas son incorrectos. http://guides.beanstalkapp.com/version-control/branching-best-practices.html
¿No debería ser DEVELOPMENT > STAGING > PRODUCTION ?
Las fusiones solo deben fluir en una dirección: desde correcciones de funciones y errores realizadas en su propia rama o en desarrollo hasta la puesta en escena para la prueba. Una vez probado, puede fusionar esos cambios del desarrollo a la producción.
Aquí me confundo un poco. ¿Así que fusiono la Etapa con el Maestro o el Maestro con la Etapa?
Estoy usando un cliente llamado SmartGit y me confundo sobre este punto. Normalmente hago una rama para una característica, me comprometo con ella, luego cambio a la maestra y la fusiono a la rama (adelante). Entonces, en este nuevo flujo de trabajo con etapas y producción, creo estas dos ramas adicionales y luego creo una rama desde el maestro (también conocido como dev) para mi función. ¿Comprometerse con esto, luego cambiar a la Etapa y fusionar (reenviar) a mi rama de características? ¿Eso suena correcto?
En realidad, lo que hizo que esto fuera tan confuso es que la gente de Beanstalk está detrás de su uso no estándar de estadificación (¡viene antes del desarrollo en su diagrama, y no es un error! https://twitter.com/Beanstalkapp/status/306129447885631488
Han decidido olvidarse de Beanstalk y solo con Github.
Desde que publiqué esto, la gente de Beanstalk tomó mi pista y renombró sus etapas, ahora llamando a Desarrollo "Estable".
De una publicación en mi blog :
El flujo de trabajo "gitflow" de nvie tiene dos problemas: confusamente cambia el significado de la rama "principal" y no justifica claramente el costo de una rama adicional de larga duración. Ambos problemas podrían resolverse por [...]
El proceso de pensamiento aquí es que pasas la mayor parte de tu tiempo en el development . Cuando está en desarrollo, crea una rama de feature (fuera del development ), completa la función y luego vuelve a fusionarse en el development . Esto luego puede agregarse a la versión final de producción al fusionarse en production .
Vea Un modelo exitoso de ramificación de Git para obtener más detalles sobre este enfoque.
En realidad, lo que hizo que esto fuera tan confuso es que la gente de Beanstalk respalda su uso no estándar de estadificación (¡viene antes del desarrollo en su diagrama, y no es un error!
Lo hacemos de manera diferente En mi humilde opinión lo hacemos de una manera más fácil: en el master estamos trabajando en la próxima versión principal.
Cada característica más grande obtiene su propia rama (derivada del maestro) y el desarrollador la volverá a basar (+ fuerza presionada) en la parte superior del maestro. Rebase solo funciona bien si un solo desarrollador trabaja en esta característica. Si la función está terminada, se actualizará nuevamente en el maestro y luego el maestro reenviará rápidamente a la última función confirmada.
Para evitar el empuje de rebasado / forzado, también se pueden fusionar los cambios maestros regularmente a la rama de características y, si está terminado, fusionar la rama de características en maestra (fusión normal o combinación de squash). Pero en mi humilde opinión, esto hace que la rama de funciones sea menos clara y hace que sea mucho más difícil reordenar / limpiar las confirmaciones.
Si viene una nueva versión, creamos una rama lateral fuera de la maestra, por ejemplo, release-5 donde solo se corrigen los errores.
Una de las mejores cosas de git es que puedes cambiar el flujo de trabajo que funcione mejor para ti. Sí uso http://nvie.com/posts/a-successful-git-branching-model/ la mayoría de las veces, pero puede usar cualquier flujo de trabajo que se ajuste a sus necesidades