Un commit en el lugar equivocado

Ayer, mientras Javier ordenaba el repositorio de la corporación, pasó algo pequeño. Un commit —el material completo de un curso del diplomado que está cursando— aterrizó en el branch equivocado. No en la rama de estudios, donde correspondía, sino en una rama de otro proyecto distinto.

No fue un desastre. Git tiene herramientas para esto: un cherry-pick para llevar el commit a su lugar, un reset para limpiar el rastro. Veinte minutos y el árbol quedó como debía estar. La mayoría lo habría dejado ahí: incidente resuelto, a seguir.

Javier no lo dejó ahí. Hizo la pregunta incómoda: ¿por qué pasó?

El branch es del directorio, no de la sesión

La respuesta tenía que ver con cómo estaba trabajando. La corporación no es un solo proyecto: es la web, las landing pages, un backend de finanzas personales, el material del diplomado, un trabajo de gobierno de datos, los agentes de IA. Todo conviviendo en un mismo repositorio. Y todo ese trabajo se hacía desde una sola carpeta.

El problema es sutil pero estructural. En git, la rama activa no le pertenece a tu sesión de trabajo: le pertenece al directorio. Si tienes una sola carpeta y dos ventanas abiertas, la rama “salta” sin avisar. Crees que estás parado en un sitio y estás en otro. El commit equivocado no fue un descuido —fue el resultado previsible de una herramienta usada de una forma que no escala.

Arreglar el commit era arreglar el síntoma. La causa era otra: la rama nunca debió ser un estado global y compartido.

Construir el camino, no solo despejarlo

Acá la sesión cambió de tono. En lugar de seguir con la lista de tareas, Javier convocó a Linus —el estratega de repositorios de la corporación— con una pregunta más grande: diseñar la forma correcta de empezar y terminar una sesión de trabajo. Que el orden no dependiera de la memoria ni de la suerte.

Lo que salió tiene tres piezas.

La primera son los worktrees. Git permite que un mismo repositorio tenga varias carpetas de trabajo, cada una anclada a su propia rama. Un proyecto, una carpeta, una rama —de forma física, no por convención. El branch deja de “saltar”: cada proyecto vive aislado. El accidente de ayer se vuelve imposible, no improbable.

La segunda es un protocolo de sesión. Dos rituales, simples y repetibles. Al abrir el día, un comando que dice en qué proyecto estás parado, sincroniza el código y recuerda dónde quedaste. Al cerrarlo, otro que ordena el trabajo en tres fases: primero asegura el código en git, después actualiza los sistemas de gestión, y solo al final, si vale la pena, escribe la historia pública del día. El orden importa: primero se guarda lo hecho, después se cuenta.

La tercera es una salvaguarda en tres capas. Una avisa al inicio si estás en la rama equivocada. Otra —la más importante— bloquea directamente un commit si detecta que va a caer donde no debe. Y la tercera es el aislamiento de los worktrees, que ataca la raíz. Cinturón, tirantes, y un diseño que no necesita ninguno de los dos.

Lo que de verdad se construyó

Al cierre del día el sistema estaba completo: dos comandos de sesión, tres validaciones automáticas, un documento que explica el protocolo entero, y una convención clara para nombrar el trabajo. Cuatro commits, una solicitud de cambios abierta para revisarlo con calma antes de adoptarlo.

Nada de esto le agrega una función a un producto. Ningún usuario lo va a ver. Es infraestructura invisible —el tipo de trabajo fácil de posponer para siempre, porque nunca es urgente hasta que un commit se pierde en serio.

La diferencia que importa

Hay una distancia enorme entre arreglar un bug y arreglar que el bug pueda existir. La primera te devuelve al punto de partida. La segunda te mueve a un punto de partida mejor.

El commit perdido costó veinte minutos. El protocolo que lo reemplaza costó una tarde. Pero esa tarde compró algo que los veinte minutos no compraban: la certeza de que el problema no vuelve. A veces el trabajo más importante del día es el que nadie te pidió.