).Si no se quiere utilizar un flujo de trabajo tan marcado, propongo:
- Cuando saques la version 4.0.5 añades un tag en la rama master en ese punto (es solo una etiqueta identificativa)
- Creas dos ramas a partir de master: hotfix y develop
- Cuando alguien corrija un canal (o server) por que habia dejado de funcionar, debe enviar el pull-request sobre la rama hotfix. Jesus debe aprobar el pull-request mergeandolo sobre la rama develop para probarlo, y cuando se este seguro de q el canal funciona se mergea desde hotfix a master
- Cuando alguien implemente una nueva funcion o un canal q necesite modificar algo del codigo (launcher, xbmctools, etc...) debera enviar pull-request a develop. Jesus creara una nueva rama desde develop (por ejemplo: newFeature#87) y mergeara ahi los nuevos cambios. Situando el puntero de git sobre esa rama se puede hacer todas las pruebas necesarias, si no funciona (o no convence) se deja la rama abierta (para posibles correcciones) o se elimina (por descartarse la funcionalidad) volviendo al punto de develop anterior (asi no es necesario deshacer cambios). Si se acepta la nueva funcion se mergea contra la rama develop y se elimina newFeature#87.
- Cuando se quiera publicar una nueva version se traen todos los cambios (merge) desde develop a master y se etiqueta nuevamente.
)
