API-Collections in Git: Requests, Docs & Tasks versionieren (2026)

Dein Code liegt in Git. Deine API-Collections, die Docs, die die API erklären, und die Tasks, die beschreiben, was als Nächstes gebaut wird, meistens nicht: Sie liegen in der Cloud eines Anbieters, in einem Wiki und in einem Ticket-Tracker, jeweils mit eigener Historie oder ganz ohne. Wenn ein Request kaputtgeht, kann niemand sagen, wer den Auth-Header geändert hat oder wie der Request letzten Dienstag aussah.

API-Collections in Git zu legen löst das. Jede Änderung wird zu einem Commit, den du lesen, reviewen und zurückrollen kannst, und die Collection reist mit dem Code, den sie testet. Dieser Guide zeigt, warum das wichtig ist, wie ein gutes Layout im Repository aussieht, wie die gängigen API-Clients 2026 mit Git umgehen und wie Apiboo deine Requests, Dokumente, Boards und Projekte im selben Repository ablegt. Wir bauen Apiboo; die Fakten zu den Mitbewerbern haben wir im September 2026 auf deren eigenen Websites geprüft.

Warum API-Collections in Git gehören

Historie: wer welchen Request wann und warum geändert hat, ohne im Chat nachfragen zu müssen.
Review: Die Änderung an einem Endpoint-Request erscheint neben der Codeänderung, die sie nötig gemacht hat.
Rollback: Du holst die Version eines einzelnen Requests zurück, die funktioniert hat, nicht den ganzen Workspace.
Eigentum: Die Dateien liegen in einem Repository, das du kontrollierst, auf GitHub, GitLab oder deinem eigenen Server, und überleben jeden Anbieter.
KI-Agenten: Ein Coding-Agent, der dein Repo liest, kann auch die Collection und die Docs lesen, als reinen Text.

Wie ein gutes Git-Layout aussieht

Nicht jede „Git-Synchronisierung“ ist gleich. Eine Collection, die als eine große JSON-Datei exportiert wird, liegt technisch zwar in Git, aber jede Änderung schreibt die ganze Datei neu, und der Diff ist unlesbar. Das willst du stattdessen:

Eine Datei pro Request, damit eine Änderung genau eine Datei berührt und ein Review genau diesen Request zeigt.
Ein Textformat, das Menschen lesen können, etwa YAML, und Markdown für Fließtext.
Secrets bleiben aus dem Repository, mit einer Prüfung, die ein Token stoppt, bevor es committet wird.
Stabile IDs in den Dateien, damit das Umbenennen eines Requests in der Historie ein Rename ist und kein Löschen plus Hinzufügen.
Deine übrigen Dateien bleiben unangetastet: Die README und der Code neben der Collection werden nie überschrieben.

Wie die gängigen API-Clients mit Git umgehen (September 2026)

Mittlerweile hat jeder von ihnen eine Antwort; sie unterscheiden sich darin, was ins Repository kommt und was es kostet.

Postman — Natives Git seit v12 speichert Collections als Dateien in deinem Repository, gekoppelt an Team-Workspaces; Newman liest das dabei genutzte v3-Collection-Format nicht, daher zieht die CI auf die Postman CLI um.
Bruno — Die Collection ist ein Ordner mit Klartextdateien (seit v3.1 standardmäßig YAML, .bru wird unterstützt); du committest kostenlos mit deinen eigenen Git-Tools, und die Git-Oberfläche in der App (Clone, Diff, Branches, Konflikte) gehört zum kostenpflichtigen Ultimate-Tarif.
Insomnia — Git Sync pro Projekt, neben Local Vault und Cloud Sync; der kostenlose Essentials-Tarif enthält Git Sync für bis zu 3 Nutzer.
Yaak — Workspaces leben in der App und lassen sich in einen Ordner spiegeln, den du selbst committest.
Thunder Client — Git-Sync gibt es in den kostenpflichtigen Tarifen.
Apiboo — eine Git-Seite in der Desktop-App: Requests als YAML, je eine Datei, dazu Dokumente als Markdown sowie Boards, Tasks und Projekte; kostenlos, und für alles außer GitHub funktioniert es ohne Apiboo-Konto.

Nicht nur Requests: Docs, Tasks und Projekte im selben Repo

Die meisten API-Clients hören bei der Collection auf. Apiboo synchronisiert auch die Arbeit drumherum, denn ein Request ohne seinen Kontext ist nur die halbe Geschichte. Verbinde My projects, boards & documents mit einem Repository, und Apiboo schreibt:

documents/ — jede Seite als Markdown-Datei, Unterseiten in einem Ordner, der nach ihrer Seite benannt ist, Bilder unter documents/media/.
boards/<name>/ — eine board.yaml mit den Listen und Labels sowie eine Markdown-Datei pro Task in tasks/, samt Kommentaren.
projects/ — eine YAML-Datei pro Projekt, dazu die Verknüpfungen zwischen ihnen.

Was Apiboo für einen Workspace schreibt

Ein Workspace wird zu einer Handvoll lesbarer Dateien: apiboo.yaml mit seiner ID und seinem Namen, collections/<name>/collection.yaml für Ordner, Einstellungen, Skripte und Auth, collections/<name>/requests/<name>.yaml für jeden Request, environments/<name>.yaml sowie variables/globals.yaml und variables/workspace.yaml. Apiboo pflegt einen eigenen Block in .gitignore und .gitattributes und lässt deine Zeilen in Ruhe.

Secret-Variablen landen nie im Repository. Eine als Secret markierte Variable wird ohne ihren Wert geschrieben; der Wert bleibt in einer *.local.yaml-Datei daneben, die Git ignoriert. Der Vault, dein Schlüsselbund, der Chat und der Mail-Catcher sind nie in einem Repository.

Der Alltag

Apiboo committet und pusht nie von allein. Du bearbeitest Requests wie gewohnt, und die Git-Seite zeigt, was sich seit der letzten Synchronisierung geändert hat, gruppiert nach Requests, Ordnern, Collections, Environments und Variablen, jeweils markiert als hinzugefügt, geändert, gelöscht oder umbenannt. Klick einen Eintrag an, und du siehst jedes geänderte Feld, alter Wert über dem neuen. Mit Discard this change setzt du ein einzelnes Element zurück.

Sync now committet und pusht; Pull holt die Änderungen deiner Teammitglieder. Bist du offline, wird der Commit angelegt und gesendet, sobald die Verbindung wieder da ist. Haben zwei Leute dieselbe Datei geändert, wählst du pro Datei deine oder ihre Version und pushst. History listet jede Synchronisierung auf, und ein einzelner Request hat seinen eigenen History-Button: Stell die Version von letztem Dienstag für einen Request wieder her, und die nächste Synchronisierung hält das als neue Änderung fest.

Vor jedem Commit sucht eine Secret-Prüfung nach API-Keys, GitHub-, Slack-, AWS- und Google-Schlüsseln, JWTs, privaten Schlüsseln und Passwörtern in URLs. Findet sie eines, wird nichts committet, und du erfährst Datei und Zeile, nie den Wert.

GitHub, GitLab oder gar kein Server

GitHub verbindest du über dein Apiboo-Konto; GitLab.com und selbst gehostetes GitLab melden sich mit einem Personal Access Token an, das in deinem System-Schlüsselbund liegt; Gitea, Forgejo, Codeberg, Bitbucket und Firmenserver funktionieren über HTTPS oder SSH mit einer Anmeldung aus deinem Vault. Connect & push legt das Repository auf GitHub und GitLab an, falls es noch nicht existiert.

Du brauchst nicht einmal einen Server. This device only speichert jede gesicherte Version auf deinem Rechner, mit denselben Änderungen, derselben Historie und Wiederherstellung, und Add a remote schickt die gesamte Historie später in derselben Reihenfolge an einen Server. Für ein Team verbinden die Owner das Repository des Teams einmal, und jedes Mitglied tritt mit dem eigenen Konto bei; niemandes Anmeldung wird geteilt.

Dein KI-Agent liest dieselben Dateien

Wenn Collection, Docs und Tasks einfache Dateien im Repository sind, kann ein Coding-Agent wie Claude Code oder Codex sie wie Code lesen: den Request, den er aufrufen soll, das Dokument, das den Endpoint erklärt, den Task, an dem er gerade arbeitet. Apiboo hat außerdem einen eingebauten MCP-Server für Agenten, die innerhalb der App arbeiten, mit Berechtigungen, die du pro Bereich einschaltest. So oder so schauen der Agent und du auf dieselbe Source of Truth.

Ehrliche Grenzen

Git gibt es nur in der Desktop-App.
Konflikte löst du pro Datei (deine oder ihre Version), nicht zeilenweise innerhalb von Apiboo; für einen zeilenweisen Merge nimm deine eigenen Git-Tools im Repository.
Die Historie eines Teams muss auf einem Server liegen; This device only ist für deine eigenen Workspaces, Projekte, Boards und Dokumente gedacht.
Einfache http://-Adressen funktionieren nur für Server auf deinem eigenen Rechner, und Dateien über 48 MB werden nicht gelesen.
Wenn du einen verknüpften Workspace umbenennst, wird er nur in Apiboo umbenannt; das Repository behält seinen Namen.

Weiterlesen

Den vollständigen Guide findest du unter apiboo.com/docs/getting-started/git. Einen direkten Vergleich mit dem Git-nativen Open-Source-Client gibt es unter apiboo.com/compare/bruno, und einen Überblick über das gesamte Feld unter apiboo.com/blog/best-rest-api-clients-2026.

Probier es mit deiner eigenen Arbeit aus

Importiere deine Collection (Postman, Insomnia, Bruno, Hoppscotch, OpenAPI oder HAR), öffne die Git-Seite und klicke auf Connect to a repository, oder wähle This device only, um ohne Server zu starten.

Lade Apiboo für Windows, macOS oder Linux unter apiboo.com/download herunter. Der Einstieg ist kostenlos, ohne Karte und ohne Konto: Jedes Tool läuft auf deinem eigenen Rechner, und du meldest dich nur an, wenn du Sync oder ein Team willst.