lunes, 9 de diciembre de 2013

Construcción de un CPO Arcade SteamPunk



Una de las cosas que más me intrigaba era poder tener mi propia máquina recreativa, jugar a los juegos de antaño, PAC-MAN, Galaxian, Galaga, etc..

Así , que decidido empiezo a mirar Webs, y en una de tantas, me llama la atención http://zonaarcade.forumcommunity.net/ donde el usuario MiKonos, y otros usuarios, han colgado gran cantidad de material, donde puedes construir por ti mismo.

Lo primero que hice, comprar un tablero MDF 60x30. ¿ La medida ?, pues es lo que ví, no me planteé , solo gasté 2.30€

Armado con una regla de 30cms, se la cogí a mi hija ;-), un tapón de CocaCola, hacerlo con el compás era demasiado tedioso.

He aquí el resultado;

No importa si el diámetro de la rosca es de 28 , 30 o 25, es solo un boceto de como quedaría. Lo único importante es la broca a usar, la del 28 para todos, excepto los 4 botones iluminados usados como servicios del 24 .

Después me dediqué a buscar un fondo para mi CPO. Gastarme pasta en un vinilo no era posible, el tener que comprar aparte del material , las herramientas para hacerlo, redujo mucho el presupuesto. Así que me bajé un programa llamado poster, como es multiplataforma, lo arranque en mi GNU/Linux, y le di las medidas de 60x30, y me imprimió 6 hojas.

Con paciencia y una tijera, recorté y los dispuse para ver como quedaría, y la verdad es que la Xerox Phaser 6000B que compré por 80€ no queda tan mal ;



Bien, a continuación quedaba hacer los agujeros al tablero MDF. He de decir que trabajar con el MDF en vez del un aglomerado se agradece.
Los agujeros se hicieron con broca de pala, quedando PERFECTO.





Terminado los agujeros , mostramos como quedaría el mando colocado. Para ello lo que he realizado es usar tornillos de rosca de 6x40mm para cogerlo todo bien fuerte, es que con el mando venian unos tornillos para agarrar por detrás, pero seguramente con un movimiento del Street Fighter, me quedaría con el mando en la mando. Así que les hice un avellanado para que se metiera el tornillo dentro de la madera.



Después , solo quedaba ver como quedaría haciendo una simulación con los botones;



Para cortar el metacrilato, lo ponemos junto con el tablero con los agujeros, y una tabla por debajo, haciendo un sanwdich. Lo cogemos con un par de  sargentos y con la misma broca de pala, hacemos los agujeros.
Para cortarlo , si la pieza del metacrilatro es más grande, con una caladora con sierra de metal funciona perfectamente.

Este es el aspecto ;



Ahora solo queda poner la tabla, la impresión y encima el metacrilato, y con un cutter o similar, recortar el papel.

Colocamos los botones, y montamos la palanca de mandos. He de decir que no he usado nada para agarrar el metacrilato con la madera, los mismos botones lo mantiene pegado. Este es el aspecto final;




Ahora, que hemos terminado con el uso del taladro y demás máquinas, nos liamos con la electrónica.

Aquí les dejo unas fotos de la torreta de conexiones , al puerto paralelo;



Aquí buscamos los pines con el tester;





Y la última foto , la torreta lista para conexión ;-)
Dando la vuelta al CPO, vemos como es por debajo;




Aqui empezamos ya a puntear la palanca y los botones ;



Y el resultado final, una maraña de cables, pero todos muy bien localizados ;




Después , viene la instalación del PPJOY , el driver para usar el CPO como un joystick. Es curioso , con el Windows 2000, los ejes Y estaban bien, con el Windows XP, el arriba era el abajo y abajo arriba. Si ocurre eso, la solución no es cambiar los cables, que también, si no, engañar al driver a la hora del mapping , diciendo que arriba es abajo y abajo es arriba ;-)

Bueno, despues de todo , vamos a disfrutar como va ;





sábado, 16 de noviembre de 2013

Ficheros perdidos en el Stash. The lost file in the Stash



Hoy en la oficina hemos simulado un caso donde nuestro querido Yeradis, vino con un problema con el stash, donde "mágicamente" desaparecieron los ficheros que intentaba subir a git.

Yeradis siempre te abre un mundo donde las cosas ocurren  de una manera un tanto especial.

Y si, de verdad que desaparecen. Y tiene su lógica, aunque a priori, parece una incongruencia, profundizando , observaremos que el funcionamiento es el adecuado.

Vamos a realizar todos los pasos, porque son muy sencillos replicarlos en un simple directorio.
Creamos un directorio y nos colocamos y ejecutamos;

$ git init
$ touch readme
$ git commit -am "prueba"

Bien, tenemos ya nuestro primer commit en el repositorio local.
Ahora vamos a crear otro fichero, pero lo meteremos en el stash.



Bien, el fichero noseve.txt, efectivamente no se ve.
Si aplicamos $ git stash pop, volvería a parecer, borrando el stash, teniendo el fichero en cuestión.

Ahora bien, cuando usamos "herramientas visuales", a veces las facilidades nos causan destrozos, como por ejemplo, desde SourceTree, y le damos a "borrar" el stash. ¿ Donde está fichero ?

Ya no se puede recuperar. Porque no hay nada. El fichero noseve.txt, al estar en el stash, y borrar el stash, no podemos recuperarlo.

Para simularlo desde la consola, vamos a eliminar la pila del stash, borrando el contenido.
$git stash drop stash@{0}
Dropped stash@{0} (41fd10ece492b8f2f4911af2522bbf60b66ed789)

Horror! GIT ELIMINA FICHEROS SIN AVISAR!! ( mode yeradis )

Hay que ser piltrafilla ;-)

Como se ha realizado un movimiento, bueno, en este caso 2 movimientos, uno es dejarlo en el index, y el otro moverlo al stash, podemos seguir su rastro con este comando;
git fsck --unreachable | grep commit


Esto nos va a mostrar los sha1 , el del index y el del stash.
Y si tenemos el sha1, tenemos los ficheros ;-)

Creamos una rama para ubicarlos temporalmente o hacer un merge en la rama actual;
git checkout -b rama_test 41fd10ece492b8f2f4911af2522bbf60b66ed789
git merge 41fd10ece492b8f2f4911af2522bbf60b66ed789

Ahora, si miras los ficheros, verás que aparece por ahí el noseve.txt. ;-)




















Cada día que pasa, más me gusta Git.

miércoles, 6 de noviembre de 2013

Git. Creando un Custom Action.


Una de las cosas que más uso en GIT, es la combinación de mirar diferencias entre diversas ramas y comprobar si en la rama donde estoy actual, necesito hacer un refactor de una rama a otra.

No, no puede fusionarlas, porque son paralelas, y algunas cosas que están de una manera , en otra se hacen de otra, por lo tanto, "master" hay más de una.

Entonces, era muy fácil coger el hash sobre el cual quiero mirar un archivo en concreto.

Por ejemplo:

git difftool 23dc453a stdio.h

Esto hace que se nos abre nuestro comparador , y podamos comparar contra el commit 23dc453a y modificar nuestro fichero stdio.h 

Si esto lo hacemos desde SourceTree , con External Diff, tenemos el inconveniente que siempre lo hace contra 2 ficheros temporal. Eso es una faena, porque por mucho que adaptemos el código, ese stdio.h es una copia del original.

Ahora con los "Custom Action" de SourceTree, podemos crear el comando adecuado que haga lo que nos interesa.

Primero, vamos a explicar que tenemos un problema, y es que el $SHA, nos esta devolviendo los 2 hash de los commit seleccionados en SourceTree.
Entonces, no podemos hacerlo directamente. 

Lo que haremos es crear un diff.bat, que va a contener lo siguiente;

git difftool %1 %3


Lo único que falta es crear el comando como esta imagen.



miércoles, 30 de octubre de 2013

Nuevo SourceTree 1.3


Atlassian, creadora de SourceTree , ha añadido un par de cosas en esta versión que está bastante bien.

En el "Repository Settings" podemos definir la ruta hacia nuestro proyecto del JIRA:

Con esto, nos permite , que cuando hacemos un commit, y en el mensaje indicamos la incidencia de JIRA,
podemos consultarla directamente haciendo click en el mensaje del log;


Si hacemos click en el enlace HOTELSHARBOUR-40, saltaremos directamente a la incidencia abierta;


También podemos observar en la incidencia , a través de git plugin , ver los cambios en el código que se ha realizado, solo cuesta 10$ para 10 usuarios, y es simple y efectivo.
Nosotros lo tenemos configurado para trabajar contra GitBlit , y va de fábula.

Y los "Customs actions", que nos permite definir en nuestro menú contextual una serie de acciones , por ejemplo;


jueves, 24 de octubre de 2013

Conflictos en GIT

A veces , cuando actualizamos un repositorio remoto, suele ocurrir que hay un fichero que entra en conflicto , pero no nos interesa hacer una fusión, si no , simplemente seleccionar nuestro fichero o el fichero del repositorio remoto.

Cuando ocurre esto, podemos fácilmente resolverlo como la siguiente imagen;

viernes, 4 de octubre de 2013

The Man of Eath.

Señores, estamos ante una de las mejores películas de ciencia ficción de todos los tiempos.

Pero lo bueno, es que no verás ni una nave espacial volar, ni viajes en el tiempo, ni presupuestos de 200 millones de dolares, ni tan siguiera se ha puesto en el cine ni televisión.

Es más, finalmente su coste es de 56.000 dolares, pero no te dejes engañar, esta es una película de culto.


Solo una pista;
La película cuenta la historia de John Oldman, un profesor de universidad que asegura ser en realidad un hombre de Cro-Magnon de 14000 años de edad que sobrevive hasta nuestros días


Trailer; ( En English )



Wikipedia

viernes, 23 de agosto de 2013

GIT RESET. Viaje en el tiempo local.

Como en los viajes en el tiempo, con git podemos fácilmente ir hacia atrás.

Ahora bien, hay que estar preparado , porque tenemos diversas forma de saltar al pasado, y dependiendo del combustible que usamos, realizará una u otra cosa :-)

Recordad que git reset se usa para nuestro repositorio local, y sobre commits que no están en un repositorio remoto. En este caso, HEAD~1 indica que saltamos un solo commit hacia atrás en el tiempo.


sábado, 10 de agosto de 2013

Gitstats. Estadísticas de nuestro repositorio git



GitStats

A veces  es interesante saber como va el proyecto, cuando tiempo invertimos en él , etc.
Es un proyecto de Heikki Hokkanen, lo tenéis en http://gitstats.sourceforge.net
En la página tenéis las instrucciones para instalarlo, bueno, básicamente un git clone.

Y es muy simple de hacerlo funcionar.
Para ello desde nuestra querida y inseparable consola de GNU/Linux;
./gitstats /mi_repositorio  /mi_directorio_html/  

Esto te generará un index.html para consultar.
Necesitarás Git, Python, Gnuplot,  que lo arreglas con apt-get install de turno. ;-)



lunes, 5 de agosto de 2013

miércoles, 10 de julio de 2013

Cuando hacer un commit y como hacerlo


Cuando hacer un commit y como hacerlo

Según mi experiencia en estos años usando control de versiones, y colaborando y siguiendo varios proyectos, he ido modificando mi manera de trabajar, según voy usándolo.

Aclaro que cada cual puede trabajar de la manera que mejor le convenga, pero está claro, que en los proyectos donde trabajan varios usuarios, es necesario al menos establecer unas normas, por el bien común de todos los integrantes y de los futuros que puedan incorporarse.

Así, podemos establecer un sistema de obligado cumplimiento por los miembros del proyecto.

Las reglas básicas del commit

  • Una funcionalidad, un commit. Usa ramas locales para ello. Después fusiona con la rama que vas a usar para subir tus cambios al repositorio remoto.
  • Evitar a toda costa hacer commits enormes, que corrigen un sinfín de cosas, con o sin relación alguna entre ellos.
¿ Parece una cosa muy fácil ?  No creas. 

El humano está acostumbrado a los malos hábitos, adquiridos con los años de esfuerzo en hacer las cosas diferentes al resto, y cambiar esto, va a costar.

¿ Que aporta esto ?


  • Mejora el encontrar posibles errores y su posterior corrección se torna muy simple, sobretodo , a la hora de fusionar por ejemplo la rama hotfix con la rama de producción.
Al tener, en principio, muy pocos cambios, será más sencilla su fusión.


  • La historia es mucho más simple , y el seguimiento será mucho más simple, sobretodo , para futura gente que se una al proyecto.

Pero a la hora de hacer el commit , tenemos que documentar que es.


Las reglas básicas del log

  • Si se usa un sistema de ticket , hacer referencia en el mensaje. Esto aporta mucho más información, que nos servirá posteriormente a la hora de tratar con la información.
  • Podemos usar una plantilla en git a través de los hooks, pero a grandes rasgos podemos simplificarlo cumpliendo este patrón:
    [DESCRIPCION CORTA] Obligatorio.
    [DEJAR ESPACIO EN BLANCO] Opcional.
    [DESCRIPCION LARGA] Opcional.
Es importante en el commit, identificar para un futuro que es lo que se realizado o solucionado.

Recordad, no estamos solos nosotros, por lo tanto, si hacemos un commit de 100 cambios, y cada fichero tiene inserciones, borrados, etc.., solo el programador que subió los cambios va a saber de que va todo esto. 

El resto , si se lo mira, lo tiene fácil, este marrón no me lo voy a comer, porque no tengo NI IDEA de lo que hace.

¿ Alguien aplica otros criterios ? 



lunes, 8 de julio de 2013

Similitud entre encaje de bolillos vs Git

Llevo un par de días haciendo encaje de bolillos con Git.



No veo yo mucha diferencia entre un encaje de bolillos y las ramas de git.

Fíjate como va escribiendo la historia, cada bolillo es un rama local, donde se fusiona, trascurre paralela al desarrollo principal, etc..


Aprender a decir NO


Una de las cosas que más rabia me da , es la incapacidad de decir no.
A veces, un NO en el momento adecuado, va a suponer la diferencia entre hacer las cosas bien o mal.

¿ Se puede desplegar un proyecto un viernes por la tarde ? NO
¿ Se puede poner una nueva feature antes de irse de vacaciones ? NO

Es importante decir a veces, NO.

miércoles, 3 de julio de 2013

GIT en el día a día





Cuando me preguntan el porque usar GIT, una imagen vale más que mil palabras.
La flexibilidad y potencia de esta maravillosa herramienta de control de versiones no tiene discusión.

Mi código esta en mi máquina, la historia que yo veo, no tiene porque ser la historia que se vea cuando suba mis cambios al repositorio remoto.

Esto es lo maravilloso de los control de versiones distribuidos.

GTK 3.1 GTK+ Stock Items Deprecation


Tengo pendiente de  pasar t-gtk con soporte a GTK2 al nuevo API GTK3.

Pero , parece que para GTK 3.10 quitarán el soporte a los Stock Items  Stock Deprecation

Sinceramente, no entiendo a los programadores que quiten o cambian el nombre de funciones, clases y métodos, por que suena más cool, o "por que yo lo valgo".

Uno de los motivos es que ahora será más fácil, puede ser, no lo discuto, lo que sí discuto , es que romper algo que lleva años, es tirar montones de lineas de código a la basura, y programas que ya no tienen a nadie detrás, pero puede funcionar simplemente compilando, ahora dejaran de ser inservibles.

Pero por poner un ejemplo


Old:
item = gtk_tool_button_new_from_stock (GTK_STOCK_SAVE);
New:
item = gtk_tool_button_new (NULL, _(“_Save”));
gtk_tool_button_set_icon_name (GTK_TOOL_BUTTON (item), “document-save”);



Vaya, parece que tendremos que picar más código....

Considero que un API debe de proporcionar una estabilidad , y si esta se rompe, es por un diseño deficiente.

Una cosa que tiene el Kernel de Linux, es que si cojes el código C de hace 30 años de Unix, este funciona sin problemas.

¿ Se hace cosas nuevas ? Por supuesto, pero NUNCA se rompe la compatibilidad que hay.
Ojo, que no es una cosa solo de GTK, es como un virus, se propaga a otros proyectos como la peste.

En fin, aquí dejo el enlace donde esta ahora las equivalencias.

Y muchas gracias al equipo de GTK por seguir haciendo crecer esta fantástica librería.

jueves, 27 de junio de 2013

GIT , ZSH y PowerLine

Como me gusta  la consola a la hora de usar GIT, me he instalado en GNU/Linux, la consola ZSH y las Powerline.

Siguiendo las instrucciones desde para instalar oh-my-zsh
Una vez instalado, edita el fichero   .zshrc y donde pone ZSH_THEME="robbyrussell"
lo cambias por ZSH_THEME="agnoster"

Y instrucciones para instalar la fuente powerline desde fonts powerline

Después, en las preferencias de la console a usar, como gnome-terminal o terminator, puedes seleccionar la fuente PowerLine y el resultado final es:


El resultado es espectacular!!!. 


En una simple ojeada , sé que estoy en la rama Linux, y que tengo algo en el index, símbolo +, y que tengo alguna modificación , símbolo o

Podeis ver diversos themes que podeis aplicar en zsh;
https://github.com/robbyrussell/oh-my-zsh/wiki/Themes

domingo, 23 de junio de 2013

miércoles, 29 de mayo de 2013

Charla sobre git

Charla sobre Git


Aquí tenéis la charla que ayer tuve el place de dar para el grupo Barcelona JUG.
He intentado que sirva tanto para gente que no tiene experiencia como para principiantes de git.

El enlace a la presentación:
http://prezi.com/nlvm_faqjau6/usando-git/



lunes, 6 de mayo de 2013

Tips para después de un git fetch

Aunque yo uso directamente git pull , recordad que pull es igual a fetch + merge,  es interesante a veces actualizar el repositorio local , pero sin hacer una fusión sobre el código en el cual estoy trabajando..

Podemos ver , antes de una fusión, los cambios que se afectuarán en forma de estadísticas ;
git diff --stat origin/master master

Podríamos ver fichero a fichero, usando nuestro programa de diferencias;
git difftool origin/master master

O por ejemplo, queremos coger un fichero del repositorio por encima del que tenemos;
git checkout  origin/master fichero.h

Fusionar los cambios;
git merge origin/master master

Después , se trata de resolver conflictos si los tuvieras.


miércoles, 17 de abril de 2013

Xerox Phaser 6000 en Ubuntu 10.04 64bits


Acabo de comprarme una impresora laser a color, de las baratitas, porque estaba HASTA los mismisimos de una Epson DX 520 Color de inyección de tinta. 
( Mirar el logotipo de Linux en la impresora!! ) ;-)

Para mí, un timo de cuidado el tema de la tinta de estas impresoras.

Ahora bien, para que funcione , en mi caso uso Ubuntu 10.04 a 64 bits,  el fabricante, en este caso Xerox, nos dá un triste driver a 32 bits en formato DEB;
http://www.support.xerox.com/support/phaser-6000/downloads/engb.html?operatingSystem=linux&fileLanguage=en_GB

Hay un rpm para 32&64, en este caso para RedHat y Suse, pero no he querido jugar con él, y no sé si puede meterlo en mi sistema.

Bueno, la solución a sido forzar a instalarlo , como cualquier otro programa de 32bits a partir del deb que nos hemos bajado posteriormente


Si quieres arriesgarte e instalar aplicaciones de 32 bits en tu ordenador con arquitectura de 64 bits, siempre que ese programa o aplicación a instalar no tenga su versión para la otra arquitectura, podemos forzar la instalación de ésta en un sistema Linux de 64 bits, de la siguiente forma:

Paso1.- Instalar las librerias de 32 bits en nuestro sistema de 64 bits con el siguiente comando:sudo apt-get install ia32-libs
Paso2.- Instalamos la aplicación deseada (en formato .deb, .rpm, etc.). En este caso hemos llamado a la aplicación de 32bits como ejemplo32bits.deb.
sudo dpkg –force-architecture -i ejemplo32bits.deb
Con esto conseguiremos instalar en nuestro equipo, el cual tiene una arquitectura de 64 bits, un programa o aplicación creado para a arquitectura de 32 bits.

Simulando en git , $Revision:$ de Subversion

Simulando en git , $Revision:$ de Subversion


Estamos en una charla con Yeradis, si sería posible simular algo como el id de $Revision:$ de SVN.
Particularmente, el numero de revisión automático me da igual, pero Yeradis es un 'plasta' con el tema,
nos hemos puesto los 2 y esto es lo que ha salido.

La idea , es usar los tags de git para hacer esa tarea
Lo  primero es generar un tag numérico que usaremos como inicio. Para ello nada más simple que hacer:
git tag -a 1

Después creamos un fichero, llámalo deploy.sh. Lo colocamos en /git/bin para que esté disponible.



#revision tags must be an INTEGER value
export tag=`git tag | sort -n | tail -1`

text=`echo $tag | sed "s/\([^0-9]*\)\([0-9]*\)/\1/"` ;
num=`echo $tag | sed "s/\([^0-9]*\)\([0-9]*\)/\2/"` ;
rev=`echo $text$(($num + 1))`

find ./ -name "*.c" -type f | while read file
do
    awk '{gsub(/\$Revision:(.*)\$/, "$Revision: '$rev' $"); print}' $file >$file.$$
mv -v $file.$$ $file
done

git commit -am "$1" && git tag -a $rev -m "$1" && echo "Revision:" $rev



Después en nuestro .gitconfig añadimos esta linea;




[alias]
deploy = !sh deploy.sh





Ahora , solamente tendremos que hacer;
git deploy "Nueva revision"

¿ Que hace esto ?

  1. Obtenemos el valor del ultimo tag, en este caso 1, y lo aumenta a 2
  2. Busca según el patrón "*.c", en este caso me interesa que busque solo los de código fuente de C, y      reemplaza la cadena $Revision: $ por la nueva revisión  , en este caso la 2., quedando como $Revision: 2$
  3. Realiza el commit
  4. Crea el tag con la nueva revisión.
 Este script se puede mejorar en muchos aspectos, pero abre una vía para una posible mejora, como controlar los errores devueltos, etc..








miércoles, 10 de abril de 2013

Ya está listo Gnome 3.8.

Hace días  he estado viendo las releases previas al lanzamiento de Gnome 3.8, y he de decir , que para mí, esta vez si que lo han conseguido.

Enhorabuena a los muchachos de Gnome, porque tiene una pinta estupenda.
Además, Gnome-Shell, particularmente me gusta, y mucho.

Más info:
https://help.gnome.org/misc/release-notes/3.8/

Buenas prácticas con GIT







Una manera de trabajar con GIT, es establecer un patrón de trabajo a nivel de empresa, a seguir por todos, aunque es aplicable a cualquier otro control de versiones.


Estableceremos 2 ramas principales que estarán en remoto:

  • master para producción
  • develop para desarrollo

La rama master es la rama principal que es la que se pone en producción.
Esta rama es la que tiene LA ÚLTIMA VERSIÓN ESTABLE.

Cuando la rama develop es lo suficiente estable, se puede mezclar con la rama master.

Es política de la empresa determinar quien / como / porque, es el responsable último de determinar cuando la rama develop pasa a master, ocasionando con ello un cambio de versión en la master.

La rama master tiene que tener los tags de versionado.
Establecer un sistema a seguir de número, como por ejemplo ubuntu, año/mes, 10.04, 10.10, etc., o por fecha , etc..

Se desarrolla en la rama develop , y cuando se llega a un versión estable, fusionamos con la master y producimos una nueva versión.

Establecer ramas de apoyo , pero limitadas en el tiempo, como por ejemplo;

  • Ramas de características (features)
  • Ramas de revisiones (hotfixes)

Cada una de estas ramas tiene un propósito específico están sujetas a estrictas normas. Podemos crear más ramas de apoyo, pero en mi caso, no me ha sido necesario.




Ramas features.  Rama padre: DEVELOP  Merge con: DEVELOP


   Estas ramas se utilizan para desarrollar nuevas características para una nueva versión.  
   La esencia de una rama de la característica es que existe, siempre y cuando la función está en desarrollo,   pero finalmente se fusiona de nuevo en develop.
   Se ramifican a partir de develop  y se combinan de nuevo en develop.  Las ramas de características no existen en origin.

Como tenemos que proceder:


Creamos una rama feature;
>git checkout -b feature_notes develop

Esto nos crea una rama feature_notes y nos coloca directo para trabajar en ella.
*Es lo mismo que hacer desde la rama develop :
>git branch feature_notes
>git checkout feature_notes

Implementaremos las mejoras correspondientes en nuestro código.
En este apartado , podemos considerar necesario hacer un git rebase -i, donde podemos definir que historia de cambios vamos a mostrar en la rama develop.
Es decir, si hemos realizado 12 commits en la rama feature_notes, no quiero que se muestre ese a la hora de fusionar, podemos agrupar todos esos commits en uno solo, mostrando la historia como un solo commit.

Incorporación de una nueva característica en develop
>git checkout develop
Switched to branch 'develop'
  
>git merge --no-ff feature_notes   
Updating ea1b82a..05e9557 (Summary of changes)
Con esto conseguimos que se cree un  nuevo objeto, guarde en el log  donde empieza y termina la feature, para que seguir la historia sea más rápido.
  
Ahora la rama feature_notes, no nos sirve para nada, la borramos.
>git branch -d feature_notes
    Deleted branch myfeature (was 05e9557).

Subimos nuestros cambios ya fusionados al origin.
>git push origin develop

Ramas hotfixes PADRE:Master Merge con: Master y Develop


   Se ramifican a partir de master y se deben combinar de nuevo en develop y master. La nomenclatura debe ser hotfix.

Si un bug es crítico debe ser resuelto inmediatamente.
La esencia de este método de trabajo es que los miembros del equipo (rama develop)   pueden seguir trabajando mientras que otra persona soluciona el bug.

Como tenemos que proceder:

Creación de una rama hotfix
Las ramas de revisión se crean a partir de la rama master.
Veámoslo con un ejemplo, digamos que estamos en la versión  de producción 1.2 y  esta hay un bug bastante grave. Supongamos que los cambios en develop son todavía bastante inestable.
A continuación vamos a bifurcar la rama master  para arreglar el problema.

>git checkout -b hotfix-1.2.1 master
Switched to a new branch "hotfix-1.2.1"
    
Corregimos el error en el código.

> git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)

No hay que olvidarse de modificar el número de versión después de la ramificación.

Después, arreglar el fallo y confirmar la corrección con uno o mas commits separados.

> git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)
   
Terminar una rama de hotfix.
MERGE CON: master y develop

En primer lugar actualizamos master para marcar la liberación.
Nos posicionamos en la rama master;
>git checkout master
        Switched to branch 'master'

Después, fusionamos la rama que hemos creado de hotfix-1.2.1 con la master, pero recordad, con la opción --no-ff
        >git merge --no-ff hotfix-1.2.1
        Merge made by recursive.
        (Summary of changes)

A continuación, y muy importante, es tagear esa versión corregida.
        > git tag -a 1.2.1
        
Después incluimos este “parche” también en develop

        > git checkout develop
        Switched to branch 'develop'
        > git merge --no-ff hotfix-1.2.1
        Merge made by recursive.
        (Summary of changes)

Por último matamos la rama temporal, pues no servirá para nada.

        > git branch -d hotfix-1.2.1
        Deleted branch hotfix-1.2.1 (was abbe5d6).

Estas ideas han sido sacadas básicamente de:

Tenéis vía google docs el documento; Guia de buenas prácticas con GIT

Android y Git. Disponer del hash automáticamente.

Una de las cosas a las que estoy acostumbrado, es tener siempre en mi código, el hash/tag/versión del control de versiones que estoy usan...