El futuro del control de versiones quizá no se parezca a Git
Usamos Git de forma casi automática: commit, rebase, merge, push. Funciona, es rápido y es omnipresente.
Pero también es complejo, poco indulgente con los errores y basado en conceptos que no han cambiado demasiado en casi veinte años.
En 2025, empiezan a aparecer señales claras de que el control de versiones puede evolucionar y una de las más interesantes es Jujutsu, también conocido como JJ.
Git sigue siendo el estándar, pero ya no es incuestionable
Git resolvió un problema enorme en su momento, control de versiones distribuido, rápido y fiable.
Eso no ha cambiado, pero lo que sí ha cambiado es el contexto:
- Equipos más grandes
- Flujos más complejos
- Trabajo distribuido real
- Necesidad de reescribir historia con frecuencia
- Miedo constante a perder trabajo
Git funciona bien cuando todo va según lo previsto, pero cuando algo se tuerce, la experiencia se vuelve frágil. Y es aquí donde JJ parte de una idea sencilla: el control de versiones no debería castigar el error.
Qué es Jujutsu (JJ)
JJ es un sistema de control de versiones distribuido, compatible con Git, pero no limitado por su modelo mental.
No es:
- Un wrapper
- Un cliente gráfico
- Un reemplazo inmediato de Git
Es un sistema nuevo que:
- Puede leer y escribir repositorios Git
- Puede trabajar con GitHub, GitLab o repos remotos existentes
- Permite convivir con equipos que siguen usando Git
No exige migraciones ni cambios de infraestructura.
La diferencia clave de JJ vs Git
En Git, reescribir código siempre implica riesgo commits perdidos, ramas rotas y force-pushes peligrosos.
En JJ, el código es mutable por diseño, eso significa que:
- Los commits se pueden editar sin miedo
- Nada se pierde realmente
- Existe un historial de operaciones, no solo de resultados
Reescribir codigo deja de ser una operación delicada y pasa a ser algo cotidiano. Esto cambia completamente cómo se afrontan la limpieza de commits antes de una PR o las correcciones tardías.
Branches que dejan de hacer demasiadas cosas
En Git, las ramas cumplen demasiados roles a la vez ya que identifican commits, representan trabajo, definen flujos y se sincronizan con remotos.
JJ simplifica esto con bookmarks, ya que un bookmark es solo un puntero fácil de mover, fácil de renombrar, fácil de eliminar y siempre consistente aunque cambie la historia.
No intenta imponer reglas de workflow y no arrastra complejidad innecesaria.
Para muchos desarrolladores, es lo que las ramas de Git deberían haber sido desde el principio.
Revsets: consultar la historia como debería ser
Git permite consultas complejas, pero su sintaxis es difícil y poco intuitiva.
JJ introduce revsets, un sistema declarativo para seleccionar commits por autor, por mensaje, por antigüedad y por relaciones lógicas.
Para quien trabaja a diario con repositorios grandes, esto marca una diferencia real.
Conflictos menos opacos, menos destructivos
Los conflictos en Git suelen aparecer como un error que hay que resolver rápido y con cuidado.
JJ los trata como estado persistente ya que el conflicto vive dentro del archivo, no desaparece hasta resolverse y el sistema entiende la estructura del conflicto.
Esto reduce errores y facilita el trabajo en ramas largas o con muchos cambios concurrentes.
Un log de operaciones, no solo de commits
Git muestra el estado final del repositorio, no muestra cómo se llegó hasta ahí, algo imprescindible para el mantenimiento a largo plazo de tu proyecto.
JJ mantiene un log de operaciones con el que puedes deshacer acciones, volver a estados anteriores y entender qué cambios hiciste y en qué orden.
Esto introduce algo que Git nunca tuvo de forma clara: seguridad psicológica.
Compatibilidad total con Git: adopción sin fricción
Uno de los puntos más importantes de JJ es que no obliga a nadie a cambiar.
Puedes usar JJ localmente, seguir empujando a repos Git y trabajar con equipos que no saben ni qué es JJ. Por lo que esto permite adopción progresiva, sin fricción organizativa.
Es una de las razones por las que ya se está usando en Google, Canonical y otros equipos centrados en developer experience.
Lo que JJ todavía no resuelve
JJ no es perfecto, ya que todavía es una comunidad pequeña, menos tooling alrededor, la curva de desaprendizaje para usuarios de Git puede ser compleja y el ecosistema está aún en crecimiento.
Algo normal en una herramienta joven, pero esto no invalida el cambio conceptual que propone.
El control de versiones también puede evolucionar
Git no va a desaparecer, seguirá siendo la base del desarrollo de software durante muchos años, pero eso no significa que sea la forma definitiva de hacer control de versiones.
JJ introduce una idea importante, el control de versiones debería facilitar el trabajo, no añadir tensión.
Más seguridad. Menos miedo. Más flexibilidad.
Conclusión
Si Git te funciona y nunca te ha generado fricción, probablemente JJ no sea prioritario. Pero si reescribes historia a menudo, trabajas en repos grandes, te has peleado demasiadas veces con rebase y sientes que Git te castiga por equivocarte, entonces JJ merece atención.
No como sustituto inmediato de Git, sino como señal de que el control de versiones puede ser mejor.
Y eso, en un ecosistema tan estable como este, ya es una noticia importante.
Referencias:
· If You Use Git Daily, Google’s Jujutsu (JJ) Might Change Everything