Git ist ein Teamsport: Warum wir Strategien brauchen
Wenn du an deinen ersten eigenen Projekten arbeitest, ist Git meistens ziemlich simpel: Du schreibst Code, machst einen git add, dann einen git commit und schließlich einen git push. Fertig. Du bist der einzige Autor, und der main-Branch gehört dir allein.
Aber sobald du in einem Team arbeitest, ändert sich das Spiel drastisch. Stell dir vor, fünf Leute schreiben gleichzeitig am selben Roman. Wenn jeder einfach wild Sätze in das Manuskript schreibt, endet das im Chaos. Sätze werden überschrieben, die Handlung macht keinen Sinn mehr und am Ende funktioniert gar nichts.
In der Softwareentwicklung ist das genauso. Wir brauchen “Verkehrsregeln”, die bestimmen, wie und wann Code von verschiedenen Entwicklern zusammengeführt wird. Diese Regeln nennen wir Branching-Strategien.
Zwei der bekanntesten Philosophien schauen wir uns heute an: Das klassische Feature-based Development und das schnelle Trunk-based Development.
Der Klassiker: Feature-based Development
Wenn du neu in einem Unternehmen anfängst oder Open Source auf GitHub machst, wirst du höchstwahrscheinlich zuerst diesem Modell begegnen. Es ist der Standard für viele Teams, weil es sich sicher und geordnet anfühlt.
Wie es funktioniert
Die Grundidee ist Isolation. Für jede neue Aufgabe – sei es ein neuer Button auf der Login-Seite oder ein Bugfix in der Datenbank – erstellst du einen eigenen Branch (einen “Zweig”), der vom Hauptcode (main) abgeht.
Der typische Workflow sieht so aus:
- Branch erstellen:
git checkout -b feature/neuer-login-button - Coden: Du arbeitest tagelang in deiner eigenen Blase an diesem Feature. Nichts, was du hier tust, stört deine Kollegen.
- Pull Request (PR): Wenn du fertig bist, sagst du dem Team: “Hey, ich bin fertig, bitte schaut euch meinen Code an.”
- Review: Deine Kollegen prüfen den Code, geben Feedback und du besserst nach.
- Merge: Erst wenn alle Daumen oben sind, wird dein Branch in den
main-Branch integriert.
Der Vibe: “Safety First”
Feature-based Development fühlt sich oft entspannt an. Du hast keinen Druck, unfertigen Code zu teilen. Der main-Branch gilt als heiliger Gral – er ist (theoretisch) immer stabil, weil nur geprüfter Code hineindarf.
Die Schattenseite: Die “Merge Hell”
Das Problem entsteht oft erst am Ende. Stell dir vor, du arbeitest zwei Wochen an deinem Feature. In dieser Zeit haben deine Kollegen aber schon 50 andere Änderungen in den main-Branch gemerged.
Wenn du jetzt versuchst, deinen Code zurückzuführen, kracht es: Merge Conflicts. Deine Änderungen passen nicht mehr zum Rest der Anwendung. Was als entspannte Entwicklung begann, endet oft in stundenlanger Arbeit, um Konflikte zu lösen – der gefürchtete “Merge-Freitag”.
Alles klar, dann schalten wir jetzt einen Gang höher. Hier kommt der zweite Teil des Artikels.
Wir schauen uns jetzt das Modell an, das Firmen wie Google oder Meta nutzen, und ziehen am Ende das Fazit.
Die Überholspur: Trunk-based Development
Wenn Feature-based Development wie das Schreiben von Kapiteln in getrennten Word-Dokumenten ist, dann ist Trunk-based Development wie das gemeinsame Arbeiten in einem Google Doc in Echtzeit.
Wie es funktioniert
Hier ist die radikale Idee: Es gibt (fast) keine langlebigen Branches mehr.
Alle Entwickler committen ihren Code direkt in den main-Branch (oft auch “Trunk” genannt) – und zwar mehrmals am Tag. Wenn Branches genutzt werden, leben diese nur ein paar Stunden, maximal einen Tag.
Der Workflow:
- Pull: Du holst dir den allerneuesten Stand vom
main. - Code & Test: Du schreibst eine kleine Änderung und testest sie lokal.
- Push: Du schiebst den Code sofort wieder auf den
main.
“Aber mache ich damit nicht alles kaputt?”
Das ist die erste Frage, die sich jeder, der zum ersten Mal davon hört, stellt. Wenn jeder ständig unfertigen Code auf main schiebt, ist die Software doch dauernd kaputt, oder?
Hier kommen zwei unverzichtbare Bodyguards ins Spiel, ohne die Trunk-based Development Selbstmord wäre:
- Automatisierte Tests: Bevor Code akzeptiert wird, läuft eine Pipeline (CI), die prüft, ob alles noch funktioniert. Wenn die Tests rot sind, wird der Push abgelehnt.
- Feature Toggles (Flags): Das ist der wichtigste Trick. Du baust deinen neuen “Login-Button” zwar direkt in den Code ein, aber du versteckst ihn hinter einem unsichtbaren Schalter (
if (featureEnabled) { ... }). Der Code ist da, aber der User sieht ihn noch nicht. So kannst du unfertige Features integrieren, ohne die Live-Umgebung zu stören.
Der Vibe: “Synchronisation”
Der große Vorteil ist: Du hast keine Angst mehr vor Merge-Konflikten. Da du deinen Code mehrmals am Tag mit dem der anderen abgleichst, sind Konflikte winzig und sofort lösbar. Das Team bewegt sich als eine Einheit vorwärts. Das nennt man Continuous Integration im wahrsten Sinne des Wortes.
Feature vs. Trunk: Der direkte Vergleich
Welcher Weg ist nun der richtige für dich? Hier ist die Entscheidungshilfe:
Feature-based Development ist stark, wenn…
- Du Open Source machst: Du kannst nicht jedem Fremden vertrauen, direkt in deinen
main-Branch zu schreiben. Hier ist der Review-Prozess als Gatekeeper essenziell. - Das Team noch keine starke Test-Kultur hat: Wenn es keine automatischen Tests gibt, ist Trunk-based Development zu riskant. Der manuelle Review im Feature-Branch ist dann dein Sicherheitsnetz.
Trunk-based Development gewinnt, wenn…
- Geschwindigkeit zählt: Moderne High-Performance-Teams wollen Feedback in Stunden, nicht in Tagen.
- Die Tests gut sind: Wer eine solide Testabdeckung hat, braucht keine Angst vor dem
main-Branch zu haben. - Ihr “Merge Hell” hasst: Wenn ihr mehr Zeit mit Konfliktlösung verbringt als mit Coding, ist es Zeit für einen Wechsel.
Fazit: Es ist eine Reise
Am Anfang deiner Karriere gibt dir Feature-based Development die nötige Sicherheit. Es ist okay, in seiner eigenen “Bubble” zu coden und erst rauszukommen, wenn alles perfekt ist.
Aber je erfahrener du wirst, desto mehr wirst du die Vorteile von Trunk-based Development schätzen lernen. Es erfordert Disziplin und Mut, aber es belohnt dich mit einem Workflow, der unglaublich flüssig ist.
Mein Tipp für dich: Frag doch mal in deinem nächsten Team-Meeting: “Wie lange leben unsere Branches eigentlich im Durchschnitt?” Die Antwort verrät dir viel darüber, wie das Team tickt.