Convertidor de repositorio GitHub a texto

Convertir un repositorio de GitHub a texto: todo un proyecto en un solo archivo que un LLM puede leer

Pega una URL de GitHub arriba y obtienes el árbol de archivos del repositorio como una lista de casillas. Marca lo que importa, genera, y tienes un único archivo de texto: la estructura de directorios al principio y luego cada archivo seleccionado debajo, separado por una cabecera con su ruta. Ese es el formato que funciona con ChatGPT, Claude, Gemini, DeepSeek o donde sea que pegues el contenido: el modelo ve a la vez la forma del proyecto y el código, así que puede razonar sobre cómo encajan las piezas en lugar de adivinar a partir de un archivo aislado.

Nada que clonar, nada que instalar, sin registro y gratis. El repositorio se lee a través de la API de GitHub directamente desde tu navegador, así que no necesitas el proyecto en tu máquina, que es justo la gracia cuando estás mirando código ajeno, una dependencia que estás evaluando o un repositorio al que te acaban de dar acceso.

Pega la URL, con la rama o la etiqueta incluidas

La forma simple https://github.com/owner/repo funciona y te da la rama por defecto. Pero la URL lleva más información que eso, y vale la pena aprovecharla. Copia la barra de direcciones mientras navegas por GitHub y lo que estás mirando viaja contigo:

• Una rama — /tree/develop o una rama de funcionalidad, para convertir el trabajo en curso en lugar de lo que hay en main.
• Una etiqueta o una release — /tree/v2.1.0. Útil cuando preguntas por la versión que de verdad tienes desplegada, o para comparar dos releases en la conversación convirtiendo cada una.
• Un subdirectorio — /tree/main/packages/api. Este es el que te salva en un monorepo. Empieza por el paquete que te interesa y el árbol que recibes ya viene acotado, en vez de diez mil archivos que luego tendrás que ir desmarcando.

Si la rama o la ruta no existen se te dice qué parte no se pudo resolver, que normalmente es una errata en el nombre de una rama o un repositorio que es privado para el token que estás usando.

Repositorios privados, y adónde va tu token

Los repositorios privados funcionan con un personal access token de GitHub. Genera uno en la configuración de desarrollador de GitHub con acceso de lectura a los repositorios que necesites: un token fine-grained limitado a un solo repositorio es suficiente, y es la opción que conviene tomar. Pégalo en el campo del token y el árbol se carga igual que el de uno público.

El token se guarda en el localStorage de tu navegador para que no lo reescribas en cada visita, y va a un único sitio: api.github.com, en las cabeceras de la petición, desde tu propia máquina. Aquí no hay ninguna cuenta a la que asociarlo ni ningún backend nuestro por el camino. Vacía el campo y se borra del almacenamiento. En una máquina compartida, bórralo al terminar; y si quieres certeza, revoca después el token en GitHub: es una acción de un clic y no te cuesta nada.

Un token también ayuda en repositorios públicos. Las peticiones sin autenticar a la API de GitHub tienen un límite de tasa bastante agresivo, así que si estás convirtiendo un repositorio grande, o varios seguidos, añadir un token es la diferencia entre que funcione y esperar una hora.

Qué desmarcar antes de generar

Este es el paso que decide si la salida sirve para algo. Un repositorio contiene un montón de archivos que están versionados por buenas razones y que aun así no valen nada como contexto para un modelo. Recorre el árbol y descarta:

• Dependencias vendorizadas — node_modules, vendor, third_party. Raro en un repositorio, pero devastador cuando está. Es código fuente de otra gente, y va a ahogar el tuyo.
• Artefactos de build — dist, build, out, .next, target, informes de cobertura. Otra vez tu propio código, transpilado o minificado: el modelo lo lee todo dos veces y la segunda no aprende nada nuevo.
• Lockfiles — package-lock.json, yarn.lock, poetry.lock, Cargo.lock. Decenas de miles de tokens de hashes casi vacíos de significado. Quédate mejor con el manifiesto: package.json o pyproject.toml es lo que le dice al modelo con qué stack trabajas.
• Código generado — salidas de protobuf y gRPC, codegen de GraphQL, clientes de OpenAPI, migraciones de base de datos, tests de snapshot. Escrito por una máquina, repetitivo, y empuja al modelo a editar archivos que se van a regenerar de todos modos.
• Archivos de datos grandes — fixtures, volcados de seed, CSV de ejemplo, bundles minificados que alguien commiteó hace años. Uno solo de estos puede comerse una ventana de contexto entera.

Filtrar por extensión es la vía rápida cuando un repositorio es grande: restringe a .ts y .tsx, o a .py, y has cortado casi todo el ruido de un golpe. Después vuelve a añadir el puñado de archivos de configuración y documentación que explican el proyecto: el README, la configuración principal, el esquema.

El contador de tokens es lo que de verdad importa

La salida generada viene con un recuento de tokens, calculado con la biblioteca gpt-tokenizer y no con una estimación de caracteres divididos entre cuatro. Míralo antes de pegar. Saber si un volcado cabe en la ventana de contexto que vas a usar es todo el juego; la alternativa es pegar, esperar y leer un error de longitud.

Úsalo para pilotar, no solo para comprobar. Si el recuento es el doble del espacio que tienes, vuelve al árbol y desmarca un directorio en vez de truncar el archivo al final, porque un volcado cortado a mitad de proyecto deja al modelo con media implementación y sin la menor idea de que le falta algo. Y ten presente que una ventana de contexto grande no es lo mismo que una buena: una selección enfocada de 8.000 tokens — el módulo, sus tests y los dos archivos que importa — suele ganarle a 200.000 tokens de todo revuelto. Manda el repositorio entero cuando la pregunta es arquitectónica, y una porción cuando es local.

Cuando esté listo, copia el texto al portapapeles, descárgalo como .txt, o llévate los archivos seleccionados en un ZIP si prefieres tenerlos como archivos y no como un único documento fusionado.

Cómo se usa

Para qué lo usa la gente de verdad

• Aterrizar en una base de código desconocida. Trabajo nuevo, equipo nuevo, o un proyecto de código abierto al que quieres contribuir. Conviértelo, pégalo y pide los puntos de entrada, las abstracciones centrales y las tres cosas que sorprenderían a un mantenedor nuevo. Te sitúas antes que leyendo el README y clicando de archivo en archivo durante un día.
• Revisar una pull request con su entorno. Un diff enseña qué cambió, no a qué afecta. Convierte la rama, o solo el paquete implicado, y pregunta quién más llama a la función que cambió y qué supuestos hace el código nuevo sobre ella.
• Escribir documentación que sea cierta. Los README se pudren porque se escriben una vez. Genera un resumen de la arquitectura, resúmenes por módulo o la lista real de variables de entorno a partir del código tal y como está hoy en main.
• Generar tests. Incluye el módulo más un archivo de test existente como referencia de estilo. El modelo se ajusta a tu framework, a tus nombres y a tus fixtures en vez de inventarse una convención que no usa nadie del equipo.
• Planificar una migración o una refactorización. Componentes de clase a hooks, JavaScript a TypeScript, un ORM por otro. Un modelo que ve todos los puntos de llamada produce una secuencia de pasos real y no una lista genérica.
• Auditorías y due diligence. Evaluar un repositorio que heredas, que compras o que estás considerando como dependencia. Un archivo consolidado hace viable preguntar dónde se manejan los secretos, qué pinta tienen las rutas de error y dónde están los patrones peligrosos.
• RAG y embeddings. Las secciones delimitadas por ruta se trocean limpiamente, así que la salida entra en una base vectorial con muy poco preprocesado.

Preguntas frecuentes

¿Cómo convierto un repositorio de GitHub a un archivo de texto?

Pega la URL del repositorio arriba y el árbol de archivos aparece como una lista de casillas. Desmarca lo que el modelo no necesita, genera, y obtienes un único archivo de texto: la estructura de directorios al principio y luego cada archivo seleccionado bajo una cabecera con su ruta. Nada que clonar, nada que instalar, gratis y sin registro.

¿Cómo convierto un repositorio privado de GitHub?

Pega un personal access token junto a la URL. Crea un token fine-grained limitado a ese único repositorio, con permiso de solo lectura sobre Contents y una caducidad corta: ese es el mínimo privilegio que la API acepta para esto. El token se usa para llamar a GitHub desde tu navegador y no se guarda de nuestro lado.

¿Cuántos tokens ocupa mi base de código y va a caber?

El contador se actualiza a medida que marcas archivos, así que ves el número antes de pegar nada. Como orden de magnitud, el código fuente ronda entre 3 y 4 caracteres por token, así que una selección de 500 KB aterriza cerca de los 140.000 tokens. Eso cabe en una ventana de contexto de 200K y no va a caber en un solo mensaje de chat en la mayoría de interfaces.

¿Qué archivos debo excluir antes de darle un repositorio a un LLM?

Primero node_modules, vendor y cualquier directorio de dependencias: suelen ser la abrumadora mayoría de los bytes y no aportan nada sobre tu código. Después los lockfiles, los artefactos de build, los bundles minificados, las fixtures de test y los archivos binarios. En un proyecto JavaScript típico, solo esa pasada elimina a menudo más del noventa por ciento de los tokens.

¿Qué tal se compara esto con gitingest, repomix o code2prompt?

Son buenas herramientas y la diferencia honesta está en el flujo de trabajo, no en las capacidades. Están pensadas para la línea de comandos, son scriptables y son la respuesta correcta dentro de una CI o de un proceso por lotes. Esto funciona en una pestaña del navegador con un árbol de casillas, así que ves el repositorio, desmarcas lo que no quieres y observas cómo se mueve el contador de tokens: mejor para el caso puntual en el que todavía estás decidiendo qué incluir.

¿Es seguro pasar mi código por aquí?

Los repositorios públicos se leen a través de la API de GitHub desde tu navegador, así que el código va de GitHub a ti. Para cualquier cosa confidencial, la opción más sólida es el conversor de carpetas locales, que no sube absolutamente nada. En cualquier caso, revisa tu selección buscando claves de API y credenciales antes de pegarla en un modelo: ese es el paso que la gente se salta.

Carpetas locales, GitLab y todo lo que no es código

No todo lo que quieres convertir vive en GitHub. El conversor de carpetas locales a texto coge un directorio directamente de tu disco y lo junta en un solo archivo sin subir nada: cero llamadas de red, que es lo que quieres para trabajo de cliente, ramas sin commitear o un proyecto que nunca fue un repositorio git. Para GitLab, el conversor de GitLab a texto hace el mismo trabajo con proyectos públicos, privados y autoalojados.

Además, el código suele ser solo la mitad del contexto. La especificación está en un PDF, el esquema en JSON, la configuración heredada en XML, los datos de ejemplo en un CSV. Convierte todo eso junto a tu repositorio con PDF a Markdown, JSON a Markdown, XML a Markdown, CSV a Markdown o HTML a Markdown. Si alguien te pasa un comprimido, ZIP a texto le saca el contenido legible, y File2Txt acepta cualquiera de los trece formatos compatibles si prefieres no elegir página. Para la documentación que solo existe en la web, Web2Txt convierte una URL en Markdown limpio, incluidas las páginas renderizadas con JavaScript: empareja una referencia de API extraída con tu repositorio convertido y un asistente de código verá los dos lados a la vez.

En el blog hay más profundidad: la guía completa para convertir repositorios de GitHub para LLM, convertir una base de código en un archivo listo para LLM, darle un repositorio entero a una IA y el paso a paso de carpeta a texto para directorios locales.

Repo2Txt está desarrollado y mantenido por v12hero, un desarrollador independiente que crea aplicaciones nativas y web centradas en la privacidad.