GitHub Repo-zu-Text-Konverter

Konvertieren Sie ein GitHub-Repository in eine einzelne Textdatei, die ein LLM lesen kann. Wählen Sie die benötigten Dateien aus, beobachten Sie die Anzahl der Token und fügen Sie das Ergebnis in ChatGPT, Claude oder Gemini ein. Kostenlos, keine Anmeldung.

GitHub-Repo in Text umwandeln: ein ganzes Repository in einer Datei, die ein LLM lesen kann

Fügen Sie oben eine GitHub-URL ein und Sie bekommen den Dateibaum des Repositories als Liste mit Kontrollkästchen. Haken Sie an, was zählt, generieren Sie — und Sie haben eine einzige Textdatei: oben die Verzeichnisstruktur, darunter jede ausgewählte Datei, getrennt durch eine Kopfzeile mit ihrem Pfad. Das ist das Format, das mit ChatGPT, Claude, Gemini, DeepSeek oder allem anderen funktioniert, in das Sie es einfügen — das Modell sieht die Form des Projekts und den Code gleichzeitig und kann deshalb darüber nachdenken, wie die Teile zusammenspielen, statt aus einer isolierten Datei zu raten.

Nichts zu klonen, nichts zu installieren, keine Anmeldung, und kostenlos ist es auch. Das Repo wird über die GitHub-API direkt aus Ihrem Browser gelesen, Sie brauchen das Projekt also gar nicht auf Ihrem Rechner — was genau der Punkt ist, wenn Sie sich fremden Code ansehen, eine Abhängigkeit bewerten oder ein Repo, auf das man Ihnen gerade Zugriff gegeben hat.

Fügen Sie die URL ein, samt Branch oder Tag

Die schlichte Form https://github.com/owner/repo funktioniert und liefert Ihnen den Standard-Branch. Aber die URL trägt mehr Information, und die sollten Sie nutzen. Kopieren Sie die Adressleiste, während Sie auf GitHub unterwegs sind, und was Sie gerade ansehen, kommt mit herüber:

  • Ein Branch — /tree/develop oder ein Feature-Branch, damit Sie die laufende Arbeit konvertieren statt dessen, was auf main liegt.
  • Ein Tag oder Release — /tree/v2.1.0. Nützlich, wenn Sie über die Version reden, die tatsächlich ausgeliefert wird, oder wenn Sie zwei Releases im Gespräch vergleichen wollen, indem Sie beide konvertieren.
  • Ein Unterverzeichnis — /tree/main/packages/api. Das ist der, der Sie im Monorepo rettet. Starten Sie beim Paket, um das es geht, und der zurückgegebene Baum ist bereits eingegrenzt — statt zehntausend Dateien, die Sie danach wieder abwählen müssten.

Gibt es den Branch oder den Pfad nicht, bekommen Sie gesagt, welcher Teil sich nicht auflösen ließ — meist ein Tippfehler in einem Branch-Namen oder ein Repo, das für das verwendete Token privat ist.

Private Repositories, und wohin Ihr Token geht

Private Repos funktionieren mit einem GitHub Personal Access Token. Erzeugen Sie eines in Ihren GitHub-Entwicklereinstellungen mit Lesezugriff auf die Repositories, die Sie brauchen — ein fine-grained Token, das auf ein einzelnes Repo beschränkt ist, reicht aus, und genau diese Option sollten Sie nehmen. Fügen Sie es ins Token-Feld ein, und der Baum lädt genauso wie bei einem öffentlichen Repo.

Das Token wird im localStorage Ihres Browsers gehalten, damit Sie es nicht bei jedem Besuch neu tippen müssen, und es geht an genau eine Stelle: api.github.com, in den Request-Headern, von Ihrem eigenen Rechner aus. Es gibt hier kein Konto, an das man es hängen könnte, und kein Backend von uns auf dem Weg. Leeren Sie das Feld, und es ist aus dem Speicher verschwunden. Auf einem gemeinsam genutzten Rechner löschen Sie es, wenn Sie fertig sind; und wenn Sie ganz sichergehen wollen, ziehen Sie das Token hinterher in GitHub zurück — ein Klick, und es kostet Sie nichts.

Ein Token hilft auch bei öffentlichen Repos. Unauthentifizierte Anfragen an die GitHub-API werden ziemlich streng gedrosselt. Wenn Sie also ein großes Repository konvertieren oder mehrere hintereinander, ist ein Token der Unterschied zwischen „es läuft“ und einer Stunde Wartezeit.

Was Sie vor dem Generieren abwählen sollten

Das ist der Schritt, der entscheidet, ob die Ausgabe brauchbar wird. Ein Repository enthält viele Dateien, die aus guten Gründen versioniert sind und als Modellkontext trotzdem wertlos bleiben. Gehen Sie den Baum durch und werfen Sie raus:

  • Mitversionierte Abhängigkeiten — node_modules, vendor, third_party. Selten in einem Repo, aber verheerend, wenn sie drin sind. Das ist der Quellcode anderer Leute, und er wird Ihren ertränken.
  • Build-Artefakte — dist, build, out, .next, target, Coverage-Berichte. Wieder Ihr eigener Code, transpiliert oder minifiziert, das Modell liest also alles zweimal und lernt beim zweiten Mal nichts Neues.
  • Lockfiles — package-lock.json, yarn.lock, poetry.lock, Cargo.lock. Zehntausende Tokens Hashes mit fast keinem Sinn darin. Behalten Sie stattdessen das Manifest; package.json oder pyproject.toml sagt dem Modell, auf welchem Stack Sie sitzen.
  • Generierter Code — Protobuf- und gRPC-Ausgaben, GraphQL-Codegen, OpenAPI-Clients, Datenbankmigrationen, Snapshot-Tests. Maschinengeschrieben, repetitiv, und es drängt das Modell dazu, Dateien zu bearbeiten, die ohnehin neu generiert werden.
  • Große Datendateien — Fixtures, Seed-Dumps, Beispiel-CSVs, minifizierte Bundles, die vor Jahren committet wurden. Eine einzige davon kann ein Kontextfenster im Alleingang auffressen.

Nach Endung zu filtern ist bei einem großen Repo der schnelle Weg: Grenzen Sie auf .ts und .tsx ein, oder auf .py, und Sie haben den größten Teil des Rauschens in einem Zug weggeschnitten. Danach holen Sie die Handvoll Konfigurations- und Dokumentationsdateien zurück, die das Projekt erklären — die README, die Hauptkonfiguration, das Schema.

Der Token-Zähler ist der Teil, auf den es ankommt

Die erzeugte Ausgabe kommt mit einer Tokenzahl, berechnet mit der Bibliothek gpt-tokenizer und nicht per Schätzung „Zeichen durch vier“. Prüfen Sie sie, bevor Sie einfügen. Zu wissen, ob ein Dump in das Kontextfenster passt, das Sie gleich benutzen, ist das ganze Spiel — die Alternative heißt einfügen, warten und eine Längenfehlermeldung lesen.

Nutzen Sie ihn zum Steuern, nicht nur zum Kontrollieren. Ist die Zahl doppelt so hoch wie Ihr Platz, gehen Sie zurück in den Baum und wählen ein Verzeichnis ab, statt die Datei am Ende abzuschneiden — denn ein mitten im Projekt gekappter Dump lässt das Modell mit einer halben Implementierung zurück, ohne dass es merkt, dass etwas fehlt. Und denken Sie daran: Ein großes Kontextfenster ist nicht dasselbe wie ein gutes. Eine gezielte Auswahl von 8.000 Tokens — das Modul, seine Tests und die zwei Dateien, die es importiert — schlägt in der Regel 200.000 Tokens von allem Möglichen. Schicken Sie das ganze Repo, wenn die Frage architektonisch ist, und eine Scheibe, wenn sie lokal ist.

Wenn alles fertig ist, kopieren Sie den Text in die Zwischenablage, laden ihn als .txt herunter oder holen sich die ausgewählten Dateien als ZIP, falls Ihnen einzelne Dateien lieber sind als ein zusammengeführtes Dokument.

So funktioniert es

Wofür die Leute es tatsächlich benutzen

  • Einarbeitung in eine unbekannte Codebasis. Neuer Job, neues Team oder ein Open-Source-Projekt, zu dem Sie beitragen wollen. Konvertieren, einfügen und nach den Einstiegspunkten fragen, nach den zentralen Abstraktionen und nach den drei Dingen, die eine neue Maintainerin überraschen würden. Sie sind schneller orientiert, als wenn Sie einen Tag lang die README lesen und sich durch Dateien klicken.
  • Einen Pull Request mit seiner Umgebung reviewen. Ein Diff zeigt, was sich geändert hat, aber nicht, was es berührt. Konvertieren Sie den Branch oder nur das betroffene Paket und fragen Sie, wer die geänderte Funktion sonst noch aufruft und welche Annahmen der neue Code über sie trifft.
  • Dokumentation schreiben, die auch stimmt. READMEs verrotten, weil sie einmal geschrieben werden. Lassen Sie sich einen Architekturüberblick, Modulzusammenfassungen oder die echte Liste der Umgebungsvariablen aus dem Code erzeugen, wie er heute auf main steht.
  • Tests generieren. Nehmen Sie das Modul plus eine bestehende Testdatei als Stilvorlage mit hinein. Das Modell übernimmt Ihr Framework, Ihre Benennung und Ihre Fixtures, statt eine Konvention zu erfinden, die im Team niemand benutzt.
  • Migrationen und Refactorings planen. Klassenkomponenten zu Hooks, JavaScript zu TypeScript, ein ORM zum nächsten. Ein Modell, das jede Aufrufstelle sieht, liefert eine echte Schrittfolge statt einer generischen Checkliste.
  • Audits und Due Diligence. Ein Repository bewerten, das Sie erben, kaufen oder als Abhängigkeit erwägen. Eine zusammengeführte Datei macht es praktikabel, zu fragen, wo Geheimnisse verarbeitet werden, wie die Fehlerpfade aussehen und wo die riskanten Muster sitzen.
  • RAG und Embeddings. Die durch Pfade abgegrenzten Abschnitte lassen sich sauber chunken, die Ausgabe fällt also mit sehr wenig Vorverarbeitung in eine Vektordatenbank.

Häufige Fragen

Wie wandle ich ein GitHub-Repo in eine Textdatei um?

Fügen Sie oben die Repository-URL ein, und der Dateibaum erscheint als Liste mit Kontrollkästchen. Wählen Sie ab, was das Modell nicht braucht, generieren Sie, und Sie bekommen eine Textdatei: oben die Verzeichnisstruktur, darunter jede ausgewählte Datei unter einer Kopfzeile mit ihrem Pfad. Nichts zu klonen, nichts zu installieren, kostenlos und ohne Anmeldung.

Wie konvertiere ich ein privates GitHub-Repository?

Fügen Sie neben der URL ein Personal Access Token ein. Erstellen Sie ein fine-grained Token, das nur für dieses eine Repository gilt, mit Lesezugriff auf Contents und kurzer Gültigkeit — das ist das geringste Privileg, das die API dafür akzeptiert. Das Token dient dazu, GitHub aus Ihrem Browser aufzurufen, und wird bei uns nicht gespeichert.

Wie viele Tokens hat meine Codebasis, und passt das?

Der Zähler aktualisiert sich, während Sie Dateien anhaken, Sie sehen die Zahl also, bevor Sie irgendetwas einfügen. Als grober Anhaltspunkt: Quellcode liegt bei etwa 3 bis 4 Zeichen pro Token, eine Auswahl von 500 KB landet also bei rund 140.000 Tokens. Das passt in ein 200K-Kontextfenster und passt in den meisten Oberflächen nicht in eine einzelne Chat-Nachricht.

Welche Dateien sollte ich ausschließen, bevor ich ein Repo an ein LLM gebe?

Zuerst node_modules, vendor und jedes Abhängigkeitsverzeichnis — sie machen meist die überwältigende Mehrheit der Bytes aus und sagen nichts über Ihren Code. Danach Lockfiles, Build-Artefakte, minifizierte Bundles, Test-Fixtures und Binärdateien. Bei einem typischen JavaScript-Projekt entfernt allein dieser Durchgang oft über neunzig Prozent der Tokens.

Wie schlägt sich das gegen gitingest, repomix oder code2prompt?

Das sind gute Werkzeuge, und der ehrliche Unterschied liegt im Arbeitsablauf, nicht im Funktionsumfang. Sie sind auf die Kommandozeile ausgelegt, skriptbar und die richtige Antwort in einer CI oder einem Batch-Job. Das hier läuft in einem Browser-Tab mit einem Auswahlbaum: Sie sehen das Repo, wählen ab, was Sie nicht wollen, und beobachten, wie sich die Tokenzahl bewegt — besser für den Einzelfall, in dem Sie noch entscheiden, was hineingehört.

Ist es unbedenklich, meinen Code hier durchzuschicken?

Öffentliche Repositories werden über die GitHub-API aus Ihrem Browser gelesen, der Code geht also von GitHub zu Ihnen. Für alles Vertrauliche ist der Konverter für lokale Ordner die stärkere Option — der lädt überhaupt nichts hoch. So oder so: Prüfen Sie Ihre Auswahl auf API-Schlüssel und Zugangsdaten, bevor Sie sie in ein Modell einfügen — das ist der Schritt, den die Leute überspringen.

Lokale Ordner, GitLab und alles, was kein Code ist

Nicht alles, was Sie konvertieren wollen, liegt auf GitHub. Der Konverter für lokale Ordner nimmt ein Verzeichnis direkt von Ihrer Platte und fügt es zu einer Datei zusammen, ohne irgendetwas hochzuladen — überhaupt keine Netzwerkaufrufe, und genau das wollen Sie bei Kundenprojekten, nicht committeten Branches oder einem Projekt, das nie ein Git-Repo war. Für GitLab macht der GitLab-zu-Text-Konverter dieselbe Arbeit mit öffentlichen, privaten und selbst gehosteten Projekten.

Und Code ist meist ohnehin nur die halbe Miete. Die Spezifikation steckt in einem PDF, das Schema in JSON, die Altkonfiguration in XML, die Beispieldaten in einer CSV. Konvertieren Sie das zusammen mit Ihrem Repo über PDF zu Markdown, JSON zu Markdown, XML zu Markdown, CSV zu Markdown oder HTML zu Markdown. Drückt Ihnen jemand ein Archiv in die Hand, holt ZIP zu Text den lesbaren Inhalt heraus, und File2Txt nimmt jedes der dreizehn unterstützten Formate, wenn Sie sich keine Seite aussuchen wollen. Für Dokumentation, die nur im Web existiert, holt Web2Txt eine URL als sauberes Markdown, JavaScript-gerenderte Seiten eingeschlossen — kombinieren Sie eine so geholte API-Referenz mit Ihrem konvertierten Repo, und ein Coding-Assistent sieht beide Seiten auf einmal.

Im Blog steht mehr dazu: der vollständige Leitfaden zur Konvertierung von GitHub-Repositories für LLMs, eine Codebasis in eine LLM-taugliche Datei verwandeln, ein ganzes Repository in eine KI einspeisen und die Schritt-für-Schritt-Anleitung von Ordner zu Text für lokale Verzeichnisse.

Repo2Txt wird entwickelt und gepflegt von v12hero, einem unabhängigen Entwickler, der native und Web-Apps mit Fokus auf Datenschutz baut.