Git ist für viele Einzelentwickler ein merkwürdiges Schauspiel: Sie bauen allein an einem Projekt, führen aber einen Workflow auf, als säßen im Hintergrund drei Teams, ein Release-Manager und ein Compliance-Ausschuss. Genau gegen diese Überinszenierung richtet sich der jüngste Aufhänger aus der Dev-Community: Die Frage ist nicht, welcher Git-Workflow theoretisch elegant ist, sondern welcher für Solo-Projekte tatsächlich trägt. Und da scheitert erstaunlich viel an derselben Stelle: an zu vielen Regeln, zu vielen Branches und zu wenig Disziplin dort, wo sie wirklich zählt.
Die Provokation ist simpel: Wer allein entwickelt, braucht keine Workflow-Religion. Er braucht ein System, das Fehler begrenzt, Entscheidungen nachvollziehbar macht und bei einem Absturz nicht mit abstürzt. Git ist dafür stark genug. Aber nur, wenn man es nicht wie ein Team-Drama behandelt. Der Fehler vieler Solo-Setups ist nicht mangelnde Technik, sondern zu viel Zeremonie. Ein Branch für dies, ein Branch für das, ein Merge-Target für die Zukunft – und am Ende ist die eigentliche Arbeit schwerer zu finden als ein Bug, der nur sonntags auftritt.
Der Kern eines brauchbaren Solo-Workflows ist deshalb unspektakulär, fast frech banal: Ein stabiler Hauptzweig, kleine Commits, klare Commit-Nachrichten, regelmäßige lokale Sicherungspunkte und ein bewusster Umgang mit experimentellen Änderungen. Wer Funktionen testet, kann dafür kurzlebige Branches nutzen. Wer nur allein an einer Idee schraubt, muss aber nicht so tun, als wäre jeder Gedankengang ein Release-Prozess. Das ist der erste nützliche Gegenentwurf zum klassischen Team-Workflow: Nicht alles muss in Branch-Architektur gegossen werden, nur weil Git das erlaubt.
Ein zweiter, oft unterschätzter Punkt ist die Wiederherstellbarkeit. Viele Solo-Entwickler denken bei Git vor allem an Zusammenarbeit oder Publikation. Dabei ist der eigentliche Wert viel prosaischer: Git ist ein Rückweg. Ein sauberer Verlauf schützt vor dem Klassiker, der im Solo-Betrieb besonders teuer ist: dem unkontrollierten Umbau auf dem Hauptzweig. Wer nur auf Sicht entwickelt und Änderungen zu lange offen lässt, produziert keine Freiheit, sondern technischen Schuldenstand. Dann wird aus Schnelligkeit bloß ein späterer Reparaturstau.
Hier liegt auch der blinde Fleck vieler moderner Entwicklungsratschläge. Sie tun so, als sei Komplexität automatisch Professionalität. Das stimmt nicht. Für Einzelentwickler ist ein Workflow dann professionell, wenn er die kognitive Last senkt. Ein Prozess mit fünf Merge-Pfaden und drei Review-Stufen ist nicht robuster, sondern oft nur dekorativer. Er sieht nach Kontrolle aus, erzeugt aber vor allem Reibung. Und Reibung ist im Solo-Projekt selten ein Qualitätsmerkmal, sondern meist ein Vorbote von Aufschub.
Das heißt nicht, dass Trunk-Based Development, Git Flow oder GitHub Flow grundsätzlich falsch wären. Sie sind nur für andere Machtverhältnisse gebaut. Git Flow etwa kann in großen Teams mit Releases, Hotfixes und klarer Rollenverteilung sinnvoll sein. Für Einzelentwickler ist er oft das digitale Gegenstück zu einem Werkzeugschrank mit 18 Schubladen, obwohl man eigentlich nur einen Schraubendreher sucht. Trunk-Based Development ist schlanker, kann aber ohne Disziplin schnell in eine Serie unübersichtlicher Zwischenstände kippen. GitHub Flow wiederum ist angenehm leicht, setzt aber voraus, dass man Pull-Requests, Reviews und Deployment nicht mit dem Solo-Alltag verwechselt. Kurz: Die bekannten Modelle sind Werkzeuge, keine moralischen Wahrheiten.
Pragmatisch sieht ein Solo-Workflow eher so aus: Der Hauptzweig bleibt jederzeit lauffähig oder zumindest klar reproduzierbar. Neue Arbeit entsteht in kleinen, klar benannten Branches oder direkt in kurzen Commits auf dem Hauptzweig, wenn das Projekt und die persönliche Arbeitsweise das tragen. Jeder Commit beantwortet eine einfache Frage: Was wurde verändert, und warum? Große Umbauten werden in überschaubare Schritte zerlegt. Vor riskanten Änderungen gibt es einen Commit oder Tag, der als Rücksprungpunkt dient. Wer zusätzlich Releases oder Meilensteine markiert, gewinnt nicht nur Ordnung, sondern auch eine Art technische Erinnerung. Das ist banal. Und genau deshalb funktioniert es.
Eine unterschätzte Einsicht: Für Solo-Projekte ist der beste Workflow oft nicht der mit der höchsten formalen Sicherheit, sondern der mit der niedrigsten Wahrscheinlichkeit, dass man ihn im Alltag umgeht. Viele scheitern nicht an Git, sondern an ihrer eigenen Neigung, den Prozess erst dann zu lieben, wenn alles schon brennt. Ein Workflow, der zu schwer ist, wird im Solo-Betrieb nicht konsequent eingehalten. Dann ist er keine Struktur, sondern ein gutes Vorsatzsystem. Und Vorsätze haben in der Versionsverwaltung bekanntlich eine kurze Halbwertszeit.
Die Gegenposition verdient trotzdem Fairness. Wer an sicherheitskritischer Software, an langfristig gepflegten Produkten oder in streng regulierten Umgebungen arbeitet, kann sich auch allein nicht mit Minimalismus herausreden. Dort sind klare Branch-Regeln, Review-Schritte oder Release-Artefakte sinnvoll, selbst wenn die Person am Rechner nur eine ist. In solchen Fällen ist der Workflow nicht Selbstzweck, sondern Nachweisbarkeit. Der entscheidende Punkt bleibt aber derselbe: Die Komplexität muss aus dem Risiko kommen, nicht aus Gewohnheit oder aus der Sehnsucht, es möge irgendwie nach „professioneller Entwicklung“ aussehen.
Genau deshalb ist die Debatte um Solo-Git mehr als eine Stilfrage. Sie ist eine Frage von Kontrolle. Wer allein entwickelt, hat keine Teamstruktur, die Fehler abfedert. Dafür hat er die Freiheit, den Prozess selbst zu gestalten. Diese Freiheit sollte nicht mit Workflow-Theater verspielt werden. Ein guter Solo-Git-Workflow ist nicht der, der am meisten Regeln hat, sondern der, der im Ernstfall den saubersten Rückweg bietet. Alles andere ist oft nur eine sehr elegante Form des Aufschiebens.
Die unbequeme Wahrheit lautet deshalb: Wer allein arbeitet und trotzdem Git Flow imitiert, verwaltet häufig nicht sein Projekt, sondern seine Unsicherheit. Besser ist ein schlanker, disziplinierter Ablauf mit kleinen Commits, klaren Rücksprungpunkten und so wenig Branch-Drama wie möglich. Nicht mehr Zeremonie macht Solo-Entwicklung professionell, sondern weniger Ausreden.