Git hat gewonnen. Das ist unbestritten. Aber “gewonnen” heißt nicht “perfekt” – und in den letzten Jahren tauchen immer mehr Tools auf, die genau an den Ecken ansetzen, an denen Git seit Jahrzehnten aneckt: verwirrende Staging-Area, Merge-Konflikte die deinen ganzen Workflow blockieren, eine Historie die sich anfühlt wie eingemeißelt statt gestaltbar.
Die meisten dieser Tools gehen dabei denselben Weg wie Git: dezentral, jeder Client eine vollständige Kopie der Historie. Pogo macht das Gegenteil. Es ist ein zentralisiertes Version Control System – ein Server ist die einzige Quelle der Wahrheit, Clients arbeiten dagegen. Klingt erstmal nach einem Rückschritt zu SVN-Zeiten. Ist es aber nicht ganz, denn Pogo bringt moderne Konzepte mit: veränderbare Changes statt starrer Commits, Konflikte die deinen Workflow nicht blockieren, und ein Branching-Modell komplett ohne Namenszwang.
Schauen wir uns an, was hinter der Idee steckt und ob sich der zentrale Ansatz für dich lohnen könnte.
Zentral statt dezentral: Ein bewusster Rückschritt?
Bei Git hat jeder Entwickler die komplette Historie lokal. Das ist mächtig, bringt aber auch Overhead mit sich: Du musst pullen, pushen, dich um Remotes kümmern und im Zweifel mit mehreren “Wahrheiten” jonglieren, die erst durch einen Merge zusammenfinden.
Pogo dreht das um. Es gibt genau einen Server, der deine Daten hält – dein Single Source of Truth. Der Client ist bewusst simpel gehalten: eine CLI, die mit dem Server spricht, dazu ein schlankes Web-UI zum Durchstöbern der Repositories. Du deployst den Server selbst, zum Beispiel mit Docker:
docker pull ghcr.io/pogo-vcs/pogo:alpine
Dahinter steckt eine PostgreSQL-Datenbank, die Konfiguration läuft komplett über Umgebungsvariablen wie DATABASE_URL oder PUBLIC_ADDRESS. Kein Ceremoniell, keine zusätzliche Software – ein Container, eine Datenbank, fertig.
Der Kompromiss ist offensichtlich: Ohne Verbindung zum Server kannst du nicht pushen oder die Historie synchronisieren. Für ein Open-Source-Projekt mit hunderten Contributoren rund um den Globus ist das ein Show-Stopper. Für ein Team, das ohnehin ständig online ist und sich nie um Offline-Fähigkeit geschert hat, ist es dagegen einfach… eine Sorge weniger. Du brauchst keine Remotes verwalten, keine Forks synchronisieren, keine Frage “wer hat jetzt die aktuelle main”. Es gibt nur einen Ort, an dem die Wahrheit liegt.
Changes statt Commits: Mutable History
Der zweite große Bruch mit Git-Gewohnheiten: Pogo kennt keine Commits, sondern Changes. Der Unterschied ist mehr als Semantik. Ein Git-Commit ist (von --amend abgesehen) unveränderlich – einmal committed, bleibt er, wie er ist. Eine Pogo-Change dagegen ist ein lebendiger Container für deine Arbeit, den du beliebig oft überschreibst, bis du sagst: “Dieser Change ist fertig.”
Der Workflow sieht dabei so aus, dass du zuerst beschreibst, was du vorhast, und danach erst codierst:
# Repository initialisieren und mit dem Server verbinden
cd my-project
pogo init --name my-project --server your-server.com:8080
# Bevor du irgendetwas programmierst: beschreiben, was du vorhast
pogo describe --message "feat: add initial project structure"
# Jetzt normal arbeiten
echo "# My Project" > README.md
mkdir src
echo "console.log('Hello, Pogo!');" > src/index.js
# Änderungen zum Server schicken
pogo push
Was hier passiert: pogo push überschreibt so lange dieselbe Change, bis du explizit pogo new aufrufst, um eine neue zu beginnen. Es gibt kein git add, keine Staging-Area, kein “ups, ich hab vergessen die Datei hinzuzufügen”. Du beschreibst deine Absicht (idealerweise als Conventional-Commit-Message), arbeitest, pushst – und kannst die Beschreibung jederzeit nachschärfen, wenn sich dein Plan während der Arbeit ändert:
pogo describe --message "feat: add initial project structure and config loader"
Eine Einschränkung gibt es: Sobald eine Change Kinder hat oder von einem Bookmark referenziert wird, kannst du sie nicht mehr überschreiben. Ab dann ist sie fixiert – genau wie ein Git-Commit, der schon gepusht wurde. Das ergibt Sinn: Sobald andere auf deiner Arbeit aufbauen, darf sich der Boden unter ihren Füßen nicht mehr verschieben.
Keine benannten Branches, dafür Bookmarks
In Git ist ein Branch ein beweglicher Zeiger mit einem Namen, den du dir merken (und pflegen) musst: feature/login, hotfix/payment-bug, release/2.1. Pogo verzichtet komplett auf dieses Konzept.
Stattdessen: Jeder Change kann beliebig viele Kind-Changes haben. Erzeugst du zwei Kinder desselben Change, hast du de facto zwei Branches – nur ohne Namen. Jeder Change bekommt automatisch eine eindeutige, zufällig generierte ID (Base32-codiert, bewusst ohne verwechselbare Zeichen wie l, 1, I oder 0, O):
pogo log
● KPHRpdJnwyPcLH4a
│ hi, pogo
○ DKJbFrEkyhLpnCm3
│ merge
○─┤ RJcALPmeLceea4hL
│ │ hello, pogo
│ ╰─○ wEpaCJnAELNrDFyk
│ │ hi, world
╰─○─╯ hfEJKLREKxhDfK4b
hello, world
Willst du zwei Zweige zusammenführen, erstellst du einfach einen neuen Change mit mehreren Parents – fertig ist der Merge. Es gibt keinen separaten “Merge-Commit”-Typ wie in Git, es ist einfach ein Change mit mehr als einem Vorgänger.
Damit du trotzdem nicht ständig mit kryptischen IDs jonglieren musst, gibt es Bookmarks. Ein Bookmark ist ein benannter Zeiger auf eine bestimmten Change – im Grunde das, was in Git ein Branch-Name wäre, nur bewusst von der Historie entkoppelt:
pogo bookmark set main
main ist dabei kein reserviertes Wort, sondern eine Konvention: Pogo behandelt ein Bookmark namens main ähnlich wie Git den Default-Branch. Für Releases setzt du dir einfach weitere Bookmarks wie v1.0.0. Das Ergebnis: Du bekommst die Übersichtlichkeit von benannten Branches, ohne dich vorher auf ein Namensschema festlegen zu müssen, bevor du überhaupt weißt, ob der Branch lange lebt.
First-Class Conflicts: Konflikte sind kein Show-Stopper
Das ist vermutlich das ungewöhnlichste Feature von Pogo. In Git – und eigentlich in fast jedem VCS – ist ein Merge-Konflikt eine harte Bremse. Du kannst nicht weiterarbeiten, nicht committen, nicht pushen, bevor der Konflikt aufgelöst ist. Genau dieser Zwang sorgt für Stress: Man löst Konflikte oft hastig, mitten im Feierabend, nur um endlich weiterzukommen.
Pogo behandelt Konflikte als First-Class Citizens. Du kannst eine Change mit ungelösten Konflikten pushen, andere können darauf zugreifen, mit-diskutieren oder sogar selbst an der Auflösung arbeiten. Der Konflikt blockiert nichts – er ist einfach ein Zustand, den ein Change annehmen kann, so wie “fertig” oder “in Arbeit”.
Textkonflikte sehen dabei aus wie gewohnt:
<<<<<<<<< change1
hello, pogo
=========
hi, world
>>>>>>>>> change2
Der Unterschied zu Git: Diese Marker landen nicht in deinem Arbeitsverzeichnis, während du panisch nach der richtigen Version suchst, sondern in einem eigenen Merge-Change, die du in Ruhe bearbeiten kannst – jetzt, später, oder du bittest jemand anderen darum. Im pogo log markiert ein 💥-Symbol jeden Change mit offenen Konflikten, damit nichts stillschweigend untergeht.
Auch bei Binärdateien gibt’s eine pragmatische Lösung: Statt eines unlösbaren Merge-Versuchs bekommst du beide Dateien, umbenannt und klar gekennzeichnet, aus welchem Change sie stammen. Du entscheidest dann händisch, welche bleibt.
Wichtige Einschränkung: Pogo erkennt nur textuelle und binäre Konflikte – keine semantischen. Wenn zwei Changes unabhängig voneinander eine Funktionssignatur ändern und der Code danach zwar sauber mergt, aber zur Laufzeit crasht, bemerkt Pogo davon nichts. Das bleibt Aufgabe deiner Tests.
Erste Schritte mit Pogo
Genug Theorie – so kommst du tatsächlich zum Laufen.
Client installieren
Am einfachsten geht’s über Homebrew (macOS/Linux):
brew install pogo-vcs/tap/pogo
Alternativ über npm, wenn du sowieso in einem Node-Ökosystem unterwegs bist:
npm install -g @pogo-vcs/pogo
Für Windows gibt’s Pogo über Scoop:
scoop bucket add pogo-vcs https://github.com/pogo-vcs/scoop-bucket.git
scoop install pogo
Server aufsetzen
Am schnellsten mit Docker. Du brauchst zusätzlich eine PostgreSQL-Datenbank:
docker pull ghcr.io/pogo-vcs/pogo:alpine
Beim ersten Start erzeugt der Server automatisch einen Root-User samt Personal Access Token und gibt ihn einmalig auf der Konsole aus – merk ihn dir sofort, denn danach wird er nicht mehr angezeigt. Vergiss außerdem nicht, einen Reverse Proxy mit SSL-Zertifikat davorzuschalten, falls der Server öffentlich erreichbar sein soll.
Erstes Repository
# Repository initialisieren und mit dem Server verbinden
cd my-project
pogo init --name my-project --server your-server.com:8080
# Mit dem Personal Access Token einloggen, wenn du danach gefragt wirst
pogo whoami
# Beschreiben, was du vorhast
pogo describe --message "feat: initial project setup"
# Arbeiten wie gewohnt
echo "# My Project" > README.md
# Änderungen an den Server schicken
pogo push
# Aktuellen Stand als "main" markieren
pogo bookmark set main
Damit hast du den kompletten Kreislauf einmal durch: initialisieren, beschreiben, arbeiten, pushen, markieren. Einen Überblick über deine Historie bekommst du jederzeit mit pogo log.
Pro-Tipps / Warnungen
Warnung: Pogo ist ein junges Projekt. Die Community ist klein, die Doku wächst noch, und du wirst vermutlich auf Kanten stoßen, die bei Git längst geglättet sind. Für ein Side-Project oder ein internes Tool ist das ein spannendes Experiment – für dein wichtigstes Produktionsrepo würde ich aktuell noch abwarten, bis sich das Projekt etwas gesetzt hat.
Wichtig: Pogo spricht kein Git-Format und ist nicht Git-kompatibel. Der Umstieg ist ein bewusster Schnitt, kein sanfter Übergang nebenher. Du kannst nicht einfach
pogoneben deinem bestehenden.git-Verzeichnis laufen lassen und schrittweise migrieren – du entscheidest dich für ein Repository.
Tipp: Wenn du in Go entwickelst, lohnt sich ein zweiter Blick: Pogo-Repositories lassen sich direkt als Go-Module importieren, ganz ohne zusätzliche Konfiguration oder Tools. Für Go-Monorepos oder interne Libraries kann das ziemlich viel Boilerplate sparen.
Warnung: Denk beim Server-Setup an den Reverse Proxy. Pogo erkennt zwar automatisch, ob HTTPS verfügbar ist, und fällt sonst auf HTTP zurück – aber “fällt zurück” heißt hier explizit: unverschlüsselt. Ohne TLS davor landet dein Personal Access Token im Klartext auf der Leitung.
Fazit
Pogo ist kein Git-Killer und will das auch gar nicht sein. Es ist ein Gegenentwurf für Teams, die die Verteiltheit von Git nie wirklich gebraucht haben, aber trotzdem an dessen Ecken und Kanten gelitten haben – der Staging-Area, den blockierenden Merge-Konflikten, dem Namenszwang bei Branches. Mit mutablen Changes, First-Class Conflicts und Bookmarks statt starrer Branches macht Pogo einiges anders, ohne dabei kompliziert zu werden.
Der Preis dafür ist Zentralisierung: kein Offline-Arbeiten ohne Server, kein Fork-and-Pull-Modell wie bei Open-Source-Projekten auf GitHub, kein Git-Interop für einen sanften Umstieg. Für ein kleines Team mit eigenem Server und ständiger Verbindung kann genau das aber ein Feature statt ein Bug sein: eine Wahrheit, keine Synchronisationsfragen, ein CLI ohne Ballast.
Ob sich Pogo langfristig durchsetzt, steht in den Sternen – dafür ist das Projekt noch zu jung. Aber die Idee, Konflikte nicht als Show-Stopper, sondern als normalen Zustand zu behandeln, ist einen Blick wert – egal, ob du am Ende bei Pogo landest oder dir davon nur Inspiration für deinen eigenen Git-Workflow holst.