08.10.2026 · Signal Titans Editorial
Cuando BitKeeper dejó de servir, Linus Torvalds construyó Git
En 2005, la comunidad del kernel de Linux perdió el acceso gratuito a la herramienta de control de versiones que había ayudado a coordinar un flujo cada vez mayor de cambios. Linus Torvalds no respondió buscando simplemente el sustituto menos malo. Detuvo durante un breve periodo el trabajo del kernel para construir una herramienta nueva.
Esa herramienta se convirtió en Git. La versión popular de la historia destaca que su primera implementación apareció en unos diez días. Sin embargo, la parte más útil es otra: la desaparición de una dependencia obligó a Torvalds a definir con precisión qué necesitaba un sistema de control de versiones para un proyecto distribuido y enorme.
Git no nació porque Torvalds soñara con diseñar software de control de versiones. Años después explicó casi lo contrario. No le interesaba especialmente esa categoría de herramientas. Estaba dispuesto a dejar que otro sistema resolviera el problema mientras cumpliera con las exigencias del kernel.
El problema antes de Git
Durante buena parte de los primeros años de Linux, los cambios circulaban como parches y archivos comprimidos. Ese proceso era manejable cuando el proyecto era más pequeño, pero el número de colaboradores, mantenedores y líneas de desarrollo creció con rapidez.
En 2002 el proyecto empezó a utilizar BitKeeper, un sistema distribuido pero propietario. Su modelo aportaba una ventaja decisiva: cada desarrollador podía trabajar con un repositorio local y después intercambiar y fusionar cambios sin depender de una única copia central. Torvalds reconoció más tarde que esa experiencia cambió su manera de pensar sobre el control de versiones.
La relación, sin embargo, siempre resultó incómoda para parte de una comunidad de software libre. El uso gratuito dependía de las condiciones de una empresa. En 2005, tras un conflicto relacionado con el análisis del protocolo de BitKeeper por Andrew Tridgell, ese acuerdo terminó. El kernel necesitaba otra solución.
Convertir la crisis en una especificación
Torvalds empezó por las limitaciones reales del trabajo. La nueva herramienta debía ser rápida, admitir miles de ramas y líneas de desarrollo, funcionar de forma totalmente distribuida, proteger la integridad de los datos y manejar un proyecto del tamaño de Linux sin convertir el propio sistema de control de versiones en un cuello de botella.
Esas exigencias explican varias decisiones de Git que al principio parecen extrañas. Cada clon contiene un repositorio completo. Muchas operaciones son locales y, por tanto, rápidas. Las ramas son ligeras porque el desarrollo no lineal no era una excepción: era la rutina diaria del kernel.
El movimiento importante no fue inventar comandos llamativos. Fue describir honestamente la carga de trabajo y diseñar alrededor de ella.
Lo que realmente se construyó
La primera versión de Git era pequeña y poco amable. Torvalds se concentró en los mecanismos fundamentales para almacenar contenido, identificar objetos, registrar historia, intercambiar cambios y comprobar su integridad. La capa de comandos más cómoda y muchas mejoras llegaron después, con Junio Hamano como mantenedor de largo plazo.
Por eso, decir que “Git se escribió en diez días” puede inducir a error. En ese periodo surgió una base funcional, no el producto maduro que millones de desarrolladores conocen hoy. La arquitectura inicial respondió a una emergencia; la comunidad la convirtió después en una infraestructura duradera.
El modelo distribuido también redujo una parte de la política alrededor de quién podía experimentar. Cualquier desarrollador podía crear ramas o conservar su propio repositorio. La autoridad seguía siendo necesaria para decidir qué entraba en la versión oficial, pero el sistema no obligaba a pedir permiso para empezar a trabajar.
Cuatro ideas que siguen siendo útiles
Primera: una dependencia técnica puede ser un riesgo estratégico. Una herramienta excelente deja de ser neutral si el acceso depende de condiciones que tu proyecto no controla.
Segunda: la escala redefine lo aceptable. Una solución suficiente para un equipo pequeño puede fallar cuando miles de cambios se producen en paralelo.
Tercera: las restricciones ayudan a aclarar la arquitectura. Velocidad, distribución e integridad no fueron extras; fueron el centro del diseño.
Cuarta: una base correcta puede importar más que una interfaz pulida. Git empezó siendo difícil, pero resolvía problemas estructurales que podían mejorarse en capas posteriores.
La lección no son los diez días
La historia se cuenta a veces como prueba de que un programador brillante puede construir cualquier cosa casi de inmediato. Esa lectura ignora los años de experiencia con el kernel, las lecciones de BitKeeper y el trabajo posterior de una comunidad enorme.
La lección más duradera es otra. Cuando desapareció una dependencia crítica, Torvalds no preguntó qué alternativa se parecía más a lo anterior. Preguntó qué exigía realmente el trabajo.
Cuando un equipo reemplaza una pieza de infraestructura, esa sigue siendo una buena pregunta: ¿estamos buscando algo familiar o algo que refleje cómo trabaja de verdad nuestro sistema?
SIGNAL TITANS