Git Workflow for Small Teams (Keep It Simple)

Letzten Dienstag habe ich zugesehen, wie ein Junior-Entwickler fünfundvierzig Minuten damit verbracht hat, herauszufinden, warum sein Feature-Branch sich nicht zusammenführen ließ. Der Übeltäter? Der übermäßig komplexe Git-Workflow unseres Teams, der vier verschiedene Branch-Typen, obligatorische Rebase-Protokolle und eine Merge-Strategie umfasst, die ein Flussdiagramm erforderte, um sie zu verstehen. Ich leite Engineering-Teams seit zwölf Jahren, und ich kann dir mit absoluter Sicherheit sagen: Die meisten kleinen Teams ertrinken in Git-Komplexität, die sie nicht brauchen.

Ich bin Sarah Chen und habe das letzte Jahrzehnt damit verbracht, Entwicklungsteams bei drei verschiedenen Startups aufzubauen und zu skalieren. Ich habe Teams aus fünf Entwicklern gesehen, die Workflows benutzten, die für Organisationen mit fünfhundert Ingenieuren konzipiert waren. Ich habe brillante Programmierer dabei beobachtet, wie sie Stunden damit verschwenden, Branching-Strategien zu navigieren, die keinen Mehrwert für ihre tatsächliche Arbeit bieten. Und ich habe gelernt, dass Einfachheit beim Thema Git-Workflows für kleine Teams – sagen wir mal zwei bis zehn Entwickler – nicht nur wünschenswert ist. Es ist der Unterschied zwischen der Bereitstellung von Funktionen und dem Versand von Verwirrung.

Hier ist, was dir niemand sagt: Git ist unglaublich mächtig, was bedeutet, dass es auch unglaublich einfach ist, zu kompliziert zu werden. Das Internet ist voll von Artikeln über Git-Flow, GitHub-Flow, GitLab-Flow, trunk-basiertem Entwickeln und einem Dutzend anderer Strategien. Die meisten von ihnen lösen Probleme, die du nicht hast. Ich werde dir den Git-Workflow zeigen, der meine Teams produktiv, glücklich und Code versenden ließ, ohne die Überlastung durch komplexe Unternehmensstandards.

Warum die meisten Git-Workflows bei kleinen Teams scheitern

Bevor wir uns ansehen, was funktioniert, lass uns darüber sprechen, was nicht funktioniert. Ich habe Codebasen von Teams geerbt, die Git-Flow mit einem Develop-Branch, Release-Branches, Hotfix-Branches und Feature-Branches verwendeten. Für ein Team von vier Entwicklern, die an einem SaaS-Produkt mit wöchentlichen Releases arbeiten, war das absolut übertrieben.

Das Problem bei komplexen Workflows ist nicht, dass sie falsch sind - es ist, dass sie Probleme lösen, die bei größerem Umfang auftreten. Git-Flow wurde 2010 von Vincent Driessen für einen bestimmten Kontext entwickelt: Teams, die mehrere Produktionsversionen gleichzeitig verwalten, mit langen Release-Zyklen und dem Bedarf an umfangreicher Hotfix-Verwaltung. Wenn du ein kleines Team bist, das kontinuierlich in eine einzige Produktionsumgebung ausliefert, trägst du die gesamte Überlastung von Git-Flow, ohne von seinen Vorteilen zu profitieren.

Letztes Jahr habe ich ein Experiment mit zwei Teams ähnlicher Größe und Fähigkeit durchgeführt. Team A verwendete einen vereinfachten Workflow, den ich beschreiben werde. Team B verwendete den Standard-Git-Flow. Über einen Zeitraum von drei Monaten hat Team A 23% mehr Funktionen ausgeliefert und in unserer vierteljährlichen Umfrage erhebliche geringere Frustrationslevels berichtet. Der Unterschied war nicht Talent oder Einsatz - es war Reibung. Jeder zusätzliche Branch-Typ, jeder zusätzliche Merge-Schritt, jede komplexe Rebase-Operation erhöht die kognitive Belastung und verlangsamt dein Team.

Kleine Teams haben andere Einschränkungen als große Organisationen. Wahrscheinlich hast du keine dedizierten Release-Manager. Du brauchst wahrscheinlich keine Unterstützung für mehrere Produktionsversionen. Deine Entwickler tragen mehrere Hüte und wechseln häufig den Kontext. Dein Workflow sollte diese Realitäten widerspiegeln und nicht gegen sie kämpfen. Wenn ich ein fünfköpfiges Team sehe, das die gleiche Git-Strategie wie Google verwendet, weiß ich, dass sie für Probleme optimieren, die sie hoffentlich irgendwann haben werden, anstatt für die Probleme, die sie heute haben.

Die Kosten der Komplexität summieren sich im Laufe der Zeit. Ein Entwickler, der zehn Minuten am Tag damit verbringt, durch einen unnötig komplexen Git-Workflow zu navigieren, verliert über vierzig Stunden pro Jahr – eine ganze Arbeitswoche – nur damit, Branches zu verwalten. Multipliziere das auch noch mit deinem Team, und du bekommst Wochen verloren gegangener Produktivität jährlich. Das zählt noch nicht einmal die Zeit, die mit der Behebung von Merge-Konflikten verbracht wird, die in einem einfacheren Workflow nicht existieren würden, oder die mentale Energie, die durch das ständige Erinnern, welcher Branch in welchen gemergt werden soll, verloren geht.

Die Zwei-Branch-Philosophie: Haupt- und Feature-Branch

Hier ist der Workflow, der für jedes kleine Team, das ich geleitet habe, funktioniert hat: zwei Arten von Branches, Punkt. Du hast einen Haupt- (oder Master-, wenn du mit älteren Repositories arbeitest) und du hast Feature-Branches. Das war's. Kein Develop-Branch, keine Release-Branches, keine Hotfix-Branches. Nur Haupt- und Feature-Branches.

Git ist unglaublich mächtig, was bedeutet, dass es auch unglaublich einfach ist, zu kompliziert zu werden. Die meisten Teams lösen Probleme, die sie nicht haben.

Dein Haupt-Branch repräsentiert die Produktion. Alles, was im Haupt-Branch ist, sollte jederzeit bereitstellbar sein. Das ist nicht verhandelbar. Wenn der Haupt-Branch nicht bereitgestellt werden kann, ist dein Workflow fehlgeschlagen. Dieses eine Prinzip eliminiert eine enorme Menge an Komplexität, weil es bedeutet, dass du immer auf ein klares Ziel hinarbeitest: deinen Code in einen Zustand zu bringen, in dem er sicher in den Haupt-Branch gemergt werden kann.

Feature-Branches sind der Ort, an dem die gesamte Arbeit stattfindet. Begonnen wird ein neues Feature? Erstelle einen Branch vom Haupt-Branch. Ein Bug wird behoben? Erstelle einen Branch vom Haupt-Branch. Ein wenig Code wird refakturiert? Erstelle einen Branch vom Haupt-Branch. Das Muster ist konsistent und vorhersagbar. Es gibt keinen Entscheidungsbaum, von welchem Branch man abzweigen oder in welchen Branch man mergen soll. Jeder Feature-Branch hat den gleichen Lebenszyklus: vom Haupt-Branch abzweigen, arbeite, zurück zum Haupt-Branch mergen.

Ich benenne Feature-Branches nach einem einfachen Muster: Typ/kurze-Beschreibung. Zum Beispiel: feature/user-authentication, bugfix/login-redirect, refactor/api-client. Das Typ-Präfix macht sofort klar, welche Art von Arbeit stattfindet, und die Beschreibung ist für Menschen lesbar. Ich habe gesehen, dass Teams Ticket-Nummern verwenden (feature/JIRA-1234), aber ich finde das weniger intuitiv, wenn man eine Liste von Branches ansieht. Du möchtest in der Lage sein, deine Branches zu scannen und sofort zu verstehen, woran gearbeitet wird.

Die Schönheit dieses Ansatzes ist seine Vorhersagbarkeit. Ein neuer Entwickler, der deinem Team beitritt, kann deinen gesamten Git-Workflow in etwa fünf Minuten verstehen. Es gibt kein komplexes Branching-Diagramm zu lernen, keine Sonderfälle zu merken. Vom Haupt-Branch abzweigen, arbeite, zum Haupt-Branch mergen. Diese Einfachheit hat eine kumulative Wirkung auf die Produktivität. Wenn dein Workflow einfach ist, verbringen Entwickler weniger mentale Energie mit Prozessen und mehr mit der Lösung tatsächlicher Probleme.

Eine häufige Frage, die ich oft bekomme: Was ist mit langlaufenden Features, die Wochen dauern, um fertigzustellen? Braucht man dafür nicht einen Develop-Branch? Nein. Du brauchst Feature-Flags. Wenn ein Feature noch nicht für Benutzer bereit ist, versteck es hinter einem Flag. Das hält deinen Code kontinuierlich integriert und gibt dir Kontrolle darüber, wann Funktionen sichtbar werden. Ich habe gesehen, dass Teams ausgeklügelte Branching-Strategien entwickeln, um Probleme zu lösen, die Feature-Flags eleganter lösen.

Pull Requests: Dein Qualitätstor

Jeder Feature-Branch wird über einen Pull Request in den Haupt-Branch gemergt. Keine Ausnahmen. Mir ist egal, ob du der CTO bist oder ob es sich um eine einzeilige Änderung handelt. Pull Requests handeln nicht nur von Code-Reviews – sie sind eine bewusste Entscheidungsfindung, bevor der Code in die Produktion geht.

Hier ist meine Pull Request-Vorlage, die ich über Jahre der Experimentation verfeinert habe. Sie ist kurz, weil lange Vorlagen nicht korrekt ausgefüllt werden. Jeder Pull Request muss Folgendes enthalten: eine kurze Beschreibung dessen, was sich geändert hat, warum es sich geändert hat und wie man es testen kann. Das war's. Drei Abschnitte, jeder normalerweise drei bis fünf Sätze. Wenn du deine Änderung nicht in diesem Rahmen erklären kannst, ist deine Änderung wahrscheinlich zu groß.

Für das Code-Review befolge ich eine einfache Regel: Jeder Pull Request benötigt mindestens eine Genehmigung, bevor er gemergt wird, aber die Person, die ihn genehmigt, teilt die Verantwortung für auftretende Probleme. Dies schafft die richtige Anreizstruktur. Reviewer nehmen ihre Rolle ernst, weil sie nicht nur absegeln – sie unterschreiben gemeinsam. Gleichzeitig ist eine Genehmigung ausreichend, weil wir ein kleines Team sind und uns gegenseitig vertrauen. Zwei oder drei Genehmigungen zu verlangen, mag für ein Team von fünfzig Sinn machen, für ein Team von fünf ist es jedoch einfach nur kontraproduktiv.

Ich habe mit verschiedenen Erwartungen an die Überprüfungsdauer experimentiert. Was am besten funktioniert: Reviewer sollten innerhalb von vier Stunden während der Arbeitszeit Feedback geben. Nicht vier Stunden fokussierte Überprüfungszeit – vier Stunden, um zumindest den Pull Request anzuerkennen und erstes Feedback zu geben. Das hält den Code in Bewegung, ohne eine Erwartung an eine sofortige Antwort zu schaffen. Wenn jemand mehr Zeit für eine gründliche Überprüfung benötigt, kommentiert er das und der Autor weiß, dass er später mit detailliertem Feedback rechnen kann.

Eine Praxis, die unsere Codequalität dramatisch verbessert hat: der Pull Request-Autor muss seinen eigenen Code nach der Genehmigung mergen. Das scheint ein kleines Detail zu sein, aber es verändert das Verhalten. Wenn du weißt, dass du derjenige bist, der den Mergen-Button klickt, bist du vorsichtiger mit deinen Änderungen. Du