Der Git-Workflow, der tatsächlich für Solo-Entwickler funktioniert
Ich erinnere mich noch genau an den Moment, als ich zusammenbrach. Es war 2 Uhr morgens an einem Dienstag, und ich starrte auf einen Merge-Konflikt zwischen meinem `feature/redesign` Branch und `main`. Der Clou? Ich war der einzige Entwickler im Projekt. Ich war buchstäblich in einem Merge-Konflikt mit mir selbst. Drei Tage Arbeit—weg. Nicht wegen eines katastrophalen Festplattenausfalls oder eines gelöschten Repositories. Nein, ich verlor diese drei Tage, weil ich einen Git-Workflow befolgt hatte, der für Teams von 10+ Entwicklern entwickelt wurde. Ich hatte Feature-Branches, Hotfix-Branches, Release-Branches und einen `develop` Branch, der nur existierte, um mir ein professionelles Gefühl zu geben. Die Ironie entging mir nicht: Ich hatte mehr Zeit mit der Verwaltung von Git verbracht, als tatsächlich Code zu schreiben. An diesem Abend, in meinem Home Office mit kaltem Kaffee und einem verletzten Ego, traf ich eine Entscheidung. Ich würde jeden Teil von Git-Zeremonie abbauen, der mir als Solo-Entwickler nicht diente. Keine weiteren Cargo-Kulte-Team-Workflows. Kein vorgeben, ich bräuchte die gleiche Infrastruktur wie ein 50-köpfiges Engineering-Team. Was aus dieser Frustration entstand, ist der Workflow, den ich seitdem für über 40 Solo-Projekte verwendet habe. Er ist nicht sexy. Er wird niemanden auf einer Tech-Konferenz beeindrucken. Aber er funktioniert, und noch wichtiger, er steht mir nicht im Weg, damit ich tatsächlich Dinge bauen kann.Warum die meisten Git-Workflows für Solo-Entwickler scheitern
Das Problem bei den meisten Git-Tutorials und -Workflows ist, dass sie von Personen geschrieben werden, die in Unternehmen mit mehreren Teams, Code-Review-Prozessen und Deployment-Pipelines arbeiten, die mindestens drei verschiedene Umgebungen umfassen. Wenn du ein Solo-Entwickler bist, hast du diese Einschränkungen nicht—aber du hast auch nicht diese Sicherheitsnetze. GitFlow, der Workflow, der die 2010er Jahre dominierte, ist ein perfektes Beispiel. Er wurde von Vincent Driessen für ein spezifisches Problem entworfen: das Management von Releases für Software, die mehrere Versionen gleichzeitig unterstützen musste. Wenn du eine Desktop-Anwendung baust, die Kunden lokal installieren, macht GitFlow Sinn. Wenn du ein Solo-Entwickler bist, der ein SaaS-Produkt oder eine Kundenwebsite versendet, ist es kompletter Overkill. Die typische Reise eines Solo-Entwicklers mit Git läuft ungefähr so ab: Du beginnst einfach mit dem Committen auf `main` (oder `master`, je nachdem, wann du Git gelernt hast). Dann liest du einen Artikel über „professionelle Git-Workflows“ und fühlst dich schuldig. Du implementierst Feature-Branches. Dann fügst du einen `develop` Branch hinzu, weil das das Diagramm zeigte. Bevor du es bemerkst, verbringst du 20 Minuten am Tag nur mit der Verwaltung von Branches und bist dir nicht einmal sicher, warum die Hälfte davon existiert. Ich war schon dort. Ich hatte Repositories mit Branches, die `feature/new-feature`, `feature/new-feature-2`, `feature/new-feature-actually-final` und `feature/new-feature-for-real-this-time` hießen. Wenn du niemals eine Branch-Naming-Krise hattest, lügst du entweder oder du entwickelst nicht lange genug alleine. Das grundlegende Problem ist, dass Team-Workflows dazu entworfen sind, Teamprobleme zu lösen: die Koordination der Arbeit zwischen mehreren Personen, die Vermeidung von Konflikten, das Management von Code-Review-Prozessen und die Aufrechterhaltung der Stabilität in gemeinsam genutzten Umgebungen. Wenn du alleine arbeitest, existieren die meisten dieser Probleme einfach nicht. Du kannst keinen Merge-Konflikt mit jemand anderem haben, wenn es niemanden gibt.Die Drei-Commit-Regel, die alles änderte
Nach meinem 2-Uhr-Morgens-Desaster begann ich, meine tatsächlichen Arbeitsmuster zu analysieren. Ich zog meinen Git-Verlauf der letzten sechs Monate auf und sah mir jeden Branch an, den ich erstellt hatte, jeden Merge, den ich gemacht hatte, und jeden Konflikt, den ich gelöst hatte. Was ich fand, war aufschlussreich. Neunzig Prozent meiner Feature-Branches enthielten drei Commits oder weniger vor dem Mergen. Das waren keine komplexen, mehrwöchigen Features, die Isolation benötigten. Es waren kleine Verbesserungen, Bugfixes und inkrementelle Änderungen, die ich künstlich in Branches separiert hatte, weil ich dachte, das sei das, was „echte Entwickler“ tun. Die verbleibenden zehn Prozent—die tatsächlichen komplexen Features—waren die, bei denen Branches sinnvoll waren. Aber selbst dann fiel mir etwas auf: Die Branches, die Probleme verursachten, waren die, die ich länger als eine Woche offen gelassen hatte. Je länger ein Branch lebte, desto wahrscheinlicher war es, dass er beim Zurück-Mergen Probleme verursachte. Das führte mich zu dem, was ich die Drei-Commit-Regel nenne: Wenn eine Änderung mehr als drei Commits benötigt, ist sie wahrscheinlich zu groß und sollte in kleinere Teile zerlegt werden. Wenn sie nicht zerlegt werden kann, ist es einer der seltenen Fälle, in denen ein Branch tatsächlich hilft. Diese Regel zwang mich, anders über meine Arbeit nachzudenken. Anstatt einen Branch für „das gesamte UI redesignen“ zu erstellen, würde ich einen Branch für „Schaltflächenstile aktualisieren“ oder „neues Navigationskomponenten implementieren“ erstellen. Jeder Branch lebte maximal einen oder zwei Tage, enthielt fokussierte Änderungen und wurde sauber gemergt. Der psychologische Wandel war erheblich. Ich hörte auf, in Begriffen von „Features“ zu denken, und begann in Begriffen von „bereitstellbaren Inkrementen“ zu denken. Jeder Branch musste etwas repräsentieren, das ich in die Produktion senden konnte, ohne bestehende Funktionalität zu brechen. Das hielt die Branches natürlich klein und kurzlebig.Der Tag, an dem ich einen Bug in die Produktion brachte (und warum es meinen Workflow besser machte)
Lass mich dir von der schlimmsten Bereitstellung meiner Karriere erzählen. Ich arbeitete an einem Kundenprojekt—einem Buchungssystem für eine kleine Hotelkette. Ich hatte zwei Wochen an einem Feature-Branch gearbeitet (ja, ich weiß, ich habe meine eigene Regel gebrochen), der eine neue Zahlungsintegration hinzufügte. Der Branch hatte sich erheblich von `main` getrennt. Ich war so auf das Zahlungsfeature konzentriert, dass ich nicht mit den kleinen Fixes und Verbesserungen, die ich direkt für `main` bei dringenden Kundenanfragen gemacht hatte, Schritt gehalten hatte. Als es Zeit zum Mergen war, hatte ich Konflikte in 14 Dateien. Ich löste die Konflikte, führte die Tests aus (sie bestanden) und stellte in die Produktion bereit. Innerhalb einer Stunde erhielt ich einen panischen Anruf vom Kunden. Das Buchungsformular war kaputt. Nicht die neue Zahlungsintegration—das grundlegende Buchungsformular, das seit Monaten einwandfrei funktionierte. Was passierte? Beim Lösen eines der Merge-Konflikte hatte ich versehentlich die falsche Version einer Funktion beibehalten. Die Tests hatten es nicht entdeckt, weil ich keine Tests für diesen speziellen Edge-Case geschrieben hatte (Lektion gelernt). Der Bug war ganz meine Schuld, aber der Workflow hatte es einfach gemacht, diesen Fehler zu machen. Dieser Vorfall lehrte mich etwas Entscheidendes: Als Solo-Entwickler ist mein größtes Risiko nicht der Code anderer Menschen—es ist mein eigener Code von vor zwei Wochen. Wenn ich zwischen verschiedenen Teilen eines Projekts wechsle, arbeite ich im Wesentlichen mit früheren Versionen meiner selbst zusammen. Und das frühere Ich ist oft ein unzuverlässiger Kollege. Diese Erkenntnis führte zum zweiten Pfeiler meines Workflows: der Eine-Woche-Regel. Kein Branch lebt länger als eine Woche. Wenn ein Feature länger als das dauern soll, breche ich es in kleinere Teile, die jeweils innerhalb einer Woche abgeschlossen und gemergt werden können. Wenn das nicht möglich ist, benutze ich Feature-Flags, um unvollständigen Code in `main` zu mergen, während ich ihn vor den Benutzern verstecke. Die Eine-Woche-Regel hat mich unzählige Male gerettet. Sie zwingt mich, nah bei `main` zu bleiben, was bedeutet, dass ich immer mit der aktuellsten Version der Codebasis arbeite. Sie verhindert die Art von Divergenz, die zu komplexen Merge-Konflikten führt. Und sie hält mich ehrlich bezüglich des Umfangs—wenn ich etwas in einer Woche nicht abschließen kann, versuche ich wahrscheinlich, zu viel auf einmal zu tun.Die tatsächlichen Kosten von Branch-Komplexität
Lass uns über Zahlen sprechen. Ich habe meine Git-bezogenen Aktivitäten drei Monate lang vor und nach der Vereinfachung meines Workflows verfolgt. Die Ergebnisse waren deutlich:| Aktivität | Vorher (Stunden/Woche) | Nachher (Stunden/Woche) | Gesparte Zeit |
|---|---|---|---|
| Erstellen und Verwalten von Branches | 2.5 | 0.5 | 2 Stunden |
| Behebung von Merge-Konflikten | 3.0 | 0.3 | 2.7 Stunden |
| Entscheiden, an welchem Branch gearbeitet werden soll | 1.5 | 0.1 | 1.4 Stunden |
| Bereinigen von veralteten Branches | 1.0 | 0.1 | 0.9 Stunden |
| Rebasing und Synchronisieren von Branches | 2.0 | 0.2 | 1.8 Stunden |
| Gesamter Git-Overhead | 10.0 | 1.2 | 8.8 Stunden |
Warum "Früh committen, oft committen" für Solo-Entwickler falsch ist
Hier ist eine kontroverse Meinung: der Rat, „früh zu committen, oft zu committen“, ist tatsächlich schädlich für Solo-Entwickler. Ich weiß, dass das gegen die traditionelle Weisheit geht, aber hör mir zu.Der Zweck von Commits ist nicht, ein detailliertes Protokoll über jede Tasteneingabe zu erstellen. Es geht darum, bedeutungsvolle Kontrollpunkte zu schaffen, die eine Geschichte darüber erzählen, wie sich dein Code entwickelt hat. Wenn du allein arbeitest, bist du die einzige Person, die das verstehen muss.