Momento a tí te conozco :) Qué tal ¿cómo va todo mi estimado Enrique? Para el caso que nos cuentas te creé un pequeño diagrama en esta URL: https://www.lucidchart.com/documents/view/dd7ecca2-0fab-43b8-937a-6d8e72d4a547/0 Básicamente mi recomendación es que para tu producto estable utilices un "Feature Workflow" en el cual tienes básicamente tu rama master (prod) + una de desarrollo (develop) + en tu caso si deseas agregar la de QA adelante + distintos tipos de ramas (feature, bugfix, hotfix). Algo que me llama la atención es esto "Cada que el ciclo de desarrollo alcanza la rama PRD, se considera una nueva versión mayor". En el caso que te dibujé cada que "algo" alcanza la rama "master" no necesariamente se considera una versión mayor, sino simplemetne dependiendo el tipo de "cosa" que se agregó es como se "marca" la nueva versión: Digamos que tienes semver: x.y.z Sí "x" cambia, es porque es una versión completamente nueva, seguramente con "breaking changes". Sí "y" cambia, es porque es una "nueva característica de tu producto". Sí "z" cambia, es porque se corrigió un "bug" que puede ser un "bug" que fue identificado ya sea en QA o en Producción (esto sería un hotfix, y estos son los que dan miedo que pasen porque suelen romper parte de un producto). Ahora bien, ya que tenemo sestable la rama propia de nuestro producto ¿cómo hacemos para esos "cambios especiales" pedidos por clientes específicos? Para ese caso mi opinión es que en la medida de lo posible estas "customizaciones" las traduzcan a características nuevas de su producto. Porque estoy casi seguro que acabarán en algún momento generando colisiones a nivel de código. Ahora bien si de plano NO se puede hacer lo anterior podrían usar "forks" que son básicamente repositorios completamente separados del repositorio principal, pero con la sincronización del principal hacia el fork habilitada (esto para que el cliente pueda obtener nuevas características). OJO: hay que tener cuidado que las "customizaciones" hechas para el "cliente X" porque otra vez los conflictos van a salir definitivamente, sólo hay que estar preparados. Saludos.

Hola Alex, Gracias por tu siempre objetiva respuesta. Definitivamente los forks serán de utilidad, y los conflictos deberán de ser resueltos sí o sí, no tenemos de otra de acuerdo al servicio que proveemos. Sobre mi descripción de la versión mayor en PRD, quizá no me expliqué adecuadamente. Debí haber dicho "Cada que llegue algo a PRD se considera una versión nueva", ya que puede ser major, minor, patch o incluso release candidate. Gracias por la aclaración. Saludos, espero nos veamos pronto :)

Ah muy bien, excelente no había comprendido bien eso :) ahora sí todo claro. ¿Hay que organizar algo no? Saludos.

¡Claro que sí, con gusto!