Mi media center - Foro

Ya comente una vez q para mi lo mejor es gitflow (y casi me sacan los ojos ).
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.

¿Que ventajas tiene esto? La rama master contiene en todo momento el codigo de la ultima version distribuida (convenientemente etiquetada) mas las correcciones de los canales y servers (para q puedan ser actualizadas automaticamente). Los experimentos los hacemos sobre ramas hijas de develop, lo q nos proporciona seguridad en caso de liarla parda y nos deja la rama master limpia. Por ejemplo, ahora mismo para probar mi version y la de divadr del updater si ambas estan en ramas separadar, es muy facil cambiar de una rama a otra ir haciendo correcciones paralelamente y finalmente descartar la q menos apoyos tenga (doy por hecho q es la mia, hasta yo la he abandonado )

Me parece bien, una vez hecho un par de veces se le pilla el truco, el que va a tener que coger apuntes es Jesús

Lo he leído media docena de veces y después de un rato parece tener todo el sentido del mundo

A mí lo de los branches me da cosa porque vengo de Subversion, pero empiezo a asimilar que Git va por otro sitio.

Vamos, que casi me has convencido ja ja ja

Déjame que lo medite con la almohada y estudie un poco.

¿Esto es ese Gitflow tuyo o una versión simplificada?

He creado los dos branches para probar a ver qué tal funciona:

https://github.com/tvalacarta/pelisalacarta/branches

Voy a ir preparando para subir en developer.

P.D: puedes borrar dos ramas antiguas "revert-79-auto-update" y "revert-41-hotfix_actualizacion_newpct1"

¿Puedo? ¿No se prenderá fuego Github y se volatizará como la estrella de la muerte?

No entiendo qué pintan ahí...

jesus escribió:¿Esto es ese Gitflow tuyo o una versión simplificada?

Jejejeje ojala fuera yo el inventor de Gitflow o de algo parecido

Lo q propongo es uns version manual y reducida de gitflow (reducida por q no uso la rama release, y por q hago los merges a dos ramas en pasos separados: primero a una pruebo y despues mergeo a la otra)

Como siempre os recomiendo mi web de cabecera para estos temas: AprendeGit.com
En concreto os recomiendo una serie de articulos muy clarificadores:

• ¿que es git-flow?
• Instalacion Aunque aqui aconsejo usar Sourcetree como herramienta visual para trabajar con git y gitflow
• la rama develop y uso de feature branches
• release branches
• hotfix branches

A ver si me voy a pasar de listo... esas ramas las creó automaticamente github, cuando hiciste revert del PB 41 y 79.

super_berny escribió:

jesus escribió:¿Esto es ese Gitflow tuyo o una versión simplificada?

Jejejeje ojala fuera yo el inventor de Gitflow o de algo parecido

Lo q propongo es uns version manual y reducida de gitflow (reducida por q no uso la rama release, y por q hago los merges a dos ramas en pasos separados: primero a una pruebo y despues mergeo a la otra)

Como siempre os recomiendo mi web de cabecera para estos temas: AprendeGit.com
En concreto os recomiendo una serie de articulos muy clarificadores:

• ¿que es git-flow?
• Instalacion Aunque aqui aconsejo usar Sourcetree como herramienta visual para trabajar con git y gitflow
• la rama develop y uso de feature branches
• release branches
• hotfix branches

Una cosa que me has recordado, estaría bien una vez que empecemos a funcionar, sacar un minituto para jubilar el post fijo del SVN a hacer referencia a GitHub

¿Usais algun IDE para programar en python?

SeiTaN escribió:A ver si me voy a pasar de listo... esas ramas las creó automaticamente github, cuando hiciste revert del PB 41 y 79.

Ya las he borrado.

A partir de ahí ya te apañas tú con el dios de Github ja ja ja