KI-Skill / Planen und entscheiden
Gitflow anwenden
Begleitet Entwicklung, gemeinsame Abnahme und Freigabe mit Gitflow. Die Methode ist unsere Voreinstellung für neue Codeprojekte; bestehende Projekte stellen wir bewusst einzeln um.
Leitlinien
Gitflow beschreibt getrennte Wege für Entwicklung, Release-Vorbereitung und dringende Produktionskorrekturen. Der Autor ordnet seit 2020 auch die Grenzen bei Continuous Delivery ein.
Vincent Driessen / A successful Git branching model ↗
Branch-Schutz steuert direkte Pushes und Merges. Unsere Hauptbranches erhalten Änderungen über Merge Requests.
GitLab / Protected branches ↗
Normale Merge Commits bewahren die gemeinsame Historie der Branches. Unsere Gitflow-Konvention verwendet keinen Squash.
GitLab / Merge methods ↗
Warum das wichtig ist
Eine bekannte Methode gibt jeder Änderung einen klaren Weg. Wir üben die Schritte an echten Aufgaben und erklären jeweils Ausgangsbranch, Ziel und Zweck. Gitflow ist unsere bewusste Wahl für Entwicklung mit gemeinsamer Abnahme vor einer Veröffentlichung. Es ist ein etabliertes Modell und keine formale Norm oder allgemeingültige Best Practice. Für kontinuierlich ausgelieferte Anwendungen können einfachere Abläufe passen; eine ausdrückliche andere Projektwahl bleibt möglich.
So setzt der Skill diese Leitlinien um
Wir entwickeln auf kurzen Feature- oder Korrekturbranches und führen geprüfte Änderungen in develop zusammen. Für die Abnahme zweigen wir einen Release-Branch ab. Der freigegebene Stand kommt nach main und erhält einen Versions-Tag; die Release-Korrekturen fliessen auch nach develop zurück. Dringende Produktionskorrekturen beginnen auf dem betroffenen freigegebenen Stand und erreichen sowohl main als auch die weitere Entwicklung. In GitLab verwenden wir geschützte Branches und Merge Requests mit normalen Merge Commits. Kleingeschriebene Namen, main statt master und unsere Freigaberegeln ergänzen das Originalmodell als DigiEstate-Konventionen. Ein Merge ist noch kein Nachweis einer erfolgten Bereitstellung.
- Beginnt die Änderung auf dem richtigen Branch und führt der Merge Request zum richtigen Ziel?
- Sind Release und Hotfix in alle erforderlichen Branches zurückgeführt?
- Stimmen Versionsangaben, Tag und geprüfter Freigabestand überein?
- Sind Prüfung, Freigabe und tatsächliche Bereitstellung nachvollziehbar unterschieden?
Im Projekt anwenden
Die führende Anleitung liegt in digiestate-skills und wird über die Projektadapter eingebunden. Neue Codeprojekte aus dem Template verwenden sie als Voreinstellung. Aufruf: $gitflow-anwenden
Natürlicher Aufruf: Wir arbeiten in diesem Projekt mit Gitflow. Bestehende Projekte werden erst nach bewusster Auswahl umgestellt; reine Textprojekte erhalten keine zusätzliche Branch-Struktur.
Dokumentation und Übergabe
Die Projektregeln halten die Gitflow-Wahl fest. Merge Requests dokumentieren Änderung und Prüfung, Versions-Tags markieren freigegebene Stände. Der Skill erklärt die nächsten Schritte und weist noch erforderliche Freigaben aus.