Primeros pasos con git (parte 0)

Trabajé durante mil años sin usar sistemas de control de versiones (cosas como svn, cvs, git, mercurial, bazaar, etc) ni nada parecido, y durante todo ese tiempo no sentí la necesidad de hacerlo. Principalmente porque trabajaba solo, o en pequeños grupos, entonces el modelo de llevar y traer zips/tgzs fechados alcanzaba como para no complicarse "por demás" con todo un repositorio. Sin embargo, en algún momento quise ofrecer el código de ZinjaI y PSeInt "en tiempo real" (que cada cambio que haga esté inmediatamente disponible para quien lo quiera probar), porque eso es algo que me gusta de muchos proyectos de los que soy usuario, y porque tiene otras ventajas adicionales (como por ejemplo que algunos usuarios puedan ayudar con el testing de forma temprana).

Hasta entonces, como dije, solo había usado los sistemas de control de versiones para clonar repositorios ajenos y nada más. A partir de ese momento, empecé a experimentar un poco con crear repositorios, hacer y publicar cambios, etc. Y tuve que elegir un sistema en particular, y me incliné por git porque era el que estaba de moda, y porque es un producto que nace de la mano del mismísimo Torvalds para gestionar nada menos que El Kernel, así que potencia y flexibilidad estaban garantizadas. Además, su popularidad prometía mucha documentación actualizada, es decir, un fácil y rápido aprendizaje.

Resultó que no encontré tan fácilmente el tipo de documentación que me hubiese gustado encontrar. Hay tanta pero tanta que es difícil separar lo bueno, y en general encontré excelentes manuales pero que resultan más enciclopédicos que prácticos, o explicaciones maravillosas de cómo funciona por dentro (como esta, realmente imperdible), pero pocos tutoriales que reúnan la condición de mostrar sólo lo necesario para no confundir al lector, pero explicando con cierto rigor qué es lo que se está haciendo en cada paso de forma que entienda y aprenda algo, en lugar de memorizar una receta (esto es algo de lo más cercano, y mi primer fuente). Por eso, voy a ir compartiendo en dos o tres posts mi experiencia con git buscando darle ese enfoque. Pero que quede claro que esa experiencia es muy poca, que mi experiencia con otros sistemas es todavía menor, que estoy utilizando solo un 1% de su potencial, y que gran parte del otro 99% ni siquiera sé que existe (por todo eso todavía no lo integré en el menú de herramientas de ZinjaI). Dicho esto, voy a tratar de resumir lo que sé para que sirva de punto de partida para otros en situaciones similares. Sobre eso, iremos luego mejorando y si algún lector con más conocimiento de la causa quiere corregirme o contribuir en los comentarios, bienvenido sea.

Y ahora, como para contradecirme instantáneamente, pero también para que este post no quede muy largo y entonces se aburran y lo abandonen (ya bastante largo va a quedar), voy a hacer solo unos comentarios acerca del uso de repositorios en general, para entrar en contexto. Y voy a dejar la promesa de presentar los primeros comandos, el paso a paso y la parte jugosa para el siguiente artículo (tengan paciencia, en el próximo, sin rodeo, creamos nuestro primer repositorios y aprendemos a subir y bajar cambios).

Entonces, ¿para qué sirve git? No estoy seguro, pero al menos para control de versiones y trabajo en grupo. Lo primero significa que sirve para tener todas las versiones de un proyecto, de forma de poder registrar cuando y dónde se hicieron los cambios, identificar en qué momento apareció o desapareció un bug o una funcionalidad, poder comparar performance entre versiones, ver la evolución de una parte del software o un archivo, generar listas de cambios muy detalladas, indirectamente obtener estadísticas del ritmo de desarrollo, y más. Además, se puede a partir de una versión generar "ramificaciones", es decir, aplicar sobre esa versión distintos cambios, para probar o implementar distintas cosas, y al final, si funcionan, unirlas (aplicar esos cambios) en la versión "principal". Con los comandos de git, en un repositorio (por ahora sería un directorio con los fuentes del proyecto), podemos en un paso cambiar de versión, o de rama, de forma muy rápida y fácil. Por otro lado, esta idea de varias ramas no se limita a un mismo usuario, sino que varios usuarios pueden copiar un mismo repositorio inicial, trabajar cada uno en una rama propia, y luego unirlas integrando el trabajo de todos. A esto me refiero con lo de trabajo en equipo.

Pero que quede claro, que aunque sea un proyecto personal y seas el único que lo desarrolla, igual te conviene utilizar git (o alguna herramienta similar), porque todo será más fácil, rápido y prolijo así.  El sistema de control de versiones es de esas cosas que si nunca hemos usado, no necesitamos, pero una vez que nos habituamos a tenerlo, ya no queremos dejar de usarlo.

Dentro de estos sistemas, algunos utilizan un gran servidor maestro que tiene "la" copia del proyecto, del cual todos bajan el fuente y en el cual todos aplican luego los cambios, mientras que otros no consideran especial a ninguna copia, y está en los usuarios mirar a una en particular como "la" copia o no, ya que cualquiera puede ser maestra o cliente en cualquier momento. Los primeros, como los viejos y preciados cvs y svn, se denominan centralizados. Los segundos, como git, distribuidos. Uno distribuido es más flexible, y también permite trabajar de modo centralizado. Además, facilita la administración de un proyecto realmente grande delegando responsabilidades en capas.

Ejemplo: Linus Torvalds es el gran dictador benévolo del nucleo de Linux. Él es dueño del gran repositorio "central", y solo acepta contribuciones de un muy reducido número de desarrolladores que son de su confianza. Pero a su vez, cada uno de estos sigue el mismo esquema, cada uno acepta cambios de su propio y reducido grupo de confianza. Entonces, los repositorios de estos primeros desarrolladores son como un repositorio central para esos grupos en un momento, pero luego elevan esos cambios al verdadero repositorio central de Linus. Y así, repitiendo esto en más niveles, gestionan la complejidad de semejante proyecto. Y cuando digo elevan, en realidad miento. Uno puede desde un repositorio A enviar cambios a otro B, o también puede B pedirle los cambios a A (porque ninguno es en realidad especial para git). Entonces, para evitar que cualquiera (obteniendo las contraseñas necesarias) pueda entrar a hacer cambios al repositorio central, el responsable del central utiliza el mecanismo inverso al que se usa por ejemplo en svn, y pide él los cambios a los demás repositorios de confianza, en lugar de esperar que estos los apliquen directamente. Así, además puede controlar cada cambio y filtrar lo que no le guste (maldiciendo al autor si seguimos hablando de Torvalds :).

Parece complicado, pero en realidad es para simplificar el mantenimiento de semejante bestia de código de la forma en que lo hacemos en la programación: atacando la complejidad por niveles. Está claro que la mayoría de los mortales no manejamos semejantes proyectos, así que los ejemplos serán mucho mucho más terrenales, simples, pero la idea era ilustrar la potencia y flexibilidad de un sistema distribuido como git. Y dentro de los distribuidos, tengo que decir que mi poca experiencia confirma lo que he leído de terceros, que dice que git es por lejos el más rápido, se nota. Así que por todo esto y más, no se pierdan las próximas entregas, donde vamos a ensuciarnos las manos con la consola para empezar a divertirnos.

Este post sigue en Primeros pasos con git (parte 1).