Git

Esta crónica es acerca de Git, actualmente (siendo el año 2022) el software de control de versiones más popular y usado del mundo.

-¿Otro texto acerca de Git? -te estarás preguntando. Sí y no. Sí hablaré de Git pero, no como un artículo teórico, sino precisamente, como un recuento lo que he podido experimentar con él.

Primero, un poco de historia…

Mis estudios de informática iniciaron en Septiembre de 1999. Si bien no eran mis inicios con la programación, sí era la primera vez que formalmente abordaba el tema. Como en muchas carreras orientadas al cómputo, la mía no se distanciaba del desarrollo del software, por el contrario, podría decir que aunque no estaba etiquetada como tal, la carrera tenía esa orientación.

¿A qué viene todo esto con Git? Bueno, de entrada, no existía en esos años (1999-2005) pero yo tenía que administrar código fuente de mis proyectos, personales individuales, y los que hacíamos en equipo; de tal suerte que mi control de versiones (seguramente no te es ajeno) funcionaba como sigue:

1. Creaba el código fuente y lo trabajaba durante determinado tiempo, hasta digamos, el final del día. Hacía un corte en un punto donde todo compilaba correctamente y ejecutaba “bien” hasta el punto del corte.
2. Creaba una carpeta de respaldo
3. Creaba una subcarpeta con la fecha del día con el formato YYYYMMAA
4. Copiaba todo el código fuente a la carpeta en turno
5. Continuaba mi trabajo el día siguiente (o periodo siguiente) y repetía los pasos 1 a 4.

Cuando el trabajo era largo (llegué a desarrollar proyectos escolares que me tomaban hasta 4 semanas de labor o más) terminaba con más de 20 carpetas de versiones de código fuente. La siguiente captura de pantalla es un ejemplo de cómo se veía mi gestión de código:

Sin embargo, sería temerario y falso de mi parte decir que esta forma de organizar código era óptima o infalible, no porque no pueda serlo, sino porque depende de muchos factores:

1. Disciplina. Había días que ya terminaba tarde, estaba cansado, ofuscado, de mal humor porque no obtenía los resultados que deseaba y simplemente olvidaba o me negaba a generar el directorio respaldo.
2. Cambios granulares. En un día podía hacer múltiples cambios, concluir algunos que funcionaban y otros que no funcionaban del todo o se quedaban a medias. Tenía que decidir si respaldar así o mejor esperar al siguiente periodo para concluir con el trabajo pendiente y hacer las correcciones correspondientes.
3. Memoria. Como buen principiante, dejé todo a mi memoria, no llevaba un control de qué había hecho cada día y qué funcionaba bien y qué no. Aunque tenía idea de mi progreso día con día, no tenía registro de cómo había ido liberando las diferentes funcionalidades.
4. Correcciones. En numerosas ocasiones, cuando agregaba nueva funcionalidad, me daba cuenta que algo que ya tenía desarrollado era insuficiente para cubrir la entrada de datos o los requisitos de la nueva funcionalidad, por lo que tenía que modificar algo que ya había dado por correcto, de forma que podía tener 2 o más días con una característica del programa que yo daba por funcional.
5. Cancelaciones. Corolario del punto anterior, conforme avanzaba en el desarrollo de algo nuevo, que propiciaba cambiar algo existente, empezaba a encontrarme con nuevos contratiempos. Con el tiempo y la experiencia que fui ganando con los proyectos, me di cuenta (ojo que es la primera aportación de esta crónica para mi audiencia) que la aparición de constantes errores e inconvenientes con una misma funcionalidad o con algo que recién había corregido, era signo inequívoco de que mi diseño o solución eran incorrectos, por lo que tenía que descartar todo lo que había hecho y regresar al punto donde estaba “bien” para comenzar de nuevo.
6. Unificación de código funcional. En ocasiones dejaba una versión funcionando de alguna característica en particular e intentaba desarrollar la siguiente en 2 vertientes para probar las soluciones que habia planteado. En esas vertientes surgían partes que me servían, entonces, para la versión definitiva, terminaba buscando la parte del código de cada vertiente que era útil e iba generando la versión final.

¿Qué ocurría cuando llevaba el proyecto a revisión?

Primero, hacer la copia del código fuente que corresponde a la versión final. Seuramente adivinaste el nombre de la carpeta:

Llegaba el momento de la verdad para mostrar el proyecto en ejecución. Solo en algunos casos de programas muy sencillos salía airoso en el primer intento, en los demás regresaba con un ánimo variante, según el número y la naturaleza de las observaciones que había recibido. Me dedicaba a las correcciones en turno, y como esta ya era la versión final, ya no hacía versión del día, sino, la versión de la versión final:

Considero que buena parte de esta narrativa no te será ajena, y con toda seguridad tampoco el hecho de que el humor de la persona que revisa también influye en el resultado, a tal grado que llegué a tener versiones finales así:

Había profesores que hacían este proceso tortuoso, porque en lugar de revisar todo (o yo revisar que todo funcionara después de mis correcciones), el profesor validaba algo, veía que no funcionaba como se había imaginado y detenía la revisión. A modo de chiste, hacía versiones finales así:

Como en los proyectos profesionales, los escolares culminaban con la entrega de código fuente al profesor, por lo que la versión final final de finales, quedaba registrada así:

Relatar estas experiencias me ha recordado momentos graciosos y no tan agradables de esos años.

Ahora, haz este ejercicio. Imagina que eres yo; estás en un equipo de trabajo escolar donde a cada quien se le encarga una parte del desarrollo que hace por su cuenta y que se unifica cada determinado tiempo, con sus versiones y correcciones. Extrapola ese ejercicio y administra versiones de código fuente de varias personas con este mecanismo. Sazónalo con la variante de que la persona que entrega código fuente tiene su propia manera de gestionar su trabajo y complícalo con la ausencia de garantía de que la persona que entrega el código para unificar está cien por ciento segura de que es su última version final final final funcional.

Así fue como pasaron mis años de universidad y los proyectos que en ese tiempo desarrollé. Eventualmente, como todo respaldo que ya no se usa, perdí y/o eliminé esos códigos.

En el trabajo

Ahora que conoces mi totalmente cuestionable método de control de versiones, su efectividad y problemas, solo me limitaré a contarte que lo usé con algunas variaciones desde 2005 hasta 2014 en todos los proyectos donde tenía que gestionar el código fuente yo, tanto el código como otros archivos relacionados, fueran documentos, matrices, imágenes, etc.

Para esos años, ya había ofertas de controladores de versiones, ¿cuál era la excusa entonces para no usarlos?

1. Desconocía que existían.
2. Internet no era tan barato y accesible como en estos años, al menos no hasta 2010/2011, por lo que obtener información acerca de ellos no estaba al alcance.
3. El equipo con quien trabajaba tampoco conocía los controladores de versiones.
4. Cuando supimos de sus existencia había: CVS (que no entendíamos), Subversion (en una versión básica que tampoco entendíamos) y Source Safe de Microsoft, que entendíamos un poco, pero su costo estaba fuera de nuestro presupuesto y tampoco se integraba con la plataforma que usaba (4GL, UNIX).

En 2014 GIT llegó a mí de mano de dos de los colegas, pero para ser totalmente franco, no entendí la filosofía y me parecía que era lo mismo que yo hacía con mis carpetas fechadas, pero mucho más engorroso porque además tenía que ejecutar comandos que no hacían mucho sentido. Mientras trabajé con ese equipo, seguí la corriente, pero era tan torpe mi colaboración y tan nulo mi entendimiento de GIT, que no lograba hacer un commit sin ayuda.

En 2015 conocí Subversion 5 (creo) y este controlador ya me hizo sentido. Veía las diferentes ramas, los repositorios, los cambios de cada persona en cada archivo específico, los archivos que cambiaron con el registro temporal de cuándo sucedieron, comparaciones entre la versión anterior y la nueva. Todo un mundo nuevo que mis carpetas fechadas y mi sistema basado en la confianza de mi memoria no podían resolver.

No obstante, uno de los principales problemas de Subversion, y con esto no quiero decir que sea inherente al software (bien podría ser por la forma como se usaba), es que si dos personas estaban usando un mismo archivo de código fuente (totalmente natural en un equipo de más de 5 personas en un mismo sistema que sufre cambios y adecuaciones constantemente), Subversión no detectaba conflictos, es decir, registraba el cambio de versión conforme esta se iba cargando, y los cambios que permanecían eran los de la última persona que había registrado modificaciones en el sistema, lo que coloquialmente conocemos por “planchar los cambios de alguien más”. Esta limitante la resolvimos con el viejo “voy a usar el archivo TAL, ¿alguien lo está modificando?”. Si había modificaciones corriendo, las alternativas eran:

• Esperar a que la otra persona terminara
• La otra persona liberaba el archivo para luego integrar sus cambios, o,
• Alguno de los dos se hacía cargo de las modificaciones de ambos.

En 2017, uno de los integrantes de mayor calibre del equipo sugirió el cambio a GIT. La mitad del equipo (o más) ya lo conocían y favorecieron el cambio. Yo estaba renuente al cambio por mi anterior experiencia; sin embargo, en ese momento yo estaba a cargo de la gestión y no de la ejecución, por lo que accedí al mismo. El equipo me enseñó nuevamente cómo se usaba y funcionaba GIT, así que poco a poco lo fui asimilando y vi las ventajas que tenía sobre Subversion.

En 2020 me separé del trabajo y el cargo que desempeñaba entonces y entré a laborar en otra empresa. Ahí estaba de nuevo GIT acechando. Esta vez, sin embargo, sí entré a operar directamente con el código fuente así que GIT no era opcional, y aquí es a donde todo este parloteo encuentra su razón de ser.

Todos los inconvenientes que encontré con mi gestión de carpetas fechadas y las limitantes de Subversion, son resueltos con GIT si se usa de forma adecuada, tanto en trabajo individual como en equipo. Lo único que no se resuelve sea con GIT, CVS, Subversion y cualquier otro software son estos obstáculos:

Falta de disciplina. Si tú o tu equipo de trabajo no tienen la disciplina de usar el versionador en tiempo y forma, no importa cual se use, la gestión del código fuente será un desastre y origen de numerosos errores y retrabajos.

Desinterés. Sea que te muestren o tengas que aprender a usar el software por tu cuenta, si no te comprometes a usarlo, entender para qué sirve y velar por usarlo bien, da lo mismo tener o carecer del software.

Para cerrar esta crónica, te sugiero que aprendas GIT, pero no partas de los comandos o por la teoría de qué es. Vuelve a leer todos los problemas que he descrito para manejar código fuente e identifica los que has tenido; GIT se hizo pensando en cómo resolver esos y otros problemas comunes, abórdalo como la solución a esos problemas y lo verás de una manera distinta, te será más fácil comprender la filosofía detrás y memorizar los comandos. Piensa además, que de momento, es el estándar de la industria (con tendencia a mantenerse) y una habilidad técnica solicitada en las ofertas de empleo. Aprender GIT no te sobra.

Sin más por el momento, hagamos commit de la crónica.