--- name: gitflow-anwenden description: Wendet Gitflow mit main, develop, Feature-, Release- und Hotfix-Branches sowie GitLab-Merge-Requests an. Verwenden beim Start neuer DigiEstate-Codeprojekte und für Entwicklungs-, Freigabe- oder Hotfix-Arbeit in Projekten, die Gitflow gewählt haben; bestehende Projekte nicht ungefragt umstellen. --- # Gitflow anwenden Führe die Arbeit nach einem wiederholbaren Gitflow-Ablauf. Erkläre vor jedem Branchwechsel und Merge kurz Ausgangspunkt, Ziel und Zweck, damit der Benutzer die Methode durch die praktische Anwendung einüben kann. ## Grundlage und Geltung Die fachliche Grundlage ist Vincent Driessens [A successful Git branching model](https://nvie.com/posts/a-successful-git-branching-model/). Gitflow ist ein etabliertes Branching-Modell, keine formale Norm. Die Einordnung des Autors von 2020 zu einfacheren Abläufen bei Continuous Delivery bleibt Teil der Referenz; sie hebt eine bewusste Gitflow-Wahl nicht auf. DigiEstate verwendet Gitflow als Voreinstellung für neue Codeprojekte. Bestehende Projekte werden nur nach bewusster Auswahl umgestellt. Reine Textprojekte erhalten dadurch keine zusätzliche Branch-Struktur. Eine ausdrückliche projektspezifische Wahl hat Vorrang. `main` statt des ursprünglichen `master`, die Präfixe mit Schrägstrich, Kleinschreibung, GitLab-Merge-Requests und die unten stehenden Freigaberegeln sind DigiEstate-Konventionen auf Grundlage des Modells. ## Branch-Vertrag | Branch | Ausgangspunkt | Merge-Ziel | Aufgabe | | --- | --- | --- | --- | | `main` | Initialstand | — | Freigegebene Versionen | | `develop` | Anfangs `main` | — | Integration der nächsten Version | | `feature/` | `develop` | `develop` | Neue Funktion | | `fix/` | `develop` | `develop` | Normale Fehlerkorrektur | | `release/` | `develop` | `main` und `develop` | Abnahme und Stabilisierung | | `hotfix/` | Freigegebener Stand auf `main` | `main` und `develop` | Dringende Korrektur | ## Vorbereiten 1. Lies die Projektregeln, den aktuellen Auftrag und die Git-Zustände. Prüfe Remote-URL, lokale Änderungen, Branches, aktive Releases und vorhandene Tags. Aktualisiere Remote-Referenzen, bevor du daraus neue Branches ableitest. 2. Ordne die Arbeit einem Branch-Typ zu. Zeige bei Versionsfreigaben den vorgesehenen Inhalt und die Version; leite sie nicht allein aus dem Datum ab. 3. Bei einem neuen Projekt: Bereite `develop` vom bestätigten Initialstand auf `main` vor und dokumentiere Gitflow in den Projektregeln. Erzeuge eine schmale Referenz auf diesen Skill statt einer zweiten vollständigen Anleitung. Fehlt noch ein Initialcommit, halte diesen und die Branch-Einrichtung als offenen Schritt fest. Erzeuge keinen Commit als Nebeneffekt der Initialisierung. 4. Stelle vorhandene Historie, Default-Branch oder CI-Auslöser nicht beiläufig um. Benenne bei einer Migration die nötigen Anpassungen vor ihrer Ausführung. ## Entwickeln Erstelle einen kurzen `feature/`- oder `fix/`-Branch vom aktuellen `develop`. Implementiere und prüfe den zusammengehörigen Auftrag. Committe und pushe nach den geltenden Projektfreigaben. Öffne einen Merge Request ausdrücklich nach `develop`; beschreibe Wirkung und Prüfnachweise. Nach dem geprüften Merge kann der Arbeitsbranch entfernt werden, soweit dessen Löschung freigegeben ist. ## Release freigeben 1. Erstelle `release/` von dem für die Abnahme ausgewählten `develop`-Stand. Integriere dort nur Freigabearbeiten und Korrekturen. Aktualisiere vorhandene Versionsmetadaten nach den Projektregeln auf die Zielversion und prüfe ihre Übereinstimmung mit dem geplanten Tag. Erfinde dafür keine zusätzliche Versionsdatei. 2. Prüfe den Release-Inhalt und hole die Freigabe für den konkret vorgelegten Stand ein. Ein Feature-Merge nach `develop` ist noch keine Release-Freigabe. 3. Übernimm den Release-Branch über einen Merge Request nach `main`. Markiere den resultierenden freigegebenen Commit mit einem annotierten Tag `v`. Prüfe vor dem Anlegen, dass dieser Tag noch nicht existiert. 4. Führe denselben Release-Branch auch über einen Merge Request nach `develop` zurück. Erhalte ihn bis beide Merges geprüft sind; aktiviere seine automatische Löschung beim ersten Merge nicht. ## Hotfix freigeben Beginne auf dem tatsächlich betroffenen freigegebenen Stand. Führe den Hotfix mit nach Projektregeln aktualisierten Versionsmetadaten aus; prüfe deren Übereinstimmung mit der vorgesehenen Hotfix-Version. Führe die Korrektur über einen Merge Request nach `main`, prüfe den Stand und tagge die neue Version. Führe die Korrektur auch nach `develop` zurück. Existiert ein aktiver Release-Branch, integriere sie dort; dessen späterer Rückmerge übernimmt die Korrektur nach `develop`. Wird sie dort schon vorher benötigt, integriere sie zusätzlich direkt. Behalte den Hotfix-Branch bis alle nötigen Merges geprüft sind. Stelle nicht den gesamten aktuellen `develop`-Stand als Hotfix bereit. ## GitLab CE und gemeinsame Historie - Schütze `main` und `develop`: direkter Push ausdrücklich `No one`, Merge durch `Maintainers`, Force Push aus. Prüfe alle passenden Schutzregeln. - Verwende normale Merge Commits, entsprechend `git merge --no-ff`, und deaktiviere Squash. So bleiben die Branch-Abstammung und die ursprünglichen Task-Commits nachvollziehbar. Verändere veröffentlichte Historie nicht. - Benenne das Merge-Ziel ausdrücklich. Die Einrichtung von Gitflow verlangt keinen stillschweigenden Wechsel des GitLab-Default-Branches. - Lösche `main` und `develop` nicht. Entferne Release- und Hotfix-Branches erst nach Prüfung aller Zielbranches; eine vorhandene Löschfreigabe gilt weiter. - Verlange eine erfolgreiche Pipeline, sobald die nötigen Jobs und Runner funktionieren. Erfinde keine CI-Nachweise und richte kein Deployment als Nebeneffekt der Branch-Einrichtung ein. - Bereite Branch-Push und Merge Request innerhalb des bestätigten Auftrags vor. Merge, Release-Tag und Veröffentlichung brauchen die nach Projektregeln erforderliche Freigabe. Ein Commit oder Branch-Push gibt keinen Merge frei. - Nutze die verfügbaren CE-Funktionen. Behaupte keine technisch erzwungene Review-Freigabe, wenn diese in der verwendeten Edition nicht vorhanden ist. Normales Git genügt; installiere keine `git-flow`-Erweiterung voraussetzungslos. Die GitLab-Details folgen der offiziellen Dokumentation zu [geschützten Branches](https://docs.gitlab.com/user/project/repository/branches/protected/), [Merge-Methoden](https://docs.gitlab.com/user/project/merge_requests/methods/) und [Merge-Request-Freigaben](https://docs.gitlab.com/user/project/merge_requests/approvals/). ## Ergebnis und Stoppregel Berichte Branch-Typ, Ausgangspunkt, Merge-Ziele, Prüfung und ausstehende Freigaben. Ein Release oder Hotfix ist erst vollständig integriert, wenn die Korrekturen alle erforderlichen Ziele erreicht haben. Trenne diesen Zustand von einer tatsächlich erfolgten Bereitstellung. Stoppe vor einer Aktion, wenn Zielrepository, betroffener Versionsstand oder Freigabe unklar sind oder fremde Änderungen überschrieben würden. Zeige dann den konkreten offenen Punkt. Überschreibe keine vorhandenen Tags und umgehe keinen Branch-Schutz.