Voy a aprender Git

Git. Ese sistema de control de versiones para superdotados. Es un hijo de Linus (el creador de Linux). Por ello, la sencillez no es una de sus características. Si alguna vez has configurado y compilado un kernel de Linux, sabrás que a este señor no le gusta ningún programa sin al menos cincuenta opciones en la línea de comandos: veinticinco empezando por -y otras veinticinco por --. Y diez más que no están documentadas. Para usar Git se asume que ya tienes de antemano una serie de habilidades (manejo de la Terminal, uso de ssh, resistencia innata al desaliento ante una documentación fea como un demonio, coeficiente intelectual de 300, …)

Así que uso habitualmente Mercurial (siempre que puedo, antes que Git) por varias razones:

  • me resultó muy sencillo aprender a usar Mercurial gracias al excelente tutorial de Joel Spolsky
  • el 80% de las cosas que haces habitualmente es muy sencillo de hacer con HG
  • no necesitas configurar nada: te lo bajas, lo instalas, vas a una carpeta, escribes hg init y listo
  • tanto BitBucket como SourceTree lo soportan. Luego es perfecto para mi.
  • si funciona, no lo toques

Pero claro, no se Git. Y me siento estúpido.

Hay varias cosas que considero «la maratón mental del informático». Lo que distingue a los buenos de los que tienen que seguir esforzándose. Cosas difíciles, que te obligan a aprender y a exprimirte el cerebro. Por supuesto, no he hecho ninguna de ellas, autocolocándome en uno de los dos anteriores grupos. Estos retos son:

  • dominar el uso de expresiones regulares (sin mirar en StackOverflow)
  • escribir una pequeña aplicación o demo completamente en ensamblador
  • hacer una aplicación web en un lenguaje funcional, como Clojure
  • hacer un juego usando OpenGL
  • entender qué demonios hace git con las ramas y git flow

Pues bien, una de ellas voy a tacharla de la lista, pero ya. El uso de Git está muy extendido, y soluciones que uso habitualmente como Cocoa Pods lo utilizan de forma extensa. Tengo que aprender a usarlo, quiera o no. Además, en varios proyectos se necesita Git y aunque con SourceTree puedo ir tirando, quiero comprender qué se cuece tras la interfaz bonita y ser capaz de manejar este DCVS yo solito.

La opción de leer un libro me aterrorizaba: demasiado esfuerzo tras tanto esfuerzo con otras cosas. Así que la mejor solución va a ser asistir al curso Entendiendo Git que Alfonso Alba imparte en Las Rozas. Creo que aún estás a tiempo de conseguir un descuento por compra anticipada. Voy con muchas esperanzas puestas en el curso, para tener una base que me permita manejar en el día a día este DCVS sin problemas, y explorar por mi cuenta. Vamos, que espero entrar chapurreando un par de palabras en Git y salir hablando, con acento y poco vocabulario, Git. Pero entendiéndolo al menos.

Escribiré qué he aprendido en el curso cuando lo termine. Pero conociendo a Alfonso de las NSCoder Night de Madrid creo que la duda no está en la calidad del curso, sino en si mi mente será capaz de pasar por la maratón. Espero que si.

j j j

Instalar el plugin de Mercurial en Eclipse

Los sistemas de control de versiones son adictivos. No puedes probarlos, porque luego no puedes vivir sin ellos. Aunque sea un pequeño ejemplo el que vas a programar, te sientes perdido sin tu repositorio y empiezas a pensar «¿y si se me ocurre cambiar esto o lo otro, y luego me arrepiento?». Ese tipo de «problemas» se solucionan casi en el acto con un VCS. Y si es distribuido (Git o Mercurial), mejor que mejor.

Antes de seguir, quiero dejar claro que no entro en las guerras religiosas entre los DCVS Git o Mercurial. Yo uso Mercurial porque Joel Spolsky lo explica de forma increíblemente sencilla. Aunque ahora que Git viene integrado con XCode4, probablemente es una buena alternativa… bueno, no :-). En fin, usa el que te de la gana, pero usa uno.

Para casi todos mis proyectos uso Mercurial. No lo uso para los ejemplos que escribo para mis cursos. Y estaba pensando «¿porqué no usarlo?». Por pereza mental, y por hacer siempre las cosas de la misma forma. Mi padre dice que «si un burro tira de una noria para un lado y le das la vuelta, ya no sabe tirar de ella». Y es que nos acostumbramos a hacer siempre lo mismo, de la misma forma, y nos estancamos. De vez en cuando hay que revisarlo todo con una mirada fresca y en lugar de pensar «¿hay una manera de optimizar esto que estoy haciendo?» debemos plantearnos «¿en serio tengo que seguir haciendo esto?».

El caso es que un sistema de control de versiones es casi perfecto para dar clases. Puedes tener una primera versión, sencilla, y luego ir promoviendo a las distintas versiones más avanzadas, que pueden ser changesets o bien nuevas ramas. Los cambios que hagas durante la clase para demostrar algo siempre puedes revertirlos sin problemas. Para eso está el DCVS. Y distribuir el código es más sencillo: compartes tu repo, y los alumnos se clonan los repositorios y punto. No hay que andar con historias de copiar los Workspaces de Eclipse y que luego falle (los WS de Eclipse dependen del sistema en el que los uses, hay que cambiar luego los Build Paths, etc.). Como se puede ver, todo son ventajas. La pregunta es porqué no lo he usado hasta ahora…

Instalar Mercurial

Evidentemente, antes de nada lo primero es instalar Mercurial, ya sea para Linux, Windows o Mac, o para donde vayas a usar el DCVS. Si no, el plugin de Eclipse no podrá usar Mercurial porque no lo encontrará en tu sistema. Te lo bajas de su sitio web oficial.

Instalando hgEclipse

HgEclipse es un plugin para Eclipse que añade soporte Mercurial a tus proyectos. Una vez instalado, en el menú contextual del proyecto encontrarás en la opción Team > Share la parte de Mercurial. Para instalarlo, iremos a Help > Install New Software e introduciremos el repositorio http://cbes.javaforge.com/update. En mi caso (instalándolo en Mac) no necesito los binarios de Mercurial para Windows, así que no los marco para instalar.

Instalando hgEclipse: repositorios

Instalando hgEclipse: repositorios

Cuando pulsemos Next, pasaremos a descargar e instalar el plugin. Al final no hay más remedio que reiniciar Eclipse. Así que hazlo 🙂

hgEclipse instalándose

hgEclipse instalándose

Usando HgEclipse

Una vez con todo instalado, lo primero es crear el repositorio Mercurial en nuestro proyecto. Eso lo prepara todo para poder gestionar las versiones de tu codigo fuente. Equivale a un «hg init». Para ello, pulsaremos con el botón derecho del ratón en el nombre de nuestro proyecto y seleccionaremos Team > Share Project. Si todo está correctamente instalado nos aparecerá una ventana como la siguiente:

Share > Project

Share > Project

Como queremos crear un repo Mercurial, basta con pulsar siguiente. Nos mostrará dónde va a crear el repositorio (que es una carpeta llamada .hg, dentro de nuestra carpeta de proyecto). Aparecerán unos nuevos iconos en las carpetas y ficheros de nuestro proyecto y la palabra [new] indicando que el repo es nuevo, pero aún no se ha realizado el primer commit.

Repositorio tras el init

Repositorio tras el init

¡Vamos a añadir ficheros a nuestro repositorio! Botón derecho en el proyecto > Share Project, pero ahora aparece un menú con un montón de opciones. Seleccionamos Add. Esto añade los ficheros del proyecto al repositorio. Yo suelo añadir únicamente el código fuente, pero no los ajustes del proyecto, ni las carpetas propias de Eclipse, como muestro a continuación:

Añadamos ficheros al repo!

Añadamos ficheros al repo!

Ahora que hemos añadido, los iconos de los ficheros fuente cambian y tienen un «+» azul al lado. Están ya controlados por el repositorio, pero no hemos subido este cambio, que en este caso es subir la primera versión. Para ello, Team > Share Project > Commit y añadimos un mensaje de commit. HgEclipse nos muestra los ficheros que va a subir, y los que no tiene «controlados», por si queremos añadirlos.

Commit

Commit

Al pulsar OK, ¡listo!. Ya tenemos control de versiones funcionando. Ahora, si modificamos un fichero se nos mostrará como cambiado y podremos hacer un commit con esos cambios. O podremos compartir el código fuente del proyecto por la red con la opción Serve. Cualquiera en la red podrá hacer un Pull del repo y bajarse este código fuente. Mucho más rápido que compartir el proyecto en una carpeta SMB y encima evitas problemas con las configuraciones de Eclipse (yo lo uso en Mac y mis alumnos, normalmente, en Windows)

Las opciones del menú de Share Project son muy amplias. Os animo a irlas probando y a aprender Mercurial entre todos. El que tenga un truco especial de cómo usa Mercurial, ya sabe, que use los comentarios.

hg commit -m "post acabado"
hg tag -m "v1.0"
j j j