Desencadenando el GitKraken

En el pasado he hablado de Git para gestionar las versiones del código, pero hoy voy a volver al tema para hablar del cliente que estoy usando de forma regular: GitKraken. La interfaz gráfica de la casa siempre dejó que desear y he paseado por unas cuantas, habiendo estado durante mucho tiempo con SmartGit, pero recientemente me dió por probar esta no solo porque había leído buenas referencias, sino porque también me hizo gracia el nombre.

Desencadenando el GitKraken

Las ventajas de usar un cliente gráfico son obvias (aunque obviamente la línea de comandos consume menos recursos y una vez se tiene el vicio es rapidísima):

  • es mas fácil de usar, pues no hay que memorizar comandos, además de que ver el resultado en una imagen es mas sencillo de procesar, pues “una imagen vale mas que 1000 palabras”.
  • la posibilidad de condensar procesos en un par de clicks, ahorrándose muchas líneas complicadas.
  • la posibilidad de tener cómodamente almacenadas las credenciales.

Cada uno tiene sus gustos, pero para mí este cliente supera a SourceTree (que es el referente clásico) por su claridad de visualización de las ramas, lo que lo pone a la cabeza de todos los que usado hasta ahora en este terreno… y además es multiplataforma, asi que funcionalmente hay poco mas que se pueda pedir… La única lástima es que aunque su base sea de código abierto, no comparte esa filosofía.

Limpieza de primavera 2015 de Google: cierra Google Code

Como todas las primaveras, llega el temido momento de ver qué va a cerrar Google este año, y la nueva víctima es Google Code. ¿El motivo? El típico abandono del proyecto, y al popularidad ganada por GitHub y Bitbucket.

Limpieza de primavera 2015 de Google: cierra Google Code

Supongo que lo primero es explicar que es Git para quien no esté puesto en el tema. Git es un software de control de versiones, creado por Linus Torvalds (ese señor que es famoso por ser el creador del kernel o núcleo de software libre Linux, ¿ya os suena mas?). Cuando Linux comenzó a trabajar de forma colaborativa, recibía por correo los cambios de los demás desarrolladores, y debía integrarlos manualmente. Conforme la comunidad crecía, esto se fue volviendo insostenible, de forma que después de darle vueltas al tema, comenzó a crear un sistema que le ayudase con este cometido. Este sistema recibía los nuevos ficheros de código, detectaba los cambios, y los actualizaba, generando “nuevas versiones”. si algo iba mal, siempre se podía volver a versiones anteriores, o empezar a desarrollar nuevos proyectos basados en los anteriores (llamados branches o  ramas), que bien podían diversificarse o juntarse de nuevo en algún punto (merge o unirse). La cuestión fue dónde se almacenaba ese código, al que todo el mundo podía aportar.

Una de esas posibilidades era Google Code, que era bastante popular. Con todas las aplicaciones que tiene Google, parecía un buen lugar, con bastantes prestaciones, hasta que comenzó a dejarlo abandonado una vez mas. Si comparamos su situación con Github, su mas fiero competidor ahora mismo, la migración de sus usuarios es normal. Solo hay que mirar la facilidad de uso y la interfaz bien diseñadas y adaptativa a cualquier dispositivo de Github, sus aplicaciones para dispositivos móviles, o sus capacidades sociales frente al aspecto pre-moviles de Google Code.

A estas alturas empieza a preocuparme la posición de Google respecto a la gestión de contenidos: primero Google Reader, después Feedburner, ahora Google Code, Blogger en la cuerda floja desde hace años… por no hablar de la inexistencia de una aplicación nativa de Google Drive para Linux desde luego cada vez confío menos en ellos para gestionar mis contenidos.