Este es un problema difícil pero que muchas personas enfrentan. Prefiero usar la configuración de Gitflow como punto de partida.
Desarrollo - > Nuevas cosas que se están trabajando en
Maestro - > Cosas terminadas que necesitan pruebas
Producción - > Material que ha sido publicado en producción.
En las funciones menores (más cortas) creo una rama desde el desarrollo, haga el trabajo allí y luego fusione la rama nuevamente con el desarrollo.
En las funciones principales (a largo plazo) creo una rama desde el desarrollo, creo ramas más pequeñas a partir de esa rama y luego vuelvo a la primera rama. Una vez que se ha completado la característica principal, se vuelve a la rama de desarrollo.
A intervalos regulares (depende del proyecto) fusiono el desarrollo con el maestro y comienza un ciclo de prueba. Si surgen algunos arreglos en las pruebas, se realizan en la rama maestra (la rama secundaria luego se fusiona). Y el desarrollo puede continuar en la rama maestra durante las pruebas.
En cualquier momento, el maestro debe fusionarse con el desarrollo, y el desarrollo debe fusionarse con cualquiera de sus subdivisiones a largo plazo.
el maestro siempre debe (en teoría) estar listo para la producción. El desarrollo siempre debe (en teoría) estar listo para la producción. La única razón por la que hay una diferencia es proporcionar un conjunto sólido de características para que los probadores las prueben.
Cuando está listo, una confirmación en el maestro que se prueba se fusiona con la producción y el despliegue en la producción se realiza desde esa rama. Los HOTFIX que deben hacerse en caso de emergencia pueden tener lugar en la rama de producción sin tener que fusionarse en el maestro (que puede tener muchos cambios sin probar).
Mi árbol normal se ve como
LongTerm -> Development -> Master -> Production
LongTerm <- Development | |
| Development -> Master |
LongTerm <- Development -> Master |
Development <- Master |
Master -> Production
Es mi regla general que ningún cambio debe durar más de unas pocas horas. Si lo hace, entonces debe hacerse en cambios más pequeños. Si es una característica enorme (como una reescritura de la interfaz de usuario), eso va a largo plazo para que el desarrollo normal pueda continuar al mismo tiempo. Las sucursales a largo plazo normalmente son solo sucursales locales, mientras que Desarrollo, Máster y Producción son sucursales remotas. Las sucursales secundarias son también locales solamente. Esto mantiene el repositorio limpio para otros, sin perder la utilidad de git en un conjunto de características a largo plazo.
Me gustaría señalar, sin embargo, que la existencia de una rama a largo plazo es una cosa rara. Normalmente, todo mi trabajo está en desarrollo. Solo cuando tengo una característica (conjunto) que va a llevar tanto tiempo que necesito poder trabajar en cosas de desarrollo normal también, uso la rama de largo plazo. Si es solo un conjunto de cambios que deberían estar juntos, entonces no me fusiono para dominar hasta que no haya terminado.