Obsidian für Software-Teams: Markdown-Docs & Boards in Git (2026)

Obsidian hat seine Fans zu Recht: lokale Markdown-Dateien, schnelle Suche, Links und ein Graph, dazu ein Plugin für nahezu alles. Viele Entwickler führen ihre eigenen Notizen darin und wünschen sich dasselbe fürs Team: Specs, Runbooks und Entscheidungen als einfache Dateien, versioniert, lesbar für jedes Tool und für jeden KI-Agenten. Dann versucht das Team, einen Vault zu teilen, und die Kanten werden sichtbar.

Dieser Beitrag zeigt, wo Obsidian für ein Software-Team aufhört, die einfache Wahl zu sein, wie Docs-as-Code aussehen sollte und wie Apiboo das angeht: Dokumente und Boards, die neben deinen API-Collections liegen und als Markdown und YAML in dein Git-Repository geschrieben werden. Wir machen Apiboo, und im Abschnitt zu den Grenzen steht, was es nicht kann – einschließlich des Plugin-Ökosystems, an das nichts anderes heranreicht.

Wo Obsidian im Team unbequem wird

Einen Vault zu teilen erfordert Obsidian Sync im Account jedes Mitarbeitenden, zu einem Preis pro Nutzer, oder ein Git-Plugin und ein Repository, das alle von Hand pullen und pushen müssen. Wenn zwei Leute gleichzeitig dieselbe Notiz bearbeiten, gibt es in beiden Fällen einen Merge-Konflikt.
Ein Vault besteht aus Dateien in einem Ordner. Zugriffskontrolle ist das, was der Ordner oder das Repository hergibt – ein Konzept von Team-Bereich gegenüber persönlichen Notizen gibt es nicht.
Aufgaben stecken in Notizen (Checkboxen oder ein Kanban-Plugin). Für eine Person ist das in Ordnung, für ein Team, das Listen, Zuständige, Fälligkeitsdaten und Kommentare braucht, ist es zu dünn.
Die API-Collection, die die Doku beschreibt, lebt in einer anderen App mit eigenem Speicher. Die Verbindung zwischen einer Spec und dem Request, den sie spezifiziert, ist bestenfalls eine URL.
Die gute Nachricht: Obsidians kommerzielle Lizenz ist seit Februar 2025 optional, die Lizenz ist also nicht mehr das Hindernis – das Teilen ist es.

Wie Docs-as-Code für ein Dev-Team aussehen sollte

Wenn die Dokumentation deines Teams in Git leben soll, braucht es vier Dinge, damit es nicht nur möglich ist, sondern auch funktioniert:

Reines Markdown, eine Datei pro Seite, in einer Ordnerstruktur, die man ohne jede App auf GitHub durchstöbern kann.
Ein Editor, in dem die Leute wirklich schreiben: Slash-Befehle, Tabellen, Codeblöcke, Bilder, Unterseiten. Rohes Markdown in einer IDE schreckt die Hälfte des Teams ab.
Aufgaben im selben Repository, als Dateien, sodass ein Pull Request die Spec und die Aufgabe, die sie angestoßen hat, gemeinsam ändern kann.
Live-Bearbeitung für die gemeinsamen Seiten des Teams, mit Git als Historie und Review-Kanal – nicht als einziger Weg zur Zusammenarbeit.

Wie Apiboo Docs und Aufgaben in dein Repo schreibt

In Apiboo ist Documents ein Block-Editor mit Slash-Menü (Überschriften, Zitate, Codeblöcke mit Syntax-Highlighting für sechzehn Sprachen, Tabellen, To-do-Listen, Bilder, YouTube- und Vimeo-Einbettungen, Unterseiten). Er versteht Markdown beim Tippen: #, >, -, 1., - [ ], drei Backticks sowie Inline-Fett, -Kursiv und -Code. Die Seiten liegen in einem Ordnerbaum mit persönlichen Seiten, Seiten, die nur auf diesem Gerät bleiben, und einem Bereich pro Team. Team-Dokumente werden live von allen im Team bearbeitet.

Verbinde My projects, boards & documents auf der Git-Seite mit einem Repository, und Apiboo schreibt documents/ mit jeder Seite als .md-Datei, Unterseiten in einem Ordner, der nach ihrer Seite benannt ist, und Bildern unter documents/media/; boards/<name>/ mit einer board.yaml für die Listen und Labels und einer Markdown-Datei pro Aufgabe in tasks/, inklusive ihrer Kommentare; und projects/ mit einer YAML-Datei pro Projekt und den Verknüpfungen zwischen ihnen. Andere Dateien im Repository, etwa eine README oder dein Code, werden nie angefasst.

Apiboo committet oder pusht nie von selbst. Sync now committet und pusht, Pull holt die Änderungen des Repositorys in Apiboo, und wenn ein Pull mehr als zehn Einträge auf einmal löschen würde, behält Apiboo sie und sagt dir Bescheid – ein Fehler im Repository kann deine Seiten also nicht ausradieren. Vor jedem Commit läuft eine Secret-Prüfung.

Docs, Aufgaben und APIs, die voneinander wissen

Was Obsidian nicht bieten kann, ist Nähe. In Apiboo liegen die Bookshop-Spec, das Bookshop-Board und die Bookshop-Collection in derselben App, und der Graph zeigt, wie sie zusammenhängen: Seitenlinks erscheinen als Links to und Linked from, und ein Projekt bündelt seine Dokumente, Aufgaben, Requests und die Repositories seines Codes. Ein KI-Agent, der über Apiboos MCP server angebunden ist, kann ein ganzes Projekt in einem Aufruf abfragen und die Spec, die offenen Aufgaben und die Requests lesen, bevor er etwas anfasst – ohne Zugriff auf den Vault und auf jegliche Secrets. Das ist der Kontext, den ein Coding-Agent braucht und den ein Ordner voller Notizen ihm nicht geben kann.

Was Apiboo nicht kann

Sei ehrlich zu dir selbst, bevor du einen Vault umziehst:

Keine Plugins, keine Community-Themes, kein Dataview. Obsidians Ökosystem ist der Grund zu bleiben, und hier ersetzt es nichts.
Der Editor ist kein Markdown-Quelltext-Editor. Du tippst Markdown-Kürzel und bekommst Blöcke; die Rohdatei siehst du in der App nicht. Die Rohdatei ist das, was im Repository landet.
Dokumente liegen in der eigenen Datenbank der App und werden von Apiboo nach Git geschrieben; das Repository ist eine synchronisierte Kopie deiner Seiten, nicht der Ordner, den der Editor öffnet.
Git gibt es nur in der Desktop-App, und die Historie eines Teams muss auf einem Server liegen; This device only ist für deine eigenen Seiten gedacht.
Konflikte werden pro Datei gelöst, deine oder ihre Version, nicht zeilenweise innerhalb von Apiboo.

Wer was nutzen sollte

Persönliche Wissensdatenbank, viele Plugins → Obsidian, keine Frage.
Ein Team, das seine Docs schon im Repository schreibt und in Pull Requests reviewt → Markdown in Git behalten; ein schlichter Editor und CI reichen.
Ein Dev-Team, das einen richtigen Editor, Aufgaben und die API-Collection an einem Ort will, mit Markdown und YAML im eigenen Repository als Dokumentation → Apiboo.
Den passenden Leitfaden zu Collections in Git findest du unter apiboo.com/blog/api-collections-in-git, die Board-Seite unter apiboo.com/blog/kanban-board-for-developers.

Probier es mit deiner eigenen Arbeit aus

Lege ein Dokument an, schreibe eine Spec mit dem Slash-Menü, füge ein Board mit drei Aufgaben hinzu, öffne dann die Git-Seite und verbinde ein Repository: Beim nächsten Sync now siehst du das Markdown und YAML, das Apiboo geschrieben hat, in einem Layout, das du auf GitHub lesen kannst.

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