Convertir un repositorio de GitLab a texto: un solo archivo que tu LLM sí puede leer
Pegar código en una ventana de chat de archivo en archivo es una mala forma de gastar una tarde. El modelo responde a cada pregunta mirando tu proyecto por el ojo de una cerradura, tú tienes que estar diciendo «espera, aquí va el otro archivo que importa», y para cuando el contexto está completo la conversación se ha ido de madre. El arreglo es aburrido y eficaz: dale de entrada toda la porción relevante del repositorio, en un único bloque de texto.
Eso es lo que hace esta página. Es el camino más corto de un repositorio de GitLab a contexto para un LLM:
pegas una URL de proyecto https://gitlab.com/..., la herramienta lee el árbol del repositorio a
través de la API de GitLab, y obtienes un árbol de casillas con todos los archivos. Marca lo que importa,
desmarca lo que no, dale a generar. Sale un mapa de directorios seguido del contenido completo de los
archivos que elegiste, con un recuento de tokens para que sepas si cabe. Cópialo, descárgalo como texto o
llévate los archivos seleccionados en un ZIP.
Pega la URL que ya tienes delante
No hay ningún ID de proyecto que buscar ni ningún campo aparte para el espacio de nombres. Copia la URL de la
barra de direcciones de tu navegador y pégala. Los subgrupos anidados funcionan: la costumbre de GitLab de
enterrar un proyecto tres o cuatro niveles bajo company/platform/services/billing está
contemplada, porque la ruta del proyecto se codifica para URL antes de llegar a la API.
Si la URL que copiaste incluye una rama o una etiqueta, se usa esa referencia. Si es solo la URL pelada del
proyecto, se resuelve automáticamente la rama por defecto, así que no tienes que acordarte de si este
repositorio en concreto se quedó en main, master o develop. El árbol
se obtiene de forma recursiva y paginada, lo que importa más de lo que parece: hay bastantes monorepos de
GitLab con miles de archivos, y una sola petición sin paginar te daría un proyecto truncado sin avisar.
Proyectos privados, y adónde va exactamente tu token
Los proyectos públicos no necesitan nada. Para uno privado, añade un personal access token de GitLab y se
envía como cabecera PRIVATE-TOKEN en las peticiones a la
API de GitLab.
Desconfiar de pegar un token en una herramienta web es el instinto correcto, así que aquí va la versión
llana: el token se guarda en el localStorage de tu navegador y se usa solo para llamar a
gitlab.com directamente desde tu navegador. No se envía a ningún servidor nuestro, porque las
peticiones no pasan por ninguno.
Con alcance de solo lectura basta: read_api o read_repository. No le des permisos
de escritura que no va a usar, y ponle una caducidad mientras estás en la pantalla del token. También merece
la pena añadir un token incluso en repositorios públicos: las llamadas sin autenticar a la API de GitLab
tienen límite de tasa, así que si te estás bajando un proyecto grande o repitiendo la misma conversión
varias veces, una petición autenticada es la diferencia entre una descarga tranquila y un muro de errores.
GitLab autogestionado: la respuesta honesta
Esta herramienta habla con gitlab.com y solo con gitlab.com. No hay campo para la
URL de una instancia propia, y pegar gitlab.yourcompany.internal no va a funcionar. Si estás en
una instancia autoalojada o autogestionada, es un no rotundo.
La buena noticia es que, para una instancia autogestionada, la mejor respuesta nunca fue una llamada a la API. Clona el repositorio — ya tienes credenciales — y apunta el conversor de directorios locales a la carpeta. Lee los archivos con las API de archivos del navegador, así que no se sube nada y nada sale de tu máquina. Para una instancia privada detrás del cortafuegos corporativo, esa es la versión que tu equipo de seguridad habría pedido de todas formas. El mismo árbol de casillas, la misma salida, el mismo recuento de tokens. También acepta un ZIP si prefieres exportar un comprimido en vez de clonar.
Qué seleccionar y qué dejar fuera
Todo empieza marcado, que es la selección equivocada para casi cualquier proyecto real. El instinto cuando conviertes un repositorio de GitLab a texto es llevártelo entero; resístete. Un volcado de repositorio útil es uno curado: el presupuesto de tokens que gastas en ruido generado es presupuesto que el modelo no gasta en tu código. Desmarca primero esto:
- Dependencias vendorizadas e instaladas —
node_modules,vendor,.venv, cualquier cosa versionada que venga de un registro de paquetes. El modelo ya sabe qué pinta tiene Express. - Lockfiles.
package-lock.json,yarn.lock,poetry.lock,Gemfile.lock. Un lockfile pueden ser decenas de miles de tokens de hashes y versiones fijadas que no responden a ninguna pregunta que nadie haga jamás. Quédate con el manifiesto, tira el lock. - Artefactos de build y recursos minificados —
dist,build,.next, bundles compilados, source maps. Es tu propio código, reescrito en una forma sobre la que nada puede razonar. - Snapshots y fixtures. Las fixtures de test grandes y los archivos de snapshot son repetitivos por diseño. Un par de ejemplos representativos ganan a los cuatrocientos.
- Las migraciones, en general. Un directorio de esquema con seis años de migraciones incrementales solo vale la pena incluirlo cuando la pregunta es sobre el propio historial de migraciones.
Conserva lo que explica la intención: los archivos de código, el README, el manifiesto y
.gitlab-ci.yml. Este último es un consejo genuinamente de GitLab: la configuración de CI es
donde viven en un mismo sitio los pasos de build, los comandos de test, los destinos de despliegue y los
supuestos de entorno. Inclúyelo y el modelo podrá responder a «por qué esto falla en CI y pasa en local» en
lugar de adivinar.
El interruptor de vista de directorios es la otra mitad de esto. En Completa, la salida
incluye la estructura entera del repositorio con tus archivos seleccionados marcados, de modo que el modelo
puede ver que existe un módulo payments aunque no lo hayas incluido: contexto útil y barato en
tokens. En Filtrada, solo aparece lo que seleccionaste. La completa suele ser mejor opción
por defecto cuando has escogido un servicio dentro de un monorepo; la filtrada es más limpia cuando mandas
un puñado concreto de archivos.
Las tareas en las que esto es realmente bueno
- Aterrizar en un proyecto desconocido. Selecciona el directorio de código, el README y la configuración de CI, y luego pide un recorrido por los puntos de entrada y por dónde va una petición cuando llega. Veinte minutos de orientación comprimidos en un solo prompt.
- Revisar un merge request con su entorno. Un diff te dice qué cambió; no te dice quién más llama a la función que cambió. Exporta el directorio tocado y sus vecinos, pega el diff al lado, y obtendrás comentarios de revisión sobre consecuencias y no sobre estilo.
- Escribir la documentación que nadie escribió. Mete un módulo y pide un README, una nota de arquitectura o docstrings que sigan las convenciones que ya tiene el código en vez de inventarse otras.
- Generar tests. Incluye el módulo más dos o tres archivos de test existentes. Esa segunda parte es la que hace utilizable la salida: el modelo copia tus fixtures, tu nomenclatura y tu estilo de aserciones en lugar de producir algo que no encaja en la suite.
- Migraciones y actualizaciones. Subir la versión de un framework, reescribir en otro lenguaje, cambiar de ORM. Todo eso necesita visibilidad de la base de código entera para pillar todos los puntos de llamada, que es exactamente lo que da una única exportación de texto.
- Auditorías. Pregunta dónde se leen los secretos, qué endpoints se saltan la autenticación o qué sigue llamando a una API interna obsoleta. Preguntas amplias como estas no tienen respuesta archivo a archivo.
En casi todas ellas, la parte interesante es el directorio de un servicio y no el grupo entero. Selecciona
ese subárbol, deja el resto, y mira el recuento de tokens antes de pegar: se genera con la biblioteca
gpt-tokenizer, así que es un recuento real que puedes comparar con la ventana de contexto de tu
modelo y no una estimación. La salida es la misma tanto si exportas código de GitLab para una pasada de
revisión con IA como si conviertes un proyecto de GitLab en un archivo de texto para ChatGPT, Claude o
Gemini: un solo archivo, y puedes leerlo antes de mandarlo.
Los archivos que están al lado de tu código
Un repositorio no son solo archivos de código. La configuración, los esquemas, los datos de seed y las especificaciones se versionan al lado, y algunos se leen fatal volcados en bruto. Los formatos estructurados aterrizan mejor como Markdown: JSON a Markdown para configuración y payloads de API, XML a Markdown para los archivos de Maven, de Android y del SOAP heredado que nunca se fue, CSV a Markdown para datos de seed y exportaciones, y HTML a Markdown para plantillas y documentación generada. Las especificaciones que llegaron como PDF también se convierten, y un archivo ZIP se puede aplanar directamente a texto. File2Txt se encarga de todo si prefieres no elegir página.
Preguntas frecuentes
¿Cómo convierto un repositorio de GitLab a un archivo de texto?
Pega arriba la URL del proyecto y el árbol de archivos se carga como una lista de casillas. Selecciona los archivos que quieras y exporta un único archivo de texto con la estructura de directorios al principio y cada archivo debajo, encabezado por su ruta. Gratis, sin instalar nada, sin registro.
¿Funciona con GitLab autoalojado?
Las instancias autogestionadas exponen la misma API REST que gitlab.com, así que una instancia accesible se comporta igual. La trampa es el acceso de red: una instancia detrás de una VPN corporativa o de una red privada no es accesible desde la pestaña de tu navegador, y ningún token cambiará eso. Para esos casos, clona el proyecto y usa el conversor de carpetas locales.
¿Cómo convierto un proyecto privado de GitLab?
Facilita un personal access token con el alcance read_repository. Créalo en Preferencias → Tokens de acceso, dale la caducidad más corta que cubra tu sesión y bórralo después. Con solo lectura basta: un token con permisos de escritura o de API completa expone más de lo que la tarea necesita.
¿Por qué usar esto en vez de clonar el repositorio?
Clonar te da un árbol de trabajo, que es la forma equivocada para esta tarea. Lo que quiere un modelo es un único documento que contenga a la vez la estructura y el contenido, con el ruido quitado. Clonar además se trae todo el historial y todas las dependencias: normalmente muchísimos más bytes que el código sobre el que realmente quieres razonar.
¿Maneja subgrupos y rutas de proyecto anidadas?
Sí. La estructura de grupos anidados de GitLab hace que las rutas de proyecto tengan varios segmentos, y es la ruta completa la que identifica el proyecto: pega la URL entera desde la barra de direcciones de tu navegador en lugar de montarla a mano y la búsqueda se resolverá correctamente.
¿Puedo convertir el diff de un merge request en vez del proyecto entero?
Desde esta página no: trabaja sobre el árbol del repositorio en una referencia dada. Para trabajo de revisión, el patrón habitual es convertir los archivos que toca el merge request, pegar eso como contexto y pegar el diff debajo. El modelo necesita el código de alrededor para juzgar un cambio, y un diff por sí solo rara vez se lo da.
Todo lo demás de la caja de herramientas
¿El código está en GitHub? El conversor de repositorios de GitHub a texto funciona igual. ¿Solo lo tienes en tu máquina, o en una instancia autogestionada que has clonado? Usa el conversor de directorios locales. ¿Necesitas el sitio de documentación y no el código que lo genera? Web2Txt convierte una URL en Markdown.
Para los argumentos más largos detrás de todo esto, hay una guía sobre darle un repositorio a un modelo de IA, otra sobre convertir una base de código en un archivo listo para LLM, una guía completa para convertir repositorios para LLM, y un artículo más amplio sobre preparar archivos para herramientas de IA.
Repo2Txt está desarrollado y mantenido por v12hero, un desarrollador independiente que crea aplicaciones nativas y web centradas en la privacidad.