Existen diversas posibilidades a la hora de armar la estructura de un repositorio de código. La elección de una u otra depende de diversos factores como ser: el tamaño del equipo, la forma de trabajo, la frecuencia de despliegue de la aplicación etc.
Quiero compartir dos estructuras posibles con las que he trabajado.
Estructura minimalista para Continuous Delivery
Contexto:
- Tu aplicación es «standalone», en el sentido que tiene mínimas dependencias con aplicaciones externas
- Tu equipo de desarrollo es chico (menos de 4 programadores)
- Cuando debes agregar cambios/nuevas funcionalidades lo haces en pequeños incrementos
- Cuentas con un alto porcentaje de cobertura
- La regresión manual (en que caso que la necesites) te lleva menos de 30 minutos
Si se dan los puntos anteriores, entonces puedes ir fácilmente a un contexto de Continuous Delivery para lo cual recomiendo una estructura de repositorio basada en dos branches permanentes:
- Develop: es el branch sobre el que se hace el desarrollo
- Master: es el branch que contiene lo que se encuentra en producción
Cuando se está desarrollando una nueva funcionalidad, se va commiteando a develop. Cuando dicha funcionalidad está completa y ha sido vista por el responsable de producto en el ambiente de tests, entonces, dicha funcionalidad es mergeada en master y desplegada al ambiente productivo.
En caso de detectarse un error en producción, se crea un branch temporal (hot-fix) para desarrollar el fix que una vez completo es mergeado en master y develop.
Estoy asumiendo un ecosistema de trabajo que cuenta con un ambiente desarrollo (máquina del developer), una ambiente de tests (similar al de producción) y un ambiente de producción.
Estructura tradicional para desarrollo iterativo
Contexto:
- Trabajas en un esquema iterativo con salidas a producción programadas en cada X días/semanas
- Tu aplicación depende de otras aplicaciones/servicios externos
- Tu equipo de desarrollo no es tan chico (más de 4 desarrolladores)
- No tienes una buena cobertura, lo cual te lleva a ejecutar regresiones que llevan horas
En este caso también tendremos los 3 branches mencionados anteriormente (develop, master y hot-fixes temporales) pero adicionalmente tendremos otros branches:
- Feature branch: cada funcionalidad es desarrollada en un branch aparte que luego es mergeado a develop
- Release branch: es este branch se van a acumulando las funcionalidades listas para pasaje a producción. Puntualmente se hace un merge de develop a release branch
Este esquema es conocido como GitFlow y tiene cierta popularidad en el mundo Git, pero a pesar de ello es posible utilizarlo con otro controladores de versiones.
Blog de NicoPaez 
Nico… en un mundo con clientes que tienen que testear el producto no alcanza con este esquema de branches o no está bien explicado, tampoco cuando hay funcionalidad que tiene que esperar para salir a producción y lo tenés en develop.
Lo que gralmente se utiliza es el merge entre los features branches con los repos (develop/release). De esta forma cada feature puede llegar a producción sin necesidad de esperar que todo esté listo para llegar a este estado.
Mis 2 centavos
Hola Juan! en mi mundo los clientes testean y en particular en mis proyectos adicionalmente suelo tener un alto porcentaje de prueba automatizada y con este esquema a mi y a algunos otros que conozco nos alcanza. Tal vez en tu contexto no sea suficiente y te lleve a tener esquemas más complejos, pero el hecho de que en tu contexto no sea suficiente no implica que en otro contexto no pueda funcionar. Tu comentarios pareciera un decir «a mi no me sirve entonces no sirve para nadie».
Por otro lado no termino de entender tu comentario sobre la funcionalidad que tiene que esperar para salir a producción. En un esquema de continuous delivery, ninguna funcionalidad espera a otra (a menos que haya una dependencia). Como indico en el post (tal vez no lo suficientemente claro) es que cada funcionalidad se desarrolla en su propio branch, eso hace que develop este siempre tenga funcionalidad completas para ser desplegadas (pero tal vez no liberadas) al ambiente que se necesite. Lo que es necesario tener en cuenta es la diferenciación entre entre despliegue y liberación de funcionalidad. Utilizando técnicas como feature toggling uno puede desplegar la funcionalidad apenas esté terminada pero sin liberarla para uso de los usuarios, o sea, la vas a mantener «apagada» hasta que el negocio considere conveniente liberarla.
Gracias por el aporte, saludos!