Git-Workflows für Solo-Entwickler: wie viel Prozess ist sinnvoll?

1. Warum Solo-Entwickler trotzdem einen Workflow brauchen

Ein verbreiteter Irrtum lautet, dass Git-Disziplin nur für Teams relevant ist, weil ihr Hauptzweck die Koordination zwischen mehreren Personen sei. Tatsächlich hat ein durchdachter Workflow auch für eine einzelne Person einen klaren Nutzen, nur verschiebt sich der Grund: Es geht nicht um Absprache mit anderen, sondern um die eigene zukünftige Fähigkeit, eine Entscheidung von vor sechs Monaten nachzuvollziehen, einen fehlerhaften Release zu identifizieren oder ein halb fertiges Experiment sauber beiseitezulegen, ohne den Hauptstrang zu verunreinigen.

Der Unterschied zum Team-Workflow liegt vor allem im Umfang: Ein Solo-Entwickler kann sich viele Absicherungen sparen, die primär vor menschlichen Missverständnissen schützen, etwa aufwendige Review-Prozesse oder detaillierte Commit-Konventionen für ein Publikum, das gar nicht existiert. Was bleibt, ist der Teil des Workflows, der die eigene spätere Selbst-Kommunikation und die technische Absicherung gegen Datenverlust betrifft.

2. Trunk-based vs. Feature-Branches allein

Bei einer einzelnen Person entfällt der Hauptgrund für Feature-Branches in einem Team, nämlich dass mehrere Personen gleichzeitig an unterschiedlichen Dingen arbeiten, ohne sich gegenseitig zu blockieren. Für kleine, schnell abgeschlossene Änderungen ist deshalb ein trunk-based Ansatz, bei dem direkt auf dem Hauptbranch gearbeitet wird, oft die einfachste und schnellste Option, weil kein Merge-Overhead entsteht und die Historie linear bleibt.

Sobald eine Änderung aber mehrere Tage oder Wochen dauert, etwa ein größerer Umbau der Architektur, oder wenn parallel an einem Hotfix für die Produktion gearbeitet werden muss, während ein größeres Feature noch nicht fertig ist, lohnt sich ein Feature-Branch auch allein, weil er den unfertigen Stand vom stabilen Hauptbranch trennt. Die praktikable Regel ist, Branches nach der erwarteten Lebensdauer der Änderung zu wählen, nicht nach einer pauschalen Team-Konvention, die für eine Person ohnehin nicht zutrifft.

# Kleine, schnelle Aenderung direkt auf main
git commit -am "fix: Rundungsfehler bei Preisberechnung"
git push origin main

# Größerer Umbau in einem eigenen Branch
git switch -c feature/such-index-neu-aufbauen

3. Commit-Hygiene auch ohne Reviewer

Ohne Reviewer entfällt der externe Druck, verständliche Commit-Nachrichten zu schreiben, aber der Nutzen bleibt bestehen, sobald man selbst in einigen Monaten mit git log nach einer bestimmten Änderung sucht. Ein Commit mit der Nachricht asdf ist für den Autor selbst nach ausreichend Zeit genauso unbrauchbar wie für einen fremden Kollegen, weil das menschliche Gedächtnis Details einer Codebasis erstaunlich schnell verliert.

Ein pragmatischer Mittelweg besteht darin, die Nachricht kurz, aber inhaltlich präzise zu halten, ohne den vollen Formalismus eines Team-Commit-Templates zu übernehmen. Wichtiger als ein striktes Präfix-Schema ist, dass die erste Zeile tatsächlich beschreibt, was sich fachlich geändert hat, damit git log --oneline Monate später als brauchbares Inhaltsverzeichnis der eigenen Arbeit funktioniert.

4. Tags und Versionierung für Releases

Selbst ein einzelner Entwickler profitiert von Tags, sobald eine Software tatsächlich veröffentlicht oder deployed wird, weil ein Tag einen eindeutigen, unveränderlichen Referenzpunkt schafft, der auch nach vielen weiteren Commits auf dem Hauptbranch erhalten bleibt. Ohne Tag lässt sich nach ein paar Wochen nur schwer rekonstruieren, welcher genaue Commit-Stand tatsächlich beim Kunden oder in Produktion lief, was bei einer Fehlersuche entscheidend sein kann.

Semantische Versionierung nach dem Schema MAJOR.MINOR.PATCH lohnt sich auch für ein Ein-Personen-Projekt, weil sie eine klare, konsistente Sprache für die eigene Release-Historie liefert, selbst wenn kein externes Publikum die Versionsnummer sieht. Ein einfaches Skript, das bei jedem Release automatisch tagt, reduziert den Aufwand auf einen einzigen Befehl.

git tag -a v1.4.0 -m "Release 1.4.0: neue Export-Funktion"
git push origin v1.4.0

# Letzten Release-Tag schnell finden
git describe --tags --abbrev=0

5. Minimal sinnvolle CI-Absicherung

Eine vollständige CI-Pipeline mit mehrstufigen Approval-Gates ergibt für ein Solo-Projekt selten Sinn, aber ein minimaler automatisierter Check, der bei jedem Push Tests und Linting ausführt, verhindert zuverlässig, dass ein offensichtlicher Fehler unbemerkt in den Hauptbranch gelangt. Der Wert liegt weniger in der Qualitätssicherung für andere, sondern darin, dass die eigene Aufmerksamkeit nicht ausreicht, um jeden Fehler manuell zu erkennen, besonders spät abends oder nach einer längeren Programmierpause.

Ein einzelner CI-Job, der auf jeden Push reagiert und bei Fehlschlag eine Benachrichtigung sendet, reicht für die meisten Solo-Projekte vollständig aus. Aufwendige Multi-Stage-Pipelines mit separaten Umgebungen für Staging und Produktion lohnen sich erst, wenn das Projekt tatsächlich von echten Nutzern abhängt und ein Fehler reale Konsequenzen hat.

# .github/workflows/ci.yml, minimaler Umfang
name: CI
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test
      - run: npm run lint

6. Backup-Strategie mit mehreren Remotes

Ein Solo-Entwickler hat kein Team, das im Fall eines Festplattenausfalls automatisch eine aktuelle Kopie besitzt, weshalb ein zusätzliches Remote-Repository, das rein als Backup dient, einen der wichtigsten Schutzmechanismen überhaupt darstellt. Ein privates Repository bei einem zweiten Hosting-Anbieter, zusätzlich zum primären Arbeits-Repository, kostet wenig Aufwand und schützt zuverlässig vor dem Totalverlust der Historie.

Der Befehl git remote add in Kombination mit einem einfachen Skript, das nach jedem Arbeitstag auf beide Remotes pusht, reicht als Absicherung völlig aus. Wichtig ist, dass das Backup-Remote unabhängig vom primären Anbieter existiert, damit ein Ausfall oder eine Kontosperrung bei einem Anbieter nicht beide Kopien gleichzeitig betrifft.

git remote add backup https://backup-anbieter.example.com/mein-projekt.git

# Nach jeder Arbeitssitzung
git push origin main
git push backup main

7. Wann sich Pull Requests auch solo lohnen

Auch ohne Reviewer kann ein Pull Request gegen sich selbst sinnvoll sein, weil die Web-Oberfläche einen Diff in einer anderen Ansicht zeigt als der lokale Editor, was gerade bei größeren Änderungen tatsächlich zusätzliche Fehler zutage fördert, die im Editor untergegangen wären. Der eigentliche Wert liegt im Kontextwechsel: Eine Änderung, die man gerade selbst geschrieben hat, wirkt in einer neuen, distanzierten Ansicht anders als im Moment des Schreibens.

Sinnvoll ist das vor allem bei sicherheitskritischen Änderungen, etwa an Authentifizierungslogik oder Datenbank-Migrationen, wo ein zweiter, bewusster Blick den Unterschied zwischen einem sauberen Release und einem nächtlichen Rollback ausmachen kann. Für triviale Änderungen wie eine Tippfehler-Korrektur lohnt sich der zusätzliche Schritt dagegen selten.

8. Typische Über-Prozess-Fallen vermeiden

Ein häufiger Fehler bei Solo-Entwicklern, die aus einem Team-Umfeld kommen, ist die unreflektierte Übernahme kompletter Team-Prozesse, etwa ausführliche Pull-Request-Templates mit mehreren Pflichtfeldern, ein striktes Commit-Format mit erzwungener Ticket-Referenz, obwohl es kein Ticket-System gibt, oder ein mehrstufiges Branch-Modell mit develop, release und hotfix Branches für ein Projekt mit einem einzigen Deployment-Ziel.

Jeder dieser Prozessschritte hatte im ursprünglichen Team-Kontext einen konkreten Grund, meist die Koordination zwischen mehreren Personen oder mehreren parallelen Releases, der für eine einzelne Person schlicht nicht existiert. Die praktikable Heuristik ist, bei jedem übernommenen Prozessschritt zu fragen, welches konkrete Problem er löst, und ihn zu streichen, sobald keine überzeugende Antwort mehr existiert.

9. Ein pragmatisches Beispiel-Setup

Ein bewährtes Minimal-Setup für ein Solo-Projekt kombiniert trunk-based Entwicklung für kleine Änderungen mit kurzlebigen Feature-Branches für größere Umbauten, semantische Tags bei jedem Release, ein einzelner CI-Job für Tests und Linting sowie ein zusätzliches Backup-Remote. Dieses Setup deckt die zentralen Risiken ab, nämlich Datenverlust, unbemerkte Fehler und eine unklare Release-Historie, ohne unnötigen Verwaltungsaufwand zu erzeugen.

Der entscheidende Punkt ist, dass sich dieses Setup mit der Zeit weiterentwickeln darf: Kommt später ein zweiter Entwickler dazu oder wächst das Projekt in seiner Bedeutung, lassen sich Review-Prozesse, ein Commit-Template oder ein umfangreicheres Branch-Modell jederzeit ergänzen, ohne dass die bisherige Historie oder die grundlegende Struktur verworfen werden müsste.

# Minimal-Setup als Checkliste
git init
git remote add origin https://hosting.example.com/mein-projekt.git
git remote add backup https://backup-anbieter.example.com/mein-projekt.git
# CI-Konfiguration (z.B. .github/workflows/ci.yml) hinzufügen
# Ersten Tag nach dem ersten funktionsfähigen Stand setzen
git tag -a v0.1.0 -m "Erster funktionsfähiger Stand"

10. Zusammenfassung

11. FAQ: Solo-Workflows