El punto de control

Cuando explico git, la parte que suena más aburrida es git checkout. Suena a trámite: sirve para regresar a una versión anterior.

Y es, con mucho, lo que más cambió cómo trabajo. No por lo que hace, sino por lo que te permite dejar de hacer.

El mecanismo, rápido

Cada entrada que registras tiene un ID —unos ocho caracteres. Revisas la lista de tus mensajes, encuentras el que dice capítulo 2 terminado, escribes git checkout con ese número, y todo lo que tenías en ese momento regresa a tu carpeta.

Si dejaste cambios sin guardar, ésos sí se pierden. Pero todo lo que sí registraste vuelve tal cual.

El escenario obvio

Aquí le puse capítulo 2 terminado, después borré algo por error, o se fue la luz, o el archivo quedó mal y ya no sirve. Vuelves a la entrada y listo.

En código pasa constantemente: metes ciertos comandos y de pronto ya nada funciona, y no sabes desde cuándo.

El escenario que sí importa

Pero ése no es el valor. El valor está antes de que nada falle.

Siempre vale la pena tener ese punto de control donde sabes que todo funcionaba, y de ahí seguir haciendo cambios sin preocuparte.

Ésa es la frase completa, y la parte que cuenta es sin preocuparte.

Sin punto de control, cada cambio tiene un costo emocional. Vas con cuidado. Haces sólo lo mínimo. Antes de tocar algo que funciona, lo piensas dos veces. Guardas copias por si acaso, con nombres que a la semana ya no significan nada. Y sobre todo: no pruebas la idea rara, esa que probablemente no va a funcionar pero que quizá sea mucho mejor.

Con punto de control, el peor escenario de cualquier experimento es "pierdo la última media hora". Y con ese piso, de pronto puedes hacer cambios grandes, borrar cosas, reescribir un capítulo entero para ver cómo queda.

No es una herramienta de recuperación

Es una herramienta de atrevimiento.

Casi nunca uso checkout para recuperar algo. Lo uso poquísimo. Pero uso todo el tiempo el hecho de que existe.

Es lo mismo que pasa con las ramas: lo que te dan no es un mecanismo, es permiso para intentar algo que probablemente no funcione.

Y sirve igual para un texto, una tesis o un presupuesto que para código. Lo que cambia no es lo que estás escribiendo. Es cuánto estás dispuesto a arriesgar mientras lo escribes.

Este texto sale del episodio 014 del Podcast Algoritmos, sobre git para quien no programa.