22 de Enero, 2010

Finalmente estoy usando GIT

En realidad tampoco hace tanto que decidí probar GIT con GitHub, pero me doy cuenta de que en lo poco que he programado en casa en estos últimos 6 meses, ya estoy habituado a este SCM.

Simplemente hago lo mismo con GIT que con SVN, salvo algún detalle que cambia (a mejor), y si nos ponemos estrictos... hago lo mismo que ya hacía con CVS, y que aprendí trabajando con RCS :P.

Al final el diablo está en los detalles, pero a grandes rasgos siempre hago lo mismo cuando soy el administrador del repositorio:

  1. Desarrollo, evidentemente :).
  2. Suelo hacer un git status y luego git diff cuando acabo de implementar una nueva funcionalidad.
  3. Realizo un git add fichero [fichero], para meter en el mismo commit todos los ficheros involucrados en el cambio (eso de los commits atómicos, que no tenía CVS).
  4. Pongo un mensaje descriptivo del cambio, normalmente precedido de NEW si es una nueva característica, o FIX si es una corrección.

Hasta aquí no hay cambios respecto a cómo lo haría con SVN, pero más adelante llegan los matices.

Como GIT es distribuido y el trabajo lo hacemos en el repositorio local, necesitamos mandar los cambios locales al repositorio remoto (en este caso en GitHub, que cada vez me gusta más como servicio).

Esto se consigue con: git push.

Otra cosa que es distinta respecto a SVN son los tags, que utilizo para marcar versiones o hitos en el proceso de desarollo.

Por ejemplo: git tag 0.1, para marcar el último commit como versión 0.1. Y luego no hay que olvidarse de hacer un git push --tags.

Para los repositorios que gestiono yo no hay mucho más (porque no me mandan parches, claro :|), como por ejemplo hacer merge de las traducciones que me llegan vía Transifex a la rama donde gestiono las traducciones (que es un poco lioso, eso sí).

Cuando trabajo con un proyecto que usa GIT, como es el caso Mojolicious, solo hay que recordar hacer un git pull (equivalente a un svn update). No he mandado nunca un parche ni hago commits locales, así que tampoco he tenido que mirar mucho más al respecto :D.

En fin, a grandes rasgos sospecho que el SCM no importa mucho, después de haber trabajado con varios, siempre que tengas en la cabeza el funcionamiento general del invento. Lo importante, y lo que al final determina qué usas, creo que es si eliges un servicio de hosting para apoyar tu trabajo, como por ejemplo GitHub (con GIT) o Google Code (con SVN o Mercurial).

En la empresa seguimos con el equipo Trac + SVN, y tampoco nos funciona mal por nuestro modelo de trabajo y porque hacemos uso intensivo de los tickets. No sé si tengo razón en que los servicios de hosting de proyectos son tan importantes, ¿con cuál prefieres trabajar tu?

Anotación por Juan J. Martínez, clasificada en: scm, git.

Hay 4 comentarios

Gravatar

Yo empece con cvs hace unos añitos ya, y estaba super feliz con el.
Migrar a svn me supuso un monton de quebraderaos de cabeza, me costo mucho realmente (a dia de hoy sigo sin entender algunas cosas), aunque simplemente por Trac merecia la pena el cambio.
El siguiente cambio fue mucho mas facil (probablemente por la "mania" que le tuve a svn desde el principio), dedique un día entero a hacer pruebas con bazaar, git y mercurial (y eso que me recomendaban darcs, que tb esta muy bien, pero tiene la horrible depedencia del compilador ghc si no tienes binarios para tu sistema). Despues de muchas pruebas, me quede con Mercurial, quizas por que es el que mejor soporte para trac tiene, por que me gusto mucho el sistema de "plugins" y por que es python ;D (FANBOY!), entre otras cosas.

Ahora aun tengo cosillas en repos svn, por pereza a la hora de migrarlos, pero todos los proyectos nuevos los tengo con hg, y estoy super contento (no he probado bitbucket, pero imagino que sera muy similar a github).

por Wu, en 2010-01-22 19:14:51

Gravatar

Yo empezé en mi primera y actual empresa hace casi dos años con subversion y en menos de dos semanas cambiamos a git.

El cambio desde luego para mi fue para mejor, por desconocimiento o por lo que fuera cada dos por tres tenia problemas con subversion.

Respecto a git me parece una herramienta increible para repositorios de software libre, pero para repos privados creo que no me merece la pena y prefiero tenerlos en mi propio servidor, simplemente porque el mantenimiento es nulo y creo que todo lo que me proporciona github lo tengo disponible ya, quizás menos bonito, pero seguro que nos distraemos menos con floripondios :P

por José Galisteo, en 2010-01-22 22:28:18

Gravatar

En el trabajo usamos svn y dudo que a corto plazo cambiemos a git u otro scm distribuido.

Sobre los sistemas de hosting, estuve en google code y me pasé a javahispano.net (que ahora cierra) por una razón no-técnica: google capa de forma activa el acceso a su servicio las ips de países embargados por EEUU.

Eso significa que mis amigos cubanos no pueden acceder a google code por que literalmente google les dice que sus IPs están "forbidden".

Este hilo movió un proyecto de SL bastante importante en GIS llamado SEXTANTE de google-code a osor.eu:

http://listserv.gva.es/pipermail/gvsig_usuarios/2008-May/004954.html

En fin, ahora quiero pasar a github para probar GIT pero tendré que asegurarme que no les aplican las leyes de embargo.

por Jorge, en 2010-01-23 10:21:48

Gravatar

@Galisteo: infrastructura propia, esa ha sido mi decisión durante mucho tiempo, pero me doy cuenta que al final es mejor eso de que que lo hagan otros. También es que para mis proyectos privados (pocos), con un repo local me vale.

@Jorge: hay más posibilidades, como http://gitorious.org/ (que están en Oslo, lo que les deja fuera del alcance de USA).

Gracias por los comentarios, es interesante conocer otros puntos de vista.

Si os parece una chorrada lo de poner un título que introduzca al comentario, con no comentar... arreglado, yo no os lo voy a tener en cuenta ;)

por Juanjo, en 2010-01-23 10:34:26

Los comentarios están cerrados: los comentarios se cierran automáticamente una vez pasados 30 días. Si quieres comentar algo acerca de la anotación, puedes hacerlo por e-mail.

Algunas anotaciones relacionadas: