Librebits - jordila_@i-ching:~/

Bits aleatorios de Software Libre / Libre Software ...

Git: Un Sencillo Flujo De Trabajo (Workflow) II

Hace un tiempo, compartíamos un sencillo flujo de trabajo Git, para pequeños proyectos. Bien retomando el hilo…

Parecía que ya empezamos a manejar el sistema de control de versiones Git , en sus tres comandos básicos…

1
2
3
4
5
$ git  add .
  
$ git commit -m "blabla"

$ git push  ...

y ahora empezamos a tratar de ordenar un poco nuestra forma de desarrollo con git

Es fundamental, para sacar el máximo provecho a Git organizar el flujo de trabajo (‘workflow’), adaptándolo a nuestras necesidades.

  • mediante el uso ramas (‘branch’)

  • desarrollando estructura de árbol de desarrollo simple y flexible a la vez

  • uso de Tags o etiquetas para versionado…

  • … y mucho más

En mi caso, decía, es bien sencillo, uso dos ramas :

  • master // que contiene el código ‘estable’ , se actualiza con menos frecuencia

  • developement // código en desarrollo, actualizándola con mayor frecuencia

y eventualmente una tercera :

  • myfeature // que deriva de developement, donde transcurre el (micro)desarrollo

que aparece y desaparece… según la necesidad. La borro con frecuencia de una vez, tras hacer merge a ‘developement’. Veamos :

  • terminé el microdesarrollo en la rama myfeature actual y lo incorporo ( merge ) a master

  • la idea-microdesarrollo resultó que no era acertada… , marchá atrás.

Este simple paso de deshacer lo andado … nos facilita saltar con red y una libertad absoluta en las ideas a desarrollar. Sabemos que en el rama developement de vuelta, por muchos ensayos y errores que cometamos, nos espera el último estado del código funcionando exactamente como lo dejamos. Siempre y cuando respetemos el flujo de trabajo. Obviamente.

Así pues, por ejemplo, quiero desarrollar la cabecera (Header de mi página web). Partiendo de la rama master actual, recién iniciado el repositorio Git.

1
2
3
4
\\inicio el repositorio , con la rama master por defecto
$ git init
\\creo la rama developement -b , a la cual cambio : 'checkout'
$ git checkout -b developement

…en este punto, decido aventurarme a crear una cabecera de página más innovadora , pero no quiero perder lo hecho hasta ahora. Ello transcurrirá en una nueva rama, derivada de la desarrollo :

1
2
\\creo la rama que deriva de la de _developement_ _-b_ , a la cual cambio : _checkout_
$ git checkout -b micabecera

Acá realizó, con red todas la pruebas que quiera ! Una vez satisfecho con los resultados, si decido fundirlos con mi estado actual de desarrollo, tan sencillo como :

1
2
3
4
5
6
7
8
\\de vuelta a la rama 'developement' , a la cual cambio con  'checkout'
$ git checkout developement
\\ 'merge' sin fast-forward:  'fundo' los cambios hechos en la rama 'micabecera' de la que provengo, conservando el 'histórico'
$ git merge --no-ff micabecera
\\ elimino la rama que acabo de fundir en la rama 'developement', pues ya no la necesito más...
$ git branch -d micabecera
\\ en caso de tener configurado el repositorio remoto, en Github por ejemplo
$ git push origin developement

Así hemos incorporado los cambios que realizamos en micabecera a la rama de desarrollo. En local y en remoto.

En un futuro post hablaremos de incluir la rama master en el proceso, y de una forma sencilla de publicar mediante ella el desarrollo actual en nuestro servidor web.

KISS : Keep-it-simple-stupid

Fuentes :

Thanks nvie y DrupalCamp ES

Bonus:

// para hacer ‘push’ de todo el árbol (y sus ramas) de trabajo, sin distinción

1
$ git push --all -u

en un workflow sencillo como este,y así no hay que precuparse de concretar la rama, ni de saber en la que estamos, bla…