Hace unos años, el dueño de una pequeña empresa me contó sobre un freelancer que había contratado para hacer su sitio web. El trabajo estaba bien hecho. El sitio salió, se veía profesional y traía clientes nuevos. Hasta que una mañana, el freelancer le mandó una foto de la ventanilla rota de su auto. Le habían robado la mochila con la notebook del asiento delantero mientras compraba un café.

Al principio, el dueño no se preocupó. Una notebook robada es problema del freelancer, ¿no? Pero después hizo una pregunta que cambió todo: "¿Tenés una copia del código de mi sitio guardada en otro lado?" El freelancer se quedó callado. La respuesta era no. Cada archivo, cada versión, cada arreglo de madrugada existía únicamente en esa máquina. Si no hubiera aparecido (apareció, unos días después, en una casa de empeño de otra ciudad), la empresa habría tenido que rehacer el sitio entero desde cero.

Ese susto es más común de lo que la mayoría de los dueños de negocio se imagina. Y deja una pregunta que vale la pena hacerse sobre tu propio sitio o software, ahora mismo: si a la persona que lo hizo se le pierde la notebook mañana, ¿tu código sobrevive?

Dónde Vive Realmente el Código de tu Sitio

La mayoría de los dueños de negocio nunca se hace esta pregunta, porque nunca piensa el código como algo que "vive" en algún lugar físico. Vos pensás tu sitio web como lo ves: una página en el navegador. Pero detrás de esa página hay una carpeta llena de archivos de texto, escritos por una persona, guardados en una computadora.

Si esa carpeta solo existe en una notebook, tu sitio es exactamente tan seguro como esa notebook. Un café derramado, un disco rígido que falla, un robo, o un desarrollador que borra por error la carpeta equivocada pueden hacerlo desaparecer en segundos. Nada hace copias en segundo plano a menos que alguien lo haya configurado a propósito.

Esto es fácil de pasar por alto porque, en el día a día, nada se ve frágil. Tu sitio funciona bien. Carga rápido. Los clientes te encuentran por Google. Nada de eso te dice cuántas copias del código existen, ni dónde están. En este caso, la fragilidad queda invisible hasta el día en que deja de estarlo.

Qué Hace Realmente el Control de Versiones

La solución a esto existe desde hace décadas, y es más simple de lo que suena. Se llama control de versiones (Git es la herramienta más usada hoy en día), y hace dos cosas que te importan como dueño de negocio, aunque nunca mires una línea de código.

Primero, guarda un historial completo de cada cambio. Cada vez que un desarrollador termina una parte del trabajo, guarda una fotografía de todo el proyecto en ese momento, junto con una nota corta sobre qué cambió y por qué. Si una actualización nueva rompe algo, el desarrollador puede volver exactamente a la versión que funcionaba, en vez de adivinar cómo llegar de nuevo a algo estable. Nada se pierde ni se sobrescribe. Todo queda sumado a esa línea de tiempo.

Segundo, y tan importante como lo anterior, mantiene copias sincronizadas del proyecto en más de un lugar. Un desarrollador que usa control de versiones suele tener una copia completa del código en su propia notebook, y otra copia completa guardada en un servidor remoto, alojado por un servicio como GitHub, GitLab o Bitbucket. Cuando termina una parte del trabajo, la "sube" a esa copia remota. Si mañana le roban la notebook, el código no desaparece. Queda guardado a salvo en ese servidor, con todo su historial, listo para bajarse a cualquier computadora nueva.

Eso es el valor real, en criollo: un historial que podés rebobinar, y copias que no viven todas en el mismo lugar.

Un Ejemplo Simple y Cotidiano

Imaginá la página de pedidos online de una panadería. Una desarrolladora agrega una función para que los clientes elijan un horario de retiro. La prueba, y algo en ese cambio rompe el botón de pago en los celulares. Con control de versiones, volver a la versión de esa misma mañana toma minutos. Sin eso, alguien tiene que buscar a mano entre el código roto y adivinar qué líneas deshacer, esperando recordar cómo era antes. Un camino es un arreglo rápido. El otro es una tarde de estrés, con el sitio caído mientras los clientes intentan hacer pedidos.

La Única Pregunta que Vale la Pena Hacerle a Cualquier Desarrollador

No necesitás entender de control de versiones para protegerte. Solo necesitás hacer una pregunta, desde el principio, a quien construya o mantenga tu sitio o software: "¿Dónde vive el código, y puedo ver que hay una copia de respaldo en un segundo lugar?"

Un desarrollador seguro de su trabajo va a tener una respuesta rápida. Te va a mostrar un repositorio privado (así se llama técnicamente una de esas copias remotas) en una plataforma como GitHub o GitLab, y por lo general puede agregarte a vos o a alguien de tu empresa como espectador de esa cuenta, sin que haga falta saber programar. Si la respuesta es vaga, o el código solo existe en su computadora personal, eso vale la pena resolverlo antes de que se convierta en un problema, no después.

Esta pregunta es distinta de quién es dueño legal del código, algo de lo que escribí por separado en qué significa realmente ser dueño de tu código fuente. También es distinta de tu plan general de recuperación ante desastres, que cubrí en por qué toda empresa necesita un plan de continuidad de software. Esta pregunta es más chica y más básica: ¿existe hoy más de una copia funcional del código, con un historial detrás?

Por Qué Esto Es un Seguro Barato

Acá está la parte que debería hacer esto una decisión fácil. Configurar control de versiones cuesta casi nada. GitHub y GitLab ofrecen repositorios privados gratuitos para proyectos chicos, y hasta los planes pagos cuestan unos pocos dólares por mes. Cualquier desarrollador que valga la pena contratar ya lo usa como parte normal de su trabajo, igual que un contratista guarda los recibos y los planos. No debería ser un pedido especial. Debería ser algo dado por sentado.

La historia de la notebook robada tuvo un final con suerte. Al freelancer le devolvieron la mochila unos días después. Pero la suerte no es un plan de respaldo, y no deberías tener que descubrir de la peor manera si el código de tu sitio existe en más de un lugar.

Si no estás seguro de cómo está armado tu propio sitio o software, esa es una charla corta y sin riesgo para tener. Hablemos de su situación.