7. Agiles Arbeiten IV – Git-Workflow light

Nach diesem Kapitel kannst du:

• das Branching-Modell mit dev und main erklären und begründen, warum es ohne Squash-Merge und ohne direkte Commits auskommt.
• den Git-Workflow light im eigenen GitLab-Projekt einrichten: Default-Branch, Protected Branches und Merge-Request-Einstellungen.
• Issues, Merge Requests mit Review, Zeiterfassung und Releases so anlegen, dass der Prozessnachweis nebenbei entsteht.
• Verstöße gegen den Git-Workflow light im Review beurteilen und begründen, welche Regel die Technik absichert und welche das Team.

Im vorigen Kapitel hast du das Projekt in GitLab mit Labels, Milestones und zwei Issue Boards aufgesetzt. Jetzt folgt der Weg jeder einzelnen Story durch Git, vom Feature-Branch bis zum Release, in der Matura-Analogie der Schritt vom Lernplan zur täglichen Routine, die jedes Kapitel gleich durchläuft.

flowchart LR
  I["Issue"] --> F["Feature-Branch"]
  F --> MR["Merge Request"]
  MR --> R["Review"]
  R --> D["dev"]
  D --> RL["Release"]
  RL --> M["main"]

Git-Workflow light

Die Arbeitsvereinbarung „Git-Workflow light“ beginnt mit Punkt 1, den Projekt-Grundlagen (Labels, Milestones, Issue Boards), die in Kapitel 06 stehen. Hier folgen die Punkte 2 bis 9 und die Vorlagen für GitLab.

Command Reference zu git workflow light findet ihr unter https://gitlab.com/htl-villach/personal/gam/selected/gam_internal/-/blob/main/projekte/anforderungen_software_projekte/git_workflow_commands.md

2. Branching-Modell

flowchart LR
  I["Issue #42"] --> F["feature/42-add-tags"]
  F -- "Merge Request + Review" --> D["dev (Integration)"]
  D -- "Release-MR, Tag v1.0.0" --> M["main (nur Releases)"]

• Feature-Branches werden aus einem Issue erstellt. Namenskonvention: feature/<issue-id>-<kurzbeschreibung>, also feature/42-add-tags. GitLab schlägt beim Button Create branch im Issue 42-add-tags vor, das Präfix feature/ ergänzt du dort.
• Merge-Ziel eines Feature-Branches ist immer dev.
• dev ist der Integrationsbranch: Hier kommt alles zusammen, was reviewt ist. dev wird nie gelöscht und ist der Default-Branch des Projekts (Einstellung im Sprint 0). Nur dann schließt Closes #42 das Issue beim Merge automatisch, und GitLab findet die Vorlagen im Ordner .gitlab/.
• main enthält ausschließlich funktionsfähige, getestete Releases. Gemergt wird nur von dev nach main, und nur im Rahmen eines Releases.
• Kein Squash-Merge, weder von Feature-Branches nach dev noch von dev nach main. Stell in den Merge-Request-Einstellungen des Projekts Squash commits when merging auf Do not allow.
• Direkte Commits auf dev oder main sind nicht erlaubt. Richte beide Branches in GitLab als Protected Branches ein (Push: No one, Merge: Developers + Maintainers). Dann verhindert GitLab den Fehler, statt dass er erst im Review auffällt.

Genauer erklärt: Warum kein Squash? Ein Squash-Merge fasst alle Commits eines Branches zu einem einzigen zusammen. Die Historie wird dadurch kürzer, aber es verschwindet genau das, was im Projekt als Nachweis zählt: wer welchen Schritt wann gemacht hat. Aus „Validierung ergänzt”, „Test für leere Eingabe” und „Review-Anmerkung umgesetzt” von zwei Personen wird ein Commit einer Person:

flowchart LR
  subgraph ohne["Merge ohne Squash"]
    direction TB
    C1["Validierung ergänzt"] --> C2["Test für leere Eingabe"]
    C2 --> C3["Review-Anmerkung umgesetzt"]
  end
  subgraph mit["Squash-Merge"]
    direction TB
    S1["ein Commit, eine Person"]
  end
  ohne -- "Squash" --> mit

Genauer erklärt: Warum zwei Hauptbranches statt einem? Solange nur main existiert, landet jede gemergte Story sofort im „offiziellen” Stand, auch wenn sie mit der Story von gestern noch nicht zusammenspielt. dev ist der Ort, an dem genau dieses Zusammenspiel getestet wird, main bleibt dadurch jederzeit vorführbar. Zeigst du beim Sprint Review einen Stand, der sich gerade nicht starten lässt, ist das in diesem Modell ein Hinweis auf einen übersprungenen Schritt, nicht Pech.

	nur main	dev + main
Wohin wird eine Story gemergt?	direkt in den offiziellen Stand	in den Integrationsstand
Ist der offizielle Stand jederzeit vorführbar?	nur, wenn jeder Merge perfekt war	ja, main bekommt nur getestete Releases
Wo fällt ein Zusammenspiel-Fehler auf?	im offiziellen Stand, oft erst im Review	auf dev, vor dem Release

Einrichten im Sprint 0

Zuerst entsteht dev aus dem aktuellen Stand von main und wird auf GitLab gepusht:

git switch main
git pull
git switch -c dev
git push -u origin dev

Danach stellst du in GitLab ein, was die Regeln absichert (Rolle Maintainer nötig):

1. dev als Default-Branch: Settings → Repository → Branch defaults aufklappen, bei Default branch dev wählen, Auto-close referenced issues on default branch aktivieren, Save changes.

2. main schützen: Settings → Repository → Branch rules. main ist meist schon geschützt, dann View details, sonst Add branch rule mit dem Branch-Namen main. Bei Allowed to push and merge über Edit die Rolle No one wählen, bei Allowed to merge Developers + Maintainers, jeweils Save changes. Allowed to force push bleibt aus.

3. dev schützen: dieselben Schritte mit Add branch rule für dev: Allowed to push and merge = No one, Allowed to merge = Developers + Maintainers, kein Force Push.

4. Squash abschalten: Settings → Merge requests, bei Squash commits when merging die Option Do not allow wählen, Save changes.

Ab jetzt beginnt jede Story gleich: aktuellen Stand von dev holen, Feature-Branch anlegen, pushen, Merge Request nach dev öffnen.

git switch dev
git pull
git switch -c feature/42-add-tags
# ... commits ...
git push -u origin feature/42-add-tags

Weil dev der Default-Branch ist, schließt Closes #42 im Merge Request das Issue beim Merge automatisch:

flowchart LR
  A["Issue #42"] --> B["Branch: feature/42-add-tags"]
  B --> C["MR: Closes #42"]
  C --> D["Review und Merge nach dev"]
  D --> E["Issue schließt automatisch"]

Ein Test, ob der Schutz greift: git push direkt auf dev oder main muss GitLab mit einer Meldung wie You are not allowed to push code to protected branches on this project ablehnen. Kommt die Meldung nicht, ist der Branch nicht geschützt.

3. Issues

Jede User Story wird als Issue erfasst. Jedes Issue enthält:

• eine Beschreibung (bei Stories im Format Rolle - Wunsch - Nutzen),
• Akzeptanzkriterien als Checkliste,
• ein Weight (die Schätzung in Story Points, siehe Abschnitt „Schätzen” in Kapitel 05),
• eine verantwortliche Person (Assignee),
• den Milestone des Sprints, sobald die Story eingeplant ist.

Optional: Issues verknüpfen und gliedern. Hängen Issues voneinander ab, machst du das im Abschnitt Linked items des Issues sichtbar (relates to, blocks, is blocked by) oder per Quick Action im Kommentar, z. B. /relate #17 oder /blocked_by #17. Ein Epic lässt sich über Child items in mehrere Issues gliedern (/add_child #43 #44 im Epic bzw. /set_parent im Issue). Blockierende Verknüpfungen und Epics sind Funktionen von GitLab Premium, das im HTL-Bereich zur Verfügung steht. In einem privaten GitLab-Free-Projekt fehlen sie.

4. Merge Requests und Review

Merge Requests sind für jede Änderung verpflichtend (Feature-Branch → dev). Ein Merge Request enthält:

• die Referenz auf das Issue (Closes #42),
• eine kurze Beschreibung der Umsetzung,
• einen Hinweis, welche Funktion(en) wie getestet wurden.

Review. Eine andere Person als die Autorin bzw. der Autor reviewt verpflichtend. Die reviewende Person prüft ausdrücklich die Akzeptanzkriterien und die Definition of Done und hinterlässt einen kurzen, inhaltlichen Kommentar - „LGTM” allein ist kein Review. Gemergt wird nicht von der Person, die den Merge Request erstellt hat. Der Weg eines Merge Request mit zwei Personen:

flowchart LR
  A["Autor:in öffnet MR"] --> R["andere Person reviewt"]
  R --> K["prüft Akzeptanzkriterien + DoD"]
  K --> C["inhaltlicher Kommentar"]
  C --> M["Merge, nicht durch Autor:in"]

Genauer erklärt: Die Vier-Augen-Regel ist keine Misstrauenserklärung. Wer den eigenen Code reviewt, liest, was er schreiben wollte, nicht, was dasteht. Eine zweite Person stolpert genau über die Stelle, an der die Annahme im Kopf und der Code auseinanderlaufen. Ganz nebenbei kennen danach zwei Leute jeden Teil des Systems, was bei Krankheit oder Teamwechsel den Unterschied macht.

5. Akzeptanzkriterien und Definition of Done

Die Akzeptanzkriterien sind Teil des Issues und werden im Merge Request überprüft. Gemergt wird nur, wenn

• alle Akzeptanzkriterien erfüllt sind und
• die Definition of Done vollständig erfüllt ist.

6. Zeiterfassung

• Time Spent regelmäßig erfassen, nicht am Sprintende aus dem Gedächtnis.
• Jeder Eintrag umfasst höchstens 50 Minuten und nennt Tätigkeit und Bezug zum Issue oder Merge Request.
• Auch Reviews und Merge Requests werden erfasst - Review ist Arbeit.

In GitLab erfasst du Zeit mit der Quick Action /spend in einem Kommentar des Issues bzw. Merge Requests. Der Kommentartext beschreibt die Tätigkeit:

/spend 45m
Implementierung der Eingabevalidierung (#23)

Trägst du die Zeit nicht am selben Tag ein, hängst du das Datum der Arbeit an: /spend 45m 2026-10-07.

Die Obergrenze von 50 Minuten erzwingt eine Granularität, bei der ein Eintrag noch etwas aussagt: „6h - Arbeit am Projekt” ist kein Nachweis, sechs Einträge mit je einer Tätigkeit sind einer.

7. Releases

• Ein Release entsteht über einen Release-Merge-Request dev → main, einen Release Tag (v1.0.0, Semantic Versioning) und ein GitLab Release mit Release Notes.
• Sinnvoller Takt: ein Release am Ende jedes Sprints, zusammen mit dem Schließen des Milestones.

Vom Feature-Branch bis zum geschlossenen Milestone sieht ein Release so aus:

flowchart LR
  F1["feature/42-add-tags"] -- "MR, kein Squash" --> D["dev"]
  D -- "Release-MR" --> M["main"]
  M --> T["Tag v1.0.0 + GitLab Release"]
  M --> S["Milestone schließen"]

8. Verbindlichkeit

Diese Regeln sind die gemeinsame Grundlage für die Bewertung der Projektarbeit: Die Board-, Merge-Request- und Zeitverläufe sind der Nachweis, wer was wann beigetragen hat. Arbeiten, die die Regeln nicht einhalten, können abgelehnt oder nicht bewertet werden. Wie sich das konkret auf die Beurteilung auswirkt, steht auf der Seite „Beurteilung” bzw. wird zu Beginn des Projekts mit der Lehrkraft vereinbart.

9. Optional: Mirror nach GitHub

Freiwillig kannst du dein GitLab-Projekt zusätzlich auf GitHub spiegeln, etwa damit es in deinem GitHub-Profil als Referenz für Bewerbungen sichtbar ist. GitLab bietet dafür einen Push-Mirror: Jeder Push auf GitLab wird automatisch an das GitHub-Repository weitergegeben. Gearbeitet wird weiterhin nur auf GitLab, dort entstehen Issues, Merge Requests und Zeiterfassung:

flowchart LR
  GL["GitLab: Issues, MRs, Zeiterfassung"] -- "Push-Mirror, alle Branches" --> GH["GitHub: Referenz im Profil"]

• Spiegle alle Branches (Option Only mirror protected branches ausgeschaltet), damit dev und die Feature-Branches auch auf GitHub zu sehen sind.
• Soll die Lehrkraft das GitHub-Repository einsehen, gib ihr dort Lesezugriff. Ihren GitHub-Benutzernamen erfährst du von ihr.

Vorlagen für GitLab

Die Vorlagen zu diesem Workflow kannst du als gitlab-templates.zip herunterladen. Entpacke das Archiv in das Wurzelverzeichnis deines Repositories und committe den Ordner .gitlab/ auf den Default-Branch (dev). Danach bietet GitLab die Vorlagen beim Anlegen eines Issues bzw. Merge Requests im Auswahlfeld Description an.

Datei	Zweck
.gitlab/issue_templates/user-story.md	User Story mit Rolle - Wunsch - Nutzen, Akzeptanzkriterien im Gegeben-wenn-dann-Format, setzt Labels, Weight und Assignee
.gitlab/issue_templates/defect.md	Fehlermeldung mit Ist/Soll, Reproduktionsschritten, Umgebung und Akzeptanzkriterien für den Fix
.gitlab/issue_templates/technical-improvement.md	Refactoring, Performance, Architektur - mit Motivation und messbaren Akzeptanzkriterien
.gitlab/merge_request_templates/default.md	Feature → dev: Issue-Referenz, Umsetzung, getestete Funktionen, Checkliste für Autor:in und Reviewer:in inkl. DoD und Zeiterfassung
.gitlab/merge_request_templates/release.md	dev → main: enthaltene Issues, Checkliste vor und nach dem Merge (Tag, GitLab Release, Milestone), Release Notes

Die Vorlagen enthalten am Ende GitLab-Quick Actions (/label, /weight, /assign, /assign_reviewer). Sie werden beim Speichern ausgeführt und aus der Beschreibung entfernt. Pass Weight und Reviewer vorher an.

Vorlage ist nicht Inhalt

Eine ausgefüllte Vorlage mit stehengebliebenen Platzhaltern wie [Rolle] oder Kriterium 1 ist schlechter als gar keine: Sie sieht nach Prozess aus, enthält aber keine Information. Im Review gilt ein Issue mit unveränderten Platzhaltern als nicht bereit für den Sprint.

Weiterlesen

• GitLab Docs: Description templates - wo Vorlagen liegen müssen und wie man eine Standardvorlage festlegt.
• GitLab Docs: Protected branches - wie du dev und main gegen direkte Pushes schützt.
• GitLab Docs: Time tracking - /spend, /estimate und die Zeitberichte pro Issue und Milestone.
• GitLab Docs: Linked issues und Child items - Abhängigkeiten zwischen Issues und die Gliederung von Epics.
• GitLab Docs: Push mirroring - Schritt für Schritt einen Mirror von GitLab nach GitHub einrichten.

Kurz nachgedacht

Im Review fällt auf: Ein Teammitglied hat seinen Feature-Branch selbst nach dev gemergt, der MR enthält als einzigen Kommentar „passt”. Gegen welche Regeln des Git-Workflow light verstößt das, und warum hat der Schutz von dev als Protected Branch es nicht verhindert?

Auflösung

Zwei Verstöße: Gemergt hat die Person, die den MR erstellt hat, und „passt” ist kein inhaltlicher Review-Kommentar. Der Protected Branch verbietet nur den direkten Push. Mergen über einen Merge Request dürfen laut Einstellung alle Developers, also auch die Autorin bzw. der Autor selbst. Diese Regel sichert deshalb die Vereinbarung im Team und die Kontrolle bei der Bewertung, nicht die Technik.

Zusatzmaterialien

• GitLab Docs: Quick actions - alle Befehle wie /label, /weight, /spend, die in den Projektvorlagen verwendet werden; lohnt sich, weil sie Board-Pflege zur Nebensache machen.
• Semantic Versioning - die Regeln hinter v1.0.0, die du für die Release-Tags brauchst.

Zum Anhören

Diesen Text kannst du dir kostenlos mit der Vorlesefunktion deines Browsers oder Betriebssystems vorlesen lassen, z. B. in Microsoft Edge über „Laut vorlesen”.

Lernergebnisse: Was du nach diesem Kapitel können solltest

• Erklären: das Branching-Modell mit dev und main erklären und begründen, warum es ohne Squash-Merge und ohne direkte Commits auskommt.
• Anwenden: den Git-Workflow light im eigenen GitLab-Projekt einrichten: Default-Branch, Protected Branches und Merge-Request-Einstellungen.
• Anwenden: Issues, Merge Requests mit Review, Zeiterfassung und Releases so anlegen, dass der Prozessnachweis nebenbei entsteht.
• Beurteilen: Verstöße gegen den Git-Workflow light im Review beurteilen und begründen, welche Regel die Technik absichert und welche das Team.

Passende Übungen

• Aufgabe 03 - Jahresprojekt Sprint 0

Autoren

GAM

Lizenz

CC-BY-SA

Regeln

https://qiz.at/rules