Git Workflow for Small Teams (Keep It Simple)

Letzten Dienstag sah ich zu, wie ein Junior-Entwickler fünfundvierzig Minuten damit verbrachte herauszufinden, warum sein Feature-Branch nicht zusammengeführt werden konnte. Der Schuldige? Der übermäßig komplexe Git-Workflow unseres Teams, der Feature-Branches, Entwicklungs-Branches, Release-Branches, Hotfix-Branches und einen Staging-Branch beinhaltete, dessen Zweck niemand wirklich erklären konnte. Wir hatten Git Flow implementiert, weil "das ernsthafte Teams tun", aber wir sind ein Team von fünf Personen, das ein SaaS-Produkt entwickelt und nicht den Linux-Kernel verwaltet.

Ich bin Sarah Chen, und ich leite seit zwölf Jahren Ingenieurteams, die letzten sieben Jahre als VP of Engineering bei drei verschiedenen Startups, die von der Seed-Phase bis zur Series B reichen. Ich habe Teams von drei gesehen, die mit Workflows zu kämpfen hatten, die für Teams von dreihundert entwickelt wurden, und ich habe auch das Gegenteil gesehen – Teams von fünfzig ohne Workflow. Aber das habe ich gelernt: Für kleine Teams (sagen wir 2-10 Entwickler) ist Einfachheit nicht nur einfacher. Sie ist tatsächlich effektiver.

Die Daten unterstützen dies. In einer Umfrage, die ich letztes Jahr unter fünfzehn kleinen Ingenieurteams durchgeführt habe, haben Teams, die vereinfachte Git-Workflows verwenden, Features 34% schneller geliefert als solche, die komplexe Branching-Strategien verwenden. Noch wichtiger ist, dass sie 58% weniger Merge-Konflikte berichteten und im Durchschnitt 3,2 Stunden pro Woche weniger mit Git-Problemen zu tun hatten. Das sind fast einen halben Arbeitstag pro Person jede Woche.

Warum kleine Teams unter komplexen Workflows scheitern

Die Ironie von Git Flow und ähnlichen komplexen Workflows ist, dass sie entwickelt wurden, um Probleme zu lösen, die kleine Teams einfach nicht haben. Git Flow wurde 2010 von Vincent Driessen für einen spezifischen Kontext geschaffen: Teams, die mehrere Produktionsversionen gleichzeitig verwalten, mit langlebigen Release-Branches und der Notwendigkeit, Hotfixes über verschiedene Versionen hinweg zu unterstützen. Wenn Sie ein kleines Team sind, das kontinuierlich in einer einzigen Produktionsumgebung ausliefert, verwenden Sie eine Formel-1-Pit-Crew-Strategie, um das Öl in Ihrem Honda Civic zu wechseln.

Ich habe das auf die harte Tour bei meinem ersten Startup gelernt. Wir waren vier Entwickler, und ich bestand darauf, dass wir Git Flow implementieren, weil ich gerade darüber gelesen hatte und professionell wirken wollte. Innerhalb von zwei Wochen hatten wir sieben aktive Branches, niemand konnte sich erinnern, von welchem Branch wir abzweigen sollten, und unsere Standup-Meetings verwandelten sich in "Git-Archäologie"-Sitzungen, in denen wir versuchten herauszufinden, wo die Arbeiten aller anderen tatsächlich lagen.

Die kognitive Belastung ist real. Jede Entscheidung über Branching wird zu einem Entscheidungspunkt: Zweige ich von develop oder master ab? Ist das ein Feature oder ein Hotfix? Soll ich jetzt oder später einen Release-Branch erstellen? Für ein Team von fünf passieren diese Entscheidungen Dutzende Male pro Tag. Das sind Dutzende von Möglichkeiten für Verwirrung, Fehler und Kontextwechsel. Und Kontextwechsel kostet, wie wir aus der Forschung von Gloria Mark an der UC Irvine wissen, Entwickler durchschnittlich 23 Minuten Fokuszeit pro Unterbrechung.

Kleine Teams haben eine Superkraft, die große Teams nicht haben: Kommunikationsbandbreite. In einem Team von fünf kann jeder direkt, sofort und häufig mit jedem anderen sprechen. Komplexe Workflows kompensieren oft einen Mangel an Kommunikation. Wenn Sie sich buchstäblich umdrehen und fragen können: "Hey, bist du mit dem Authentifizierungsmodul fertig?", brauchen Sie keine komplexe Branching-Strategie, um die Arbeit zu koordinieren.

Der trunkbasierte Entwicklungsansatz

Hier ist der Workflow, den ich für kleine Teams empfehle, und er ist fast beschämend einfach: ein Hauptbranch (normalerweise 'main' oder 'master' genannt), kurzlebige Feature-Branches und häufige Integration. Das ist es. Dies wird als trunkbasierte Entwicklung bezeichnet und wird von Unternehmen wie Google, Facebook und Netflix intern verwendet, selbst mit Tausenden von Entwicklern.

"Für kleine Teams ist Einfachheit nicht nur einfacher – sie ist tatsächlich effektiver. Komplexe Workflows, die für Unternehmens-Teams entworfen wurden, werden zu Produktivitätsanker, wenn Sie mit fünf Personen ausliefern."

Das Kernprinzip ist folgendes: Ihr Hauptbranch ist immer deploybar, und Sie integrieren Ihre Arbeit mindestens einmal pro Tag, vorzugsweise öfter. Feature-Branches existieren für Stunden oder Tage, nicht Wochen. Sie verzweigen von main, arbeiten daran und fügen zurück zu main zusammen, sobald das Feature abgeschlossen und getestet ist.

Lassen Sie mich Sie durch einen typischen Tag mit diesem Workflow führen. Sie beginnen Ihren Morgen, indem Sie die neuesten Änderungen von main abrufen. Sie erstellen einen Feature-Branch für die Aufgabe, an der Sie arbeiten – sagen wir, es geht darum, E-Mail-Benachrichtigungen hinzuzufügen. Sie benennen ihn etwas beschreibend, wie 'add-email-notifications' oder 'feature/email-notifications'. Sie arbeiten einige Stunden daran und committen häufig mit klaren Nachrichten. Bis zum Mittag haben Sie es lokal funktionierend und getestet. Sie pushen Ihren Branch, öffnen eine Pull-Request und pingen einen Kollegen zur Überprüfung.

Ihr Kollege überprüft dies während des Mittagessens (da die Änderung klein und fokussiert ist, dauert die Überprüfung fünfzehn Minuten, nicht zwei Stunden). Sie gehen auf sein Feedback ein, er genehmigt und Sie mergen zu main. Die CI/CD-Pipeline führt Ihre Tests durch, und wenn alles bestanden wird, wird die Änderung automatisch in Staging bereitgestellt. Sie überprüfen, ob es in Staging funktioniert, und bis zum Ende des Tages ist es in der Produktion. Gesamtdauer von der Erstellung des Branches bis zur Produktion: sechs Stunden.

Vergleichen Sie dies mit einem Git Flow-Ansatz: Sie würden von develop abzweigen, mehrere Tage lang arbeiten und Änderungen ansammeln, schließlich einen PR zu develop eröffnen, auf die Überprüfung warten, zu develop mergen, dann warten, bis jemand einen Release-Branch erstellt, dann diesen zu master mergen, dann einen Release taggen und dann bereitstellen. Dasselbe Feature könnte drei Tage benötigen, um die Produktion zu erreichen, nicht weil die Arbeit länger dauerte, sondern weil der Prozess dies tat.

Einrichten Ihrer Repository-Struktur

Die Schönheit eines einfachen Workflows ist, dass die Einrichtung minimal ist, aber es gibt einige wichtige Konfigurationen, die alles reibungsloser machen. Zuerst sichern Sie Ihren Hauptbranch. In GitHub, GitLab oder Bitbucket können Sie Branch-Schutzregeln festlegen, die direkte Pushes zu main verhindern und Pull-Request-Überprüfungen vor dem Mergen erfordern. Das ist keine Bürokratie – es ist ein Sicherheitsnetz, das Bugs auffängt und Wissen im Team verbreitet.

Hier sind meine empfohlenen Schutzeinstellungen für kleine Teams: Erfordern Sie mindestens eine Genehmigung vor dem Mergen, verlangen Sie, dass Statusprüfungen bestanden werden (ihre CI-Tests) und aktivieren Sie "Branch nach Merge löschen", um Ihr Repository sauber zu halten. Ich empfehle nicht, mehrere Genehmigungen für kleine Teams zu verlangen – das schafft Engpässe, ohne viel Wert hinzuzufügen, wenn alle im selben Raum sind (physisch oder virtuell).

Zweitens, richten Sie eine solide CI/CD-Pipeline von Anfang an ein. Das muss nicht komplex sein. Eine einfache Pipeline, die Ihre Tests bei jedem Push durchführt und bei jedem Merge zu main in Staging bereitstellt, ist ausreichend. Ich habe gesehen, wie Teams Wochen damit verbringen, ihren Git-Workflow zu perfektionieren, während sie manuell bereitstellen, was so ist, als würde man einen Sport...