Git-Workflow-Strategien für wachsende Teams

Git ist leicht zu lernen und schwer, im Team gut einzusetzen. Sobald mehr als eine Person in dasselbe Repository committet, summieren sich Workflow-Entscheidungen. Eine schlechte Branching-Strategie erzeugt Merge-Konflikte, blockiert Deployments und untergräbt das Vertrauen in den Release-Prozess.

Die drei Workflows, die man kennen sollte

Die meisten Teams landen bei einer von drei Strategien — oder einem Hybrid. Jede hat klare Trade-offs.

Die richtige Wahl hängt von Release-Rhythmus, Teamgröße und CI-Reife ab — nicht von persönlicher Vorliebe.

Trunk-Based Development

Bei Trunk-based Development committet jeder direkt auf main (oder auf einen sehr kurzlebigen Branch, der innerhalb von Stunden gemerged wird). Feature Flags schirmen unfertige Arbeit ab.

# Short-lived branch — lives for hours, not days
git checkout -b feat/add-discount-field
# ... make changes, commit ...
git push origin feat/add-discount-field
# Open PR, get review, merge same day

// Feature flag gates incomplete work in production
export function calculatePrice(item: CartItem): number {
  const base = item.price * item.quantity;
 
  if (featureFlags.isEnabled("volume-discounts")) {
    return applyVolumeDiscount(base, item.quantity);
  }
 
  return base;
}

Die entscheidende Einschränkung: Branches müssen kurzlebig sein. Wenn ein Branch länger als ein, zwei Tage existiert, betreibt man kein Trunk-based Development mehr — sondern langlebige Feature-Branches mit Extraschritten.

GitHub Flow

GitHub Flow ist der gängigste Workflow für Produktteams. Ein langlebiger Branch (main), Feature-Branches für jede Änderung, Pull Requests zur Review.

# Create a feature branch from main
git checkout main
git pull origin main
git checkout -b feat/user-profile-redesign
 
# Work on the feature, commit often
git add -A
git commit -m "refactor: extract ProfileHeader component"
git commit -m "feat: add avatar upload to profile page"
 
# Push and open a PR
git push origin feat/user-profile-redesign

Der typische Fehlerfall sind veraltete Branches. Wenn ein Feature-Branch eine Woche lang existiert und sich main weiterbewegt, häufen sich Merge-Konflikte und Reviews werden mühsam.

// ❌ Giant PR after two weeks of isolated work
// 47 files changed, 2,300 additions, 800 deletions
// Reviewer: "... I'll look at it tomorrow" (never does)
 
// ✅ Stacked PRs — small, reviewable, shippable
// PR 1: Add ProfileHeader component (3 files, 120 lines)
// PR 2: Add avatar upload endpoint (2 files, 80 lines)
// PR 3: Wire upload to ProfileHeader (4 files, 60 lines)

Teile die Arbeit in kleine, unabhängig mergebare PRs auf. Jeder PR sollte sich in unter 15 Minuten reviewen lassen.

GitFlow und wann man es wirklich braucht

GitFlow führt develop-, release/*- und hotfix/*-Branches zusätzlich zu main ein. Es ist für Produkte gedacht, die versionierte Releases ausliefern — Desktop-Software, Mobile-Apps mit App-Store-Review oder Bibliotheken mit Semver.

# Start a release branch from develop
git checkout develop
git checkout -b release/2.4.0
 
# Fix last-minute bugs on the release branch
git commit -m "fix: correct currency formatting in invoice PDF"
 
# Merge to main and tag
git checkout main
git merge release/2.4.0
git tag -a v2.4.0 -m "Release 2.4.0"
 
# Back-merge to develop
git checkout develop
git merge release/2.4.0

Wer kontinuierlich von main deployt, bekommt mit GitFlow nur Ceremony ohne Nutzen. Es löst das spezifische Problem, mehrere Release-Kanäle gleichzeitig zu pflegen.

Disziplin bei Commit-Nachrichten

Unabhängig vom Workflow sind Commit-Nachrichten Dokumentation. Eine gute Commit-Historie ist ein durchsuchbares Änderungsprotokoll.

# ❌ Useless messages
git commit -m "fix stuff"
git commit -m "WIP"
git commit -m "updates"
 
# ✅ Conventional commits — searchable, parseable
git commit -m "fix: prevent duplicate charges on retry"
git commit -m "feat: add webhook signature verification"
git commit -m "refactor: extract payment gateway interface"

Conventional Commits (feat:, fix:, refactor:, chore:, docs:) ermöglichen automatische Changelogs, semantisches Versionieren und ein aussagekräftiges git log.

Main schützen

Jedes Team braucht Schutzmechanismen für den Hauptbranch. Mindestens:

# Example GitHub branch protection rules
branches:
  main:
    protection:
      required_pull_request_reviews:
        required_approving_review_count: 1
      required_status_checks:
        strict: true
        contexts:
          - "ci/tests"
          - "ci/lint"
          - "ci/typecheck"
      enforce_admins: true

Keine direkten Pushes auf main. Kein Merge ohne bestandene CI. Kein "nur dieses eine Mal" umgehen — genau so brechen Produktionssysteme freitags um 17 Uhr zusammen.

Merge-Konflikten proaktiv begegnen

Die meisten Merge-Konflikte haben zwei Quellen: langlebige Branches und gemeinsam genutzte Dateien, die alle bearbeiten (Routes, Configs, Barrel Exports).

// ❌ Single barrel file that every feature touches
// src/components/index.ts — guaranteed conflict zone
export { Button } from "./Button";
export { Modal } from "./Modal";
export { UserCard } from "./UserCard"; // PR A adds this
export { InvoiceTable } from "./InvoiceTable"; // PR B adds this — conflict
 
// ✅ Import directly — no shared barrel file
import { UserCard } from "@/components/UserCard";
import { InvoiceTable } from "@/components/InvoiceTable";

Die zweite Lösung ist häufiges Rebasing. Wenn dein Branch länger als einen Tag lebt, rebase täglich auf main, um Konflikte früh zu erkennen, solange sie noch klein sind.

Die wichtigsten Punkte

1. Wähle einen Workflow passend zu deinem Release-Rhythmus — nicht den, der im Diagramm am besten aussieht
2. Halte Branches kurzlebig, unabhängig davon, welchen Workflow du wählst
3. Kleine PRs werden schneller reviewt und lassen sich sauberer mergen als monolithische
4. Conventional Commits machen deine Historie durchsuchbar und Changelogs automatisch
5. Schütze main mit CI-Gates — keine Ausnahmen, keine Umgehungen
6. Rebase häufig, um Merge-Konflikte früh zu erkennen, solange sie noch klein sind