Probando git

Quizá algunos ya habréis tomado nota, por si acaso lo dejo dicho aquí: el otro día Alex Blewitt publicaba un fantástico post sobre git y egit (el plug-in de Eclipse que proporciona soporte integrado para git). En realidad el post versa casi exclusivamente sobre git. Merece la pena echarle cinco minutos para comprender cómo puede cambiar nuestra forma de desarrollar software con un sistema de control de versiones distribuido (DVCS – Distributed Version Control System).

Algo que me ha llamado bastante la atención es lo ágil que es trabajar con git. En primer lugar, git utiliza repositorios locales. Podemos trabajar con repositorios remotos, pero normalmente tenemos una copia local de éstos.
La forma de trabajar con git es diferente a como hacemos normalmente con un sistema de control del código centralizado como Subversion. En git cada desarrollador tiene una copia del repositorio, y puede evolucionarla como quiera. A priori esto puede parece un caos, pero es realmente ágil y versátil. Debido a la forma en que git encadena los commits (échale un vistazo al post de Blewitt para más detalles, es muy gráfico), es posible hacer merges mucho más sofisticados, por lo que esta evolución paralela realmente no supone un problema.

En sidelab llevamos ya muchos meses discutiendo acerca de la necesidad de migrar a git uno de nuestros proyectos software. El proyecto en concreto es JMH, actualmente alojado en un Subversion en Sourceforge. JMH es un framework Java que comenzó a desarrollar Micael y que posteriormente hemos ido evolucionando conjuntamente desde que me incorporé a la línea de investigación en la que él estaba trabajando.

Para que se entienda nuestra necesidad de cambiarnos de svn a git comentaré un poco cuál es la casuística que tenemos ahora mismo entre manos. Actualmente, ambos trabajamos en la misma línea de investigación: nuestra tarea consiste en tratar de obtener soluciones de buena calidad en problemas que son computacionalmente complejos. Este tipo de problemas no suele ser posible resolverlos de manera exacta, obteniendo el mejor valor posible (o valor óptimo). Por tanto, se intenta diseñar algoritmos aproximados que sean capaces de dar soluciones de calidad en tiempos razonables.

En general, tanto Mica como yo trabajamos en problemas diferentes, pero ambos nos apoyamos en el framework JMH, porque hay muchas cosas ya hechas. Por ejemplo, tenemos el framework de experimentación ya montado. También tenemos un conjunto de clases que nos ayudan a construir análisis de los resultados. ¿Cuál es el problema? Que con bastante frecuencia ambos nos encontramos con la necesidad de cambiar esto o aquello del framework, y normalmente los cambios o bien afectan al otro, o bien afectan a alguno de los problemas en los que hemos trabajado en el pasado (y que nos gustaría que siguieran funcionando en el futuro). Necesitamos tener la posibilidad de evolucionar jmh por separado.

En este sentido git es un sistema muy adecuado. En git no existe el concepto de repositorio central (aunque podría haberlo en algún sitio) y es muy habitual que alguien clone el repositorio público de otro para evolucionar el código como le apetezca. La ventaja es que si yo quiero beneficiarme de los cambios de otro, esto también es muy sencillo. Basta que apunte mi git a la url del git del otro desarrollador para que introduzca sus cambios en mi código.

Yo, por lo pronto ya tengo Egit instalado en mi Eclipse. En la página del proyecto tienen un manual muy completo para empezar. He seguido los pasos al pie de la letra y ya tengo mi repositorio git, y mi repositorio remoto en github donde puedes encontrar un esbozo de API (de momento pruebas, nada más) para consultar un Bugzilla mediante la API de servicios web que nos ofrece. Puedes hacer pull desde este repositorio utilizando esta URI: git://github.com/gortazar/es.sidelab.api.bugzilla.git. Por cierto que github tiene un importador de Subversion.

Mi problema es que me he acostumbrado a utilizar Mylyn-Bugzilla-Subversive y me gustaría tener una asociación similar Mylyn-Bugzilla-Git. Echando un ojo por ahí, me he encontrado con este conector de Mylyn para github. También podría seguir utilizando Sourceforge, sin embargo, su lentitud es desesperante. Y la buena noticia es que parece que en el momento en que egit termine de madurar, van a proporcionar soporte en Mylyn para gestionar los changesets como hacen con Subversive.

Ahora bien, miedo me da poder evolucionar mi repositorio tanto como quiera. Me conozco y haré pocos push a mi repositorio remoto. Habrá que volver a preocuparse por las copias de seguridad. No será la primera vez que perdemos un disco duro.

Anuncios

One thought on “Probando git

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s