Hola Alexander:

Gracias por tu pregunta y perdona que haya tardado tanto en responderte.

Es una buena pregunta y la respuesta depende de cómo estáis trabajando; si usáis pull request o no o si estáis usando rebase o merge, por ejemplo. Por concretar un poco, y asumiendo que utilizas merge y no trabajáis con pull requests, a mi modo de verlo tendrías dos opciones:

1. Mantener la rama hasta que sepas los resultados de las pruebas y el veredicto de QA. Si está todo OK, la borras. Si no, vuelves a la rama, haces los cambios que te piden, negreas de nuevo en develop y esperas los resultados. Vas repitiendo el proceso hasta que esté todo Ok y entonces borras la rama.
2. Cierras la rama y si tienes que hacer modificaciones, creas una nueva rama para implementarlas

Si trabajase en las condiciones que te he indicado arriba, seguramente optaría por la primera opción.

¡Un saludo!

Hola Sergio:

La respuesta a la primera pregunta es que sí. Si abres el caso 1, lo desarrollas y lo cierras. Luego abres el caso 2 lo desarrollas y lo cierras. El último commit de develop tendrá los dos casos. Tu grafo quedará parecido a esto:

..^^^^^^^^^.....^^^^^^^^^
....caso 1.......caso 2


Si luego no queremos publicar lo que se ha hecho en el caso 1, hay varias formas de proceder. Una de ellas es reaplicar con un rebase todos los commits del caso 1 sobre master y hacer lo mismo con lo del caso 2 de forma que tu repositorio quede así

development
master
o
|\o--o--o--o caso 1
|
\o--o--o--o caso 2


Una vez hecho esto, mergeas en develop solo el caso 2 y ya lo tendrías. Eso sí, si el código que has hecho en el caso 2 depende del código que está en el caso 1, no te resultará tan fácil. Por ejemplo, puede que alguna función del caso 2 dependa de una función nueva que hiciste del caso 1. En ese caso habría que hacer alguna cosa más, como reorganizar el código del caso 1 para sacar un commit que contenga sólo esa función y hacer un cherry-pick de ese commit en el caso 2. Estoy poniéndote diferentes opciones que se me ocurren te pueden servir.

Y por último, con respecto a crear features a partir de master: no habría ningún problema, los creas y cuando terminas los mergeas. Lo único es que eso ya no es «git-flow» 😉 porque te estás saltando el flujo. Si no haces ninguna cosa rara con las ramas y sólo te dedicas a hacer un caso desde master y cerrarlo, seguramente git-flow ni se entere (para él será como si hubieses hecho un hotfix).

Espero haberte ayudado.

Un saludo,

Alfonso

Nota: los puntos en los esquemas son como espacios, no consigo que el editor no los colapse…

Tengo una duda respecto al uso de gitflow, y sobre «a partir de que rama» hacer los desarrollos.

Ejemplo:
Entra el caso numero 1, partimos de develop, creamos una feature y hacemos merge a develop (todavía no lo publicamos con release, ni master…)
Entra el caso número 2 (mismo proyecto pero tematica distinta a numero 1), ¿¿si partimos de develop, no estariamos arrastrando los cambios del caso 1?? Y si luego no queremos publicar lo que se ha hecho en el caso 1, estariamos arrastrandolo, no?

¿Que inconveniente hay en crear Features siempre a partir de la rama Master para cada ticket?

Gracias, saludos.

1. una vez terminado el desarrollo de la rama feature/rama1, ¿se puede volver a crear?

2. si mi ubicacion está en la rama feature/rama1 ¿Puedo realizar un git push origin develop?

Me gustaría darte la enhorabuena por el artículo, git flow es sencillo, he leído un montón de veces sobre gitflow, pero nunca recaes en la importancia cuándo lo ves en comparación con el flujo normal, el que usamos todavía en nuestro equipo.

Desde hace tiempo, quiero implantar este flujo de trabajo en nuestro equipo, pero tengo miedo de que sea demasiada complicación dado que hay perfiles muy diferentes en el proyecto, maquetadores, desarrolladores Junior, senior… y no sé si vamos a ir hacia delante, o hacia atrás.

¿Qué nos recomiendas?

Creo además sinceramente, como bien indicas, que git flow, con un desarrollo muy medido y establecido de ante mano, puede ser muy beneficioso y organizado, pero nosotros trabajamos en 3/4 proyectos al mismo tiempo y creo que puede dar más problemas que beneficios.

Los dos comandos son equivalentes (en realidad cuando ejecutas git flow se llama a git-flow). Gracias por la aclaración.

git flow init

Dentro del proyecto Git
Saludos

¡De nada! Gracias a ti por tus comentarios. Soy organizador de un grupo de meetup en Madrid donde intentamos juntarnos una vez al mes para dar una charla. Cuando nos es posible, la grabamos, la colgamos en internet y lo pongo aquí en el blog. Si sigues el blog estarás al tanto de cualquier contenido que generemos sobre git.

Con respecto a lo del libro, no, no he escrito ninguno… pero todo se andará ;-).

Un saludo,

Alfonso

Gracias! por tu tiempo en explicarme.

Muy beno tu blog sobre git, me gustaria saber si aparte de este blog das charlas (online) sobre git, si has escrito algun libre sobre git para comprarlo! etc…
Saludos desde Panamá!

…con respecto a lo que comentas de que te crea dos ramas, eso ocurre cuando ejecutas git-flow init en un directorio que no tiene un repositorio en git. En ese caso, hace algo parecido a lo siguiente

• git-init -> git-commit
• git commit -m’Initial commit’ –allow-empty (para crear un commit sólo con un mensaje)
• git branch master
• git branch develop

Hola Murray:

Los comandos exactos no los sé, pero los puedes encontrar en el código fuente: https://github.com/nvie/gitflow/blob/develop/git-flow-init. Si echas un vistazo rápido verás que básicamente se utiliza git config. Lo que hace básicamente el comando es crear la configuración en base a las respuestas que le das.

Un saludo.

Tengo una duda… que comandos utiliza git-flow para iniciar un proyecto ?

me gustaria replicar este flujo de trabajo pero usando git normal.

al iniciar con git-flow, este me crea dos ramas (develop y master) con un commit de inicio, los dos iguales.