Estoy intentado implantar en mi empresa el uso de Git Flow siguiendo las pautas que Vincent Driessen describió en su día ( http://nvie.com/posts/a-successful-git-branching-model/ ) y me surge la siguiente duda:
Si trabajamos con equipos de más de un desarrollador y repositorios remotos, ¿como hacemos las copias de seguridad de nuestras nuevas ramas de funcionalidad? Me explico:
Si tu estás desarrollando una nueva funcionalidad que tardas por ejemplo 3 días en realizarla, si quieres tener una copia de seguridad de los commits que vas realizando durante estos 3 días en tu repositorio local, ¿es una buena práctica crear esta rama también en el repositorio remoto principal o tener un repositorio remoto personal y subir esta rama a él?
A ver… Hay que usar cada cosa para lo que es. Si quieres hacer copias de seguridad, hazlas con un software de copias de seguridad. Git es un sistema de control de versiones y git-flow es un plugin que te permite usar un sistema de ramificación eficiente tal y como está ideado.
Meter en medio "una rama para copias de seguridad" no veo que sea necesario (ni creo que sea para lo que está pensado un sistema de control de versiones) ya que las ramas features tienen que publicarse para que tus compañeros puedan pullear los cambios… ahí está tu rama de copia de seguridad ya que, la ramas features, son para llevar el desarrollo de un requerimiento.
No debí explicarme bien. Lo que quería decir es si precisamente las ramas de funcionalidad se debían subir al repositorio remoto para que, a aparte de que otros desarrolladores tuvieran acceso a ellas si es necesario, tener una copia de las mismas aunque no estuviera terminada la funcionalidad.
He seguido investigando y como tu dices las ramas se deben subir al remoto.
Ah! Si, vale… Ahora te he entendido.
Sí, las ramas feature se deben "publishear" para que estén en el remoto y tus compas puedan trabajar con ella; hay un comando en git-flow para ello como bien sabrás después de investigar.
- normalmente cuando terminas una feature cuando le das al botón gitflow esta rama se hace merge con develop y se borra la rama feature (siempre y cuando tengas activa la opción)
- cuando terminas hotfix cuando le das al botón gitflow se hace merge con master y develop y se borra la rama hotfix (siempre y cuando tengas activa la opción)
aunque a veces sourcetree se hace el loco y no descarga la rama que haya creado otro usuario (sea hotfix, feature...) en ese caso yo desde terminal ejecuto
git checkout --track origin/feature/facturacion
si otra persona ha hecho merge de la rama de feature con develop, luego la puede borrar de su pc con el siguiente comando
git branch -d feature/whitelist
sobre borrar la rama en remoto no sé si te refieres a borrar la rama en un servidor de pruebas, yo prefiero tener sólo las ramas de master y develop
Estoy intentado implantar en mi empresa el uso de Git Flow siguiendo las pautas que Vincent Driessen describió en su día ( http://nvie.com/posts/a-successful-git-branching-model/ ) y me surge la siguiente duda:
Si trabajamos con equipos de más de un desarrollador y repositorios remotos, ¿como hacemos las copias de seguridad de nuestras nuevas ramas de funcionalidad? Me explico:
Si tu estás desarrollando una nueva funcionalidad que tardas por ejemplo 3 días en realizarla, si quieres tener una copia de seguridad de los commits que vas realizando durante estos 3 días en tu repositorio local, ¿es una buena práctica crear esta rama también en el repositorio remoto principal o tener un repositorio remoto personal y subir esta rama a él?
Muchas gracias.
Un saludo.
15/02/2016 18:43
A ver… Hay que usar cada cosa para lo que es. Si quieres hacer copias de seguridad, hazlas con un software de copias de seguridad. Git es un sistema de control de versiones y git-flow es un plugin que te permite usar un sistema de ramificación eficiente tal y como está ideado.
Meter en medio "una rama para copias de seguridad" no veo que sea necesario (ni creo que sea para lo que está pensado un sistema de control de versiones) ya que las ramas features tienen que publicarse para que tus compañeros puedan pullear los cambios… ahí está tu rama de copia de seguridad ya que, la ramas features, son para llevar el desarrollo de un requerimiento.
16/02/2016 10:50
No debí explicarme bien. Lo que quería decir es si precisamente las ramas de funcionalidad se debían subir al repositorio remoto para que, a aparte de que otros desarrolladores tuvieran acceso a ellas si es necesario, tener una copia de las mismas aunque no estuviera terminada la funcionalidad.
He seguido investigando y como tu dices las ramas se deben subir al remoto.
Un saludo y gracias por todo.
16/02/2016 10:53
Sí, las ramas feature se deben "publishear" para que estén en el remoto y tus compas puedan trabajar con ella; hay un comando en git-flow para ello como bien sabrás después de investigar.
De nada ;)
19/02/2016 16:54
Utilizo Sourcetree y facilita mucho el trabajo pero ahora me surge una nueva duda:
¿Las ramas de features y de hotfix se deben borrar tanto en el repositorio local como en el remoto?
Gracias
22/02/2016 18:51
yo uso cada día Sourcetree y esta genial!
- normalmente cuando terminas una feature cuando le das al botón gitflow esta rama se hace merge con develop y se borra la rama feature (siempre y cuando tengas activa la opción)
- cuando terminas hotfix cuando le das al botón gitflow se hace merge con master y develop y se borra la rama hotfix (siempre y cuando tengas activa la opción)
aunque a veces sourcetree se hace el loco y no descarga la rama que haya creado otro usuario (sea hotfix, feature...) en ese caso yo desde terminal ejecuto
git checkout --track origin/feature/facturacion
si otra persona ha hecho merge de la rama de feature con develop, luego la puede borrar de su pc con el siguiente comando
git branch -d feature/whitelist
sobre borrar la rama en remoto no sé si te refieres a borrar la rama en un servidor de pruebas, yo prefiero tener sólo las ramas de master y develop
un saludo