Jugando con GIT

Tras el post anterior, me quedé con las ganas de ponerme a jugar con Git un poco más en serio, y eso he estado haciendo, a ratos, a lo largo de esta semana.

La primera sorpresa agradable es que ahora, desde la página oficial, existe descarga para windows, con un instalador fácil estilo windows. Me lo descargo e instalo. El instalador te da tres opciones, instalar un bash específico para Git, hacer una instalación paa cygwin o bien, con serias advertencias por parte del instalador, poner los comandos de git accesibles desde una ventana de comandos de ms-dos. Esto último requiere que ciertos comandos de windows, como find.exe, se cambien por otros al estilo unix. Vemos que windows, aunque ya hay instalador fácil oficial, sigue sin estar totalmente soportado, haciéndose necesario el uso de una shelll de unix. Supongo que esto no tiene especial importancia si estás acostumbrado a unix (como es mi caso), vas a usar un TortoiseGIT o directamente el IDE que sea.

Siguiente parte a probar, el servidor. Según la documentación hay tres opciones:

• git daemon. Es lo más simple, se arranca con un comando y ya está compartido cualquier repositorio git en el servidor. El acceso es de solo lectura, haca falta configurar el arranque si queremos también acceso de escritura. La pega es que tiene ningún tipo de autentificación de usuario, así que cualquier anónimo sería capaz de escribir y borrar en nuestro repositorio sin ninguna restricción. Es ese el motivo por el que no se aconseja esta opción en redes que no sean de confianza. Este servidor se aconseja sólo en modo lectura, puesto que es el más rápido a la hora de hacer descargas (git clone).
• ssh. Acceso a través de ssh, con una configuración de ssh más o menos estándar. No la he probado y es la opción aconsejada, con la pega de que todos los usuarios deben tener usuario en el servidor.
• http. Publicar un repositorio en modo lectura desde un servidor http es casi inmediato. La parte de escritura requiere habilitar WebDAV en el servidor apache y la autentificación de usuarios recae totalmente en el servidor apache. Esta es la opción que he usado yo.

Con respecto a la primera opción, git daemon, simplemente comentar que git push se queda colgado (llevar algo al repositorio remoto) haciéndola totalmente inútil. Parece ser un bug del cliente windows que lleva ya un tiempo ahí. La parte de servidor ssh en windows tampoco parece que se pueda poner fácilmente en un windows que no sea "server" (creo que si no es un windows "server" ni siquiera tiene servicio de ssh) y por eso me he tenido que ir a la parte de apache http.

En cuanto a las ramas, me he puesto a jugar con ello y es una pequeña maravilla. La gran mejora respecto a svn no es que haga mejor los "merge" en si mismos, supongo que el algoritmo de merge deben ser parecidos y en ambos casos, si hay conflictos, hay conflictos y se deben resolver a mano. La gran ventajas de Git sobre SVN es que Git lleva automáticamente toda la cuenta de qué ramas se han hecho de qué ramas, qué merges se han hecho y cuando hacemos un nuevo merge, el sabe automáticamente qué ficheros son los que tiene que juntar y desde dónde. SVN no lleva toda esta cuenta, por lo que el primer merge que se hace suele funcionar bien (se hace desde las revisiones adecuadas), pero si más adelante intentamos hacer un segundo merge con las mismas ramas, o de una de estas con otra, svn no sabe exactamente desde qué revisiones partir y debemos decírselo manualmente en el comando. Eso nos obliga a llevar a nosotros, manualmente, un histórico de merges que se han hecho, desde qué ramas, etc, etc. Claramente, si quieres trabajar con muchas ramas y vas a hacer muchos merges, Git es muchísimo mejor opción que Subversion.

En cuanto a facilidad de comandos, sobre todo si se está acostumbrado s Subversion, cuesta acostumbrarse un poco. El principal motivo, aparte de saber o no la sintaxis de los comandos, es que venimos de Subversion con la idea de un único repositorio central. Nuestra copia de trabajo está siempre ligada al repositorio central y los comando svn se hacen siempre contra ese repositorio central. En Git, nuestra copia del repositorio "central" es exactamente igual de importante para Git que la "central". Y pueden evolucionar por separado, yo puedo tener ramas que no están en la central y evolucionan de forma distinta, el "central" puede tener sus propias ramas, llamarse incluso igual que las nuestras, y no tener nada que ver.

El tema va incluso más allá, lo de repositorio "central" es cosa nuestra, realmente no lo hay. Git permite incluso que traigamos cosas de repositorios distintos. Puedo traerme una rama del "central", otra rama del repositorio de mi compañero de trabajo Federico y otra de internet, teniendo así un repositorio local con ramas traídas de N fuentes distintas.

Y las ramas mías y de la central, aunque se llamen igual (o no) y tengan el mismo contenido, pueden no estar ligadas para Git o pueden si estarlo. Si no están ligadas, git las considera independientes y los comandos git push o git pull no funcionarán si no les damos la paramétrica adecuada indicando ambas ramas. Si están ligadas, aunque tengan nombres distintos, git lo sabe y es capaz de ejecutar push y pull sin problemas.

Todo esto añade una complejidad excesiva de conceptos y variedad de comandos, sobre todo para los que venimos de Subversion con un respositorio central en el que están todas las ramas que existen y no hay más. Para empezar a trabajar con Git y sacarle partido a todo esto de las ramas, es necesario hacer un montón de pequeñas pruebas con los comandos para entender exactamente qué hacen, o buscar tutoriales detallados, puesto que la documentación es más bien pobre (es más una documentación de referencia que un tutorial de conceptos).

Ahora probaré el tema de servidor y autentificación con LDAP. Si consigo algo decente, montaré un servidor Git en el curro para alguno de los proyectos pequeños y empezaremos a hacer pruebas para usarlo. Me queda también ver si redmine es capaz de sacar fuentes de Git y si Hudson/Jenkins entiende de Git.