GOT, el companion de Git que suma el contexto que falta

GOT es una capa para desarrolladores que se monta sobre Git, lanzada en su versión 1.0 el 14 de junio de 2026 por el desarrollador Supun Hewagamage. No reemplaza a Git ni lo modifica: agrega el contexto que Git deja afuera, como el porqué de cada decisión y qué archivos pertenecen a cada feature. Si alguna vez intentaste entender una base de código ajena, sabés de qué hablo. GOT, esta herramienta para Git, apunta a ese dolor concreto.

GOT es una herramienta de línea de comandos open source, escrita en Go, que se instala sobre un repositorio Git existente. Guarda metadatos (workspaces, decisiones de arquitectura, notas y puntos de recuperación) en un directorio aislado llamado .got/, sin tocar el historial ni los commits de Git. Tus compañeros pueden seguir usando Git puro y nada se rompe.

¿Por qué Git no responde ciertas preguntas?

Ponele que entra alguien nuevo al equipo. Abre git log, ve 800 commits, y la primera pregunta que larga es: “¿cuáles de estos archivos son del feature de auth?”. Git no tiene idea. Git es brillante para trackear qué cambió. Lo que no sabe es por qué.

Esa es la grieta que describe Hewagamage en su posteo de lanzamiento en dev.to. Git no sabe que esos 12 archivos forman el módulo OAuth, ni que el equipo eligió JWT sobre sesiones allá por marzo, ni que el nuevo debería leer el módulo de auth antes de meter mano en la API. Toda esa información existe, pero está enterrada en hilos de Slack, en la cabeza de alguien que ya no está, o en ningún lado.

El resultado lo conocés: el junior arranca a leer código a ciegas, pregunta lo mismo tres veces, y pierde días en algo que un párrafo de contexto resolvía en minutos. Cubrimos ese tema en detalle en optimización en pipelines CI/CD.

¿Cómo funciona GOT como capa sobre Git sin invadirlo?

Acá está lo interesante: GOT no forkea Git, no toca sus internals y no reescribe commits. Es una capa fina que vive al lado. Según el anuncio, cinco principios guiaron cada decisión de diseño:

• Git es la fuente de verdad. GOT nunca modifica Git de formas que vos no pediste.
• La metadata está aislada. Todo va al directorio .got/. Lo borrás y Git no se entera de nada.
• Offline-first. Sin llamadas de red, salvo las que vos iniciás a propósito.
• Arquitectura de plugins. Pensado para extenderse sin parchear el core.
• Recuperable. Las operaciones destructivas crean un punto de recuperación automático primero.

La consecuencia práctica de esto es que adoptarlo no es una decisión de equipo. Lo instalás vos, en tu máquina, y listo. Si no convence, lo sacás y el repo queda igual que antes.

¿Qué features trae GOT v1.0?

La 1.0 no es un MVP pelado. Estas son las capacidades que Hewagamage lista como confirmadas en el lanzamiento:

Workspaces

Agrupás archivos, branches, decisiones y PRs en contextos lógicos. En vez de “estos archivos sueltos”, tenés “el feature de OAuth y todo lo que lo toca”. Más contexto en herramientas de automatización Git.

ADRs (registros de decisiones de arquitectura)

Decisiones estructuradas, vinculadas a commits y código. Ese “por qué elegimos JWT” deja de vivir en un hilo de Slack que nadie encuentra y queda atado al lugar donde importa.

Notas, guided sessions e integración con GitHub

Las notas son contexto rápido que queda pegado al trabajo. Las guided sessions arman recorridos para que el nuevo no tenga que “leer el código y arreglárselas solo”. Y desde la terminal manejás PRs e issues sin saltar al navegador.

Snapshots y comandos seguros

Antes de una operación destructiva, GOT crea un punto de recuperación automático. ¿Hiciste un reset --hard de los que duelen? Hay red de contención. Los comandos con guardrails (reset, push, rebase) intentan que no te pegues un tiro en el pie.

¿En qué se diferencia de Git? ¿Lo reemplaza?

No, y el autor es enfático con eso (está hasta en el título del posteo). Git sigue siendo obligatorio; GOT es la capa de contexto encima. Esta tabla lo deja claro: Complementá con la guía de hreflang para repositorios multiidioma.

Aspecto	Git	GOT
Qué hace	Trackea cambios e historial	Suma contexto, decisiones y seguridad
Responde	Qué cambió y cuándo	Por qué y para qué feature
Dónde guarda datos	En el repo (commits)	En .got/, aislado
Adopción	Obligatoria para todos	Opcional por desarrollador
Operaciones destructivas	Sin red automática	Snapshot previo automático

La forma de pensarlo: Git te muestra un commit. GOT te muestra por qué existe ese commit, a qué feature pertenece y qué ADR lo respaldó.

¿Dónde aporta más valor en el día a día?

Hay cuatro escenarios donde la cosa se nota:

• Equipo que crece: cada incorporación nueva multiplica la fricción de onboarding. Los workspaces y las guided sessions cortan esa curva.
• Decisiones de arquitectura frecuentes: si todo el tiempo discutís “por qué hicimos X”, los ADRs evitan que esa memoria se evapore.
• Miedo a romper algo: los snapshots automáticos dan margen para experimentar sin sudar frío.
• Flujos sobre GitHub o Git autoalojado: manejás issues y PRs sin salir de la terminal.

Sobre lo último: si corrés tu propio servidor Git (Gitea, GitLab self-hosted o lo que sea) sobre infraestructura propia, GOT no te obliga a cambiar nada del setup. Para ese tipo de servidores, un VPS en donweb.com alcanza y sobra, y GOT se monta encima sin pedir permiso a nadie.

¿Cómo lo instalás y empezás a usarlo?

Al estar hecho en Go, GOT se distribuye como binario multiplataforma para macOS, Linux y Windows. El flujo conceptual del día uno es simple: lo inicializás sobre un repo que ya tiene Git, creás tu primer workspace para el feature en el que estás, registrás las decisiones que vayas tomando y dejás que los snapshots corran solos antes de cada operación riesgosa.

Lo importante: nada de esto cambia el flujo de Git de tus compañeros. La metadata queda en .got/, que podés sumar al .gitignore si no querés versionarla. Para ver la lista exacta de comandos y la documentación, lo mejor es ir directo al repositorio en GitHub, porque una herramienta así de nueva va a iterar rápido.

Qué está confirmado y qué no

• Confirmado: versión 1.0 lanzada, escrita en Go, metadata aislada en .got/, workspaces, ADRs, notas, guided sessions, snapshots, integración con GitHub y comandos seguros.
• Confirmado: los cinco principios de diseño (Git como fuente de verdad, metadata aislada, offline-first, plugins, recuperable).
• Pendiente o sin detalle público: la sintaxis exacta de cada comando, el roadmap de plugins de terceros y el grado de soporte para plataformas más allá de GitHub (GitLab, Gitea) más allá de que funciona con cualquier setup de Git.
• A tomar con pinzas: es un proyecto de un autor individual recién en su 1.0. La promesa es buena; la madurez en producción todavía hay que verla.

Errores comunes al pensar en GOT

• Creer que reemplaza a Git. No lo hace. Si sacás GOT, seguís teniendo todo tu historial Git intacto. Es una capa, no un fork.
• Pensar que obliga a todo el equipo. Falso. Es opcional por persona. El que no lo instala trabaja con Git normal y no se entera de que existe.
• Asumir que sube tus datos a algún lado. Es offline-first: no hace llamadas de red salvo las que vos disparás. La metadata queda local en .got/.
• Usarlo como reemplazo de documentación formal. Los ADRs y notas son contexto vivo pegado al código, no un wiki completo. Sirven para el “por qué” rápido, no para reemplazar specs largas.

Preguntas Frecuentes

¿Qué es GOT y cómo funciona como companion de Git?

GOT es una herramienta de línea de comandos open source que se monta sobre Git para agregar contexto: workspaces, decisiones de arquitectura, notas y snapshots. Funciona como una capa fina que guarda todo en un directorio .got/ aislado, sin modificar los commits ni el historial de Git.

¿Para qué sirve GOT si ya tengo Git?

Sirve para responder lo que Git no puede: por qué se tomó una decisión, qué archivos pertenecen a cada feature y qué debería leer primero alguien nuevo. Agrega registros de decisiones (ADRs), onboarding guiado y puntos de recuperación automáticos antes de operaciones destructivas. Ya lo cubrimos antes en agentes locales para desarrollo.

¿GOT reemplaza a Git?

No. GOT no reemplaza, no forkea ni modifica los internals de Git. Git sigue siendo la fuente de verdad y es obligatorio; GOT es una capa opcional que cada desarrollador instala o no según prefiera.

¿Es compatible con GitHub y GitLab?

GOT funciona con cualquier setup de Git, incluido GitHub, donde maneja PRs e issues desde la terminal. Al apoyarse sobre Git estándar y no alterarlo, es compatible con plataformas como GitLab, Gitea o servidores autoalojados, aunque el nivel de integración nativa más allá de GitHub todavía no tiene detalle público.

¿GOT es gratis y open source?

Sí. GOT está publicado en GitHub como proyecto open source, escrito en Go y disponible como binario para macOS, Linux y Windows.

Conclusión

GOT ataca un problema real y viejo: Git guarda el qué pero pierde el porqué, y ese porqué es justo lo que más cuesta cuando entra gente nueva o cuando volvés a un módulo seis meses después. La decisión de diseño más fuerte es la no invasión: metadata aislada, adopción individual, cero llamadas de red salvo las que pedís. Eso baja el riesgo de probarlo casi a cero.

¿Vale la pena hoy? Si tu equipo está creciendo y la fricción de onboarding te duele, instalalo en tu máquina y probá los workspaces y ADRs una semana. Es un proyecto en su 1.0 de un autor individual, así que tomá la madurez en producción con cautela. Pero la idea está bien planteada, y como podés sacarlo sin dejar rastro, el costo de la prueba es bajo.

Fuentes

• GOT en GitHub – repositorio oficial, código y documentación
• Anuncio de lanzamiento de v1.0 por Supun Hewagamage en dev.to
• Enriquecer el contexto de código con diffs de Git para herramientas más inteligentes (dev.to)