Die Nordlicht Reisen GmbH will wissen, warum die Buchungsseite am Montag langsamer war. Die Antwort steht irgendwo zwischen einem Wunsch aus dem Vertrieb, einem Pull Request vom Freitag und einem Build, der nachts lief. Niemand findet den Weg. Ihr Auftrag in dieser Lektion: einen Arbeitsfluss zu entwerfen, in dem jede Änderung einen Anfang, eine Rückmeldung und eine Spur hat, und die Werkzeuge beider Welten dafür einzusetzen.
Das sind die Fähigkeiten der Prüfung zu Beginn des Bereichs „Prozesse und Kommunikation“: die Struktur des Arbeitsflusses (einschließlich GitHub Flow), Rückmeldeschleifen und Benachrichtigungen (einschließlich GitHub Issues), die Verfolgung der Arbeit (GitHub Projects, Azure Boards) und die Rückverfolgbarkeit von Quelle, Fehlern und Qualität.
Vorwissen: Git und Pull Requests setzt der Kurs voraus (K3, Modul 3.7 zeigt sie im Alltag einer Pipeline). Die Landkarte der beiden Werkzeugwelten steht in Lektion 0.2; Konten und Aufräumen in Lektion 0.1. Verzweigungsmodelle im Detail (trunk-based, Feature-Branch, Release-Branch) kommen in Lektion 2.1; hier geht es um den Fluss der Arbeit, nicht um die Form der Branches.
Hinweis: Alle Angaben stammen aus der Dokumentation von GitHub und Microsoft Learn; die Seiten stehen unter „Weiterlesen“. Die Befehle und Menüpfade dieser Lektion wurden nicht ausgeführt; sie stammen aus der Referenz von GitHub und Microsoft.
Die Struktur des Arbeitsflusses: GitHub Flow
GitHub Flow ist ein leichter, Branch-basierter Arbeitsablauf. GitHub beschreibt ihn in sechs Schritten:
| Schritt | Was geschieht | Was GitHub dazu sagt |
|---|---|---|
| 1. Branch anlegen | ein eigener Branch für die Änderung | ein kurzer, beschreibender Name, damit Mitarbeitende die laufende Arbeit auf einen Blick sehen (Beispiele der Seite: increase-test-timeout, add-code-of-conduct) |
| 2. Änderungen machen | Commits und Push auf den Branch | beschreibende Commit-Nachrichten; jeder Commit idealerweise eine abgeschlossene, einzelne Änderung, damit sie sich leicht rückgängig machen lässt |
| 3. Pull Request erstellen | um Rückmeldung zu bitten | wer vor dem Abschluss Rückmeldung will, markiert ihn als Entwurf (draft); verknüpfte Issues mit einem Schlüsselwort schließen sich beim Zusammenführen; konfigurierte Prüfungen erscheinen im Pull Request |
| 4. Rückmeldungen einarbeiten | auf Fragen und Vorschläge antworten | weitere Commits; der Pull Request aktualisiert sich selbst |
| 5. Pull Request zusammenführen | nach der Zustimmung | Konflikte müssen vorher gelöst sein; Schutzregeln für Branches können das Zusammenführen blockieren |
| 6. Branch löschen | nach dem Zusammenführen | zeigt, dass die Arbeit fertig ist, und verhindert die versehentliche Wiederverwendung; Pull Request und Verlauf bleiben, der Branch lässt sich wiederherstellen |
Merken Sie sich die Absicht dahinter: Jede Änderung hat einen Ort (den Branch), einen Raum für Rückmeldung (den Pull Request) und eine Bedingung zum Abschluss (Prüfungen und Zustimmung). Die Schutzregeln selbst, die Prüfungen erzwingen, lehrt Lektion 2.2.
Dieselbe Idee bei Azure DevOps
Azure Repos kennt denselben Ablauf mit anderen Namen: Branch, Pull Request mit Reviewern und Richtlinien, Zusammenführen. Der Unterschied liegt in der Verbindung zur Planung: Aus einem Arbeitselement in Azure Boards lässt sich ein Branch erzeugen, und Azure Boards zeigt Pull Requests im Abschnitt Development des Arbeitselements. Microsoft beschreibt als durchgehende Nachverfolgbarkeit: einen Branch aus einer Anforderung erstellen, Pull Requests prüfen, die an Arbeitselemente gebunden sind, Builds und Releases mit Arbeitselementen verknüpfen und Änderungen von der Anforderung bis zur Produktion verfolgen.