GitHub Flow

Details

Kernkonzepte:

  • Ein schlanker, branch-basierter Workflow, bei dem main immer auslieferbar ist

  • Feature-Branches sind kurzlebig und werden für jede Änderung aus main erstellt

  • Pull Requests sind der zentrale Kollaborationsmechanismus — für Code-Review, Diskussion und CI-Validierung vor dem Mergen

  • Das Mergen in main löst sofortige Auslieferung aus (Continuous Delivery)

  • Branch-Namen spiegeln die Arbeit wider: Issue-Nummer oder kurzer beschreibender Slug

    Workflow-Schritte

    1. Branch von main erstellen (benannt nach Issue oder Feature)

    2. Änderungen mit aussagekräftigen Nachrichten committen

    3. Pull Request frühzeitig öffnen für Transparenz und Feedback

    4. Diskutieren, reviewen und iterieren bis der PR genehmigt ist

    5. In main mergen — main ist immer auslieferbar

    6. Sofort nach dem Merge deployen

    Schlüsselvertreter

    Scott Chacon ("GitHub Flow", 2011)

Wann zu verwenden:

  • Teams, die Continuous Delivery oder Continuous Deployment praktizieren

  • Projekte, bei denen main stets produktionsbereit sein muss

  • Issue-getriebene oder Ticket-getriebene Entwicklungsworkflows

  • Agentische Coding-Workflows, bei denen Kontextkürze wichtig ist

Verwandte Anker:

Aktueller Stand:

  • Der Prior reproduziert höchstwahrscheinlich Scott Chacons Original-Formulierung von 2011, in der Continuous Deployment der Kern ist — "anything in the master branch is deployable", gemergte Arbeit wird sofort deployt, oft mehrmals täglich

  • GitHubs aktuelle offizielle Beschreibung ist zu einem generischen Branch → PR → Review → Merge-Workflow ohne jeden Deployment-Schritt geschrumpft — sage, welche der beiden Varianten du meinst