Git para quien no programa

Dos preguntas para empezar.

Una: ¿no te has fijado que los programas dicen versión 10.2, o 10.0.1? Un número más grande significa que es más nuevo, pero ¿cómo deciden si el cambio va en el primer punto o en el segundo?

Y dos, la doméstica: ¿por qué acabas con documento_v1, documento_v2, documento_v3_final y documento_v3_final_bueno?

Las dos se contestan con lo mismo, y creo que es una herramienta que le sirve a cualquiera. Si trabajas en una oficina y usas documentos, te va a ayudar a regresar a cambios anteriores y a tener un solo archivo con toda su historia: quién agregó qué, cuándo y por qué.

Qué resuelve un control de versiones

Cuando varias personas escriben en los mismos archivos —código, sí, pero también un libro, o una contabilidad donde cada quien lleva sus registros— necesitas saber quién hizo los cambios, cómo, qué cambió realmente, cuándo, y sobre todo por qué.

Todo eso lo registra el sistema y queda disponible para cualquiera que tenga acceso. Y cambia una palabra: a la carpeta ya no le llamamos carpeta, le llamamos repositorio.

Por qué git

Es gratis. GitHub tiene una de las comunidades más grandes que existen y ayuda muchísimo a los proyectos de código abierto: una especie de Wikipedia, pero para código.

Y la tecnología que usa —git— la creó la misma persona que creó Linux, Linus Torvalds. (En el episodio dije "Linux Torvalds", confundiendo el nombre con el del sistema operativo.)

Voy a ser honesto sobre la barrera: si no te gustan este tipo de cosas, Linux puede ser un problema, y git también lo es al principio. Pero una vez que le entiendes, en verdad vale mucho la pena.

El ciclo personal, en cinco comandos

git init — Le dices al sistema: aquí va a haber algo cuya evolución quiero medir.

git add — Añades los archivos que quieres registrar. Hay instrucciones para tomar todos los de una carpeta de una vez.

git commit — Registras una entrada, con un mensaje que dice qué está pasando. Casi siempre el primero es se inició el proyecto. Ésa es la primera semilla de toda la historia.

git status — Es una conversación con el repositorio. Oye, dime cómo estás. Y te contesta: estos archivos no los has registrado, éstos ya los modificaste, éstos los borraste, éstos los moviste de lugar.

git checkout — Cada entrada tiene un ID, unos ocho caracteres. Lees tus mensajes, encuentras el que dice capítulo 2 terminado, pones el numerito, y todo lo que tenías en ese momento regresa a tu carpeta.

Ese último es el que realmente cambia cómo trabajas, y no por la razón técnica.

El ciclo remoto, y una regla de higiene

Para trabajar con otras personas necesitas un repositorio remoto. GitHub te lo guarda; es como un Dropbox para este tipo de históricos. Creas la cuenta, creas el repositorio, y con git clone haces una copia en tu computadora. Cualquiera puede clonar lo que sea público.

git push empuja tus cambios a la nube. git pull los jala.

Y algo importante: no es automático. Tú decides exactamente cuándo. Y eso es deseable, porque quieres control sobre qué versión es estable y en qué momento metiste un error.

La regla de higiene, que cuesta agarrar: primero jala, luego trabaja.

Si empiezas a hacer cambios antes de jalar, entras en conflictos con mucha más facilidad. Y peor: ¿qué tal si alguien más ya escribió esa parte, ya hizo ese capítulo, y estás duplicando el trabajo? Al final del día, empuja. Porque si no empujas, los demás no lo van a poder ver.

Conflictos

¿Qué pasa si los dos trabajamos en el mismo archivo, en la misma línea?

El programa te avisa: aquí hay dos versiones de lo mismo, elige. Borras la que no y te quedas con la que sí. A veces se complica —en código tienes que decidir cuál es mejor; en un libro, qué frase suena mejor, o si las combinas.

Pero lo importante es que te avisa. Trabajando sin control de versiones eso puede tardar muchísimo en descubrirse, puede provocar discusiones interminables, o —peor— puede que ni siquiera te des cuenta de que los dos modificaron lo mismo.

Ramas: permiso para probar ideas que pueden morir

¿Qué tal si quieres explorar un capítulo que no sabes si vas a incluir? ¿O una característica que no sabes si va a funcionar? ¿Cambiar un color, cambiar unas frases, meter una historia pequeña dentro de la historia principal?

Para eso están las ramas (git branch). Piénsalo así —no pasa exactamente— pero supongamos que se hace una copia de tus archivos, y en esa copia trabajas.

Si la idea prospera, la combinas con la principal (git merge). Si no, la borras, y de preferencia bórrala de verdad, porque si no acabas con un montón de cosas que nunca vas a usar.

Lo que las ramas te dan no es técnico: es permiso para intentar algo que probablemente no funcione, sin arriesgar lo que ya sirve.

Ahora sí, los numeritos

Aquí conviene que hagas una pausa. Instala git —funciona en Linux, Mac y Windows—, juega un rato: haz un archivo, cámbialo, haz otra entrada, cámbialo otra vez. Con esa práctica encima, lo que sigue tiene mucho más sentido.

Todo el flujo de ramas, el de Vincent Driessen, explicado con un libro en vez de con código: la rama pública, la de desarrollo, las de prueba, la de liberación y las de corrección urgente. Y de ahí sale de dónde viene cada uno de los tres numeritos.

Ahí también está la respuesta a algo que a todos nos ha pasado: corrigen un error, ya funciona, actualizas, y el mismo error vuelve a aparecer.

Y lo que más me importa de todo esto

Que sirve mucho más allá de programar.

Una tesis. Un libro. Tu registro de compras: tengo este dinero ahorrado, voy a hacer estas compras, me va quedando esto. Y de pronto se te ocurre algo: ¿qué pasaría si compro esto otro? Haces una rama, desarrollas ese plan, ves el resultado, y decides si lo pasas a tu plan principal o si simplemente muere porque no era buena idea.

Saber que cometiste un error y que lo puedes corregir rápido. Tener el histórico de cómo pensaste, sin anotarlo a mano y sin cargar todo en la cabeza al mismo tiempo.

No es sencillo entrarle. Pero si le entras, te quita muchísimos dolores de cabeza.

Este texto sale del episodio 014 del Podcast Algoritmos, grabado a las dos semanas y media de haberme mudado a Zlín. De ese mismo intermedio salió otro texto que no tiene nada que ver con git.