Este artículo parece interesante, pero estoy bastante seguro de que los diagramas son erróneos. http://guides.beanstalkapp.com/version-control/branching-best-practices.html
¿No debería ser "DESARROLLO" > "ESTRATEGIA" > "PRODUCCIÓN"?
Las fusiones sólo deben fluir en una dirección: de las características y correcciones de errores realizadas en su propia rama o en desarrollo hacia staging para pruebas. Una vez probados, puedes fusionar los cambios de desarrollo a producción. producción.
Aquí me confundo un poco. ¿Así que fusiono Staging a Master o Master a Staging?
Estoy usando un cliente llamado SmartGit y me confundo acerca de este punto. Normalmente hago una rama para una característica, hago commit en ella, luego cambio a master y hago merge a la rama (forward). Así que en este nuevo flujo de trabajo con la puesta en escena y producción, creo estas dos ramas adicionales, a continuación, crear una rama de maestro (también conocido como dev) para mi función. Confirmar a ella, a continuación, cambiar a la puesta en escena y la fusión (hacia adelante) a mi rama característica? ¿Es correcto?
En realidad, lo que hace que esto sea tan confuso es que la gente de Beanstalk respalda su uso no estándar de Staging (viene antes que development en su diagrama, ¡y no es un error! https://twitter.com/Beanstalkapp/status/306129447885631488
He decidido olvidarme de Beanstalk y sólo con Github.
Desde que publiqué esto, la gente de Beanstalk tomó mi indirecta y renombró sus etapas, ahora llamando a Desarrollo "Estable".
El proceso de pensamiento aquí es que usted pasa la mayor parte de su tiempo en "desarrollo". Cuando estás en desarrollo, creas una rama de característica
(fuera de desarrollo
), completas la característica, y luego la fusionas de nuevo en desarrollo
. Esto puede entonces ser añadido a la versión final de producción mediante la fusión en "producción".
Ver A Successful Git Branching Model para más detalles sobre este enfoque.
Nosotros lo hacemos de otra manera. IMHO lo hacemos de una manera más fácil: en master
estamos trabajando en la próxima versión mayor.
Cada característica mayor tiene su propia rama (derivada de master) y será rebasada (+ force pushed) sobre master regularmente por el desarrollador. Rebasar sólo funciona bien si un solo desarrollador trabaja en esta característica. Si la característica está terminada, será recién rebasada sobre master y luego el master será fast-forwarded al último commit de la característica.
Para evitar el rebasing/forced push también se pueden fusionar los cambios de master regularmente a la rama de la característica y si está terminada fusionar la rama de la característica a master (fusión normal o squash merge). Pero IMHO esto hace la rama de características menos clara y hace mucho más difícil reordenar/limpiar los commits.
Si se va a publicar una nueva versión, creamos una rama lateral fuera de master, por ejemplo release-5
donde sólo se corrigen los errores.
una de las mejores cosas de git es que puedes cambiar el flujo de trabajo que mejor te funcione.. Yo uso http://nvie.com/posts/a-successful-git-branching-model/ la mayor parte del tiempo, pero usted puede utilizar cualquier flujo de trabajo que se adapte a sus necesidades