Die Druckversion wird nicht mehr unterstützt und kann Darstellungsfehler aufweisen. Bitte aktualisiere deine Browser-Lesezeichen und verwende stattdessen die Standard-Druckfunktion des Browsers.

aiMOOC

Anwendungsentwicklung und Softwarequalität – Versionsverwaltung im Team verwenden

QR-Code

Anwendungsentwicklung und Softwarequalität – Versionsverwaltung im Team verwenden

Zielgruppe: Auszubildende Fachinformatik – Anwendungsentwicklung

Niveau: Ausbildung | Grundlagen bis Transfer

Lernzeit: 90–120 Minuten, einschließlich Übungen

Kurzbeschreibung: Änderungen nachvollziehen, Branches im Team verwenden, Code-Reviews durchführen und Merge-Konflikte fachlich begründet lösen.

Lernziele: Du kannst einen lokalen Git-Workflow anwenden, Änderungen prüfen, automatisierte Tests ausführen, Review-Feedback geben und einen Merge-Konflikt sicher auflösen.

Lernprinzip: Anschauen → Ausprobieren → Überprüfen → Erklären → Übertragen

Sicherheitsrahmen: Alle ausführbaren Beispiele verwenden ausschließlich fiktive Dateien in neu angelegten lokalen Testverzeichnissen. Es werden keine externen Repositories, Produktivsysteme, Kundendaten, Zugangsdaten oder Netzwerkverbindungen benötigt. Die eingebundenen Lernmedien sind externe Informationsangebote, keine Testumgebungen.

Einleitung

Versionsverwaltung macht Änderungen an Software nachvollziehbar. Das verbreitete Versionsverwaltungssystem Git ermöglicht parallele Entwicklung, überprüfbare Änderungen und das Zusammenführen verschiedener Arbeitsstände.

Abbildung: Git-Arbeitsbereiche und typische Befehle. Für die Übungen werden nur lokale Funktionen verwendet.

Drei Schritte zur Softwarequalität:

Ändern: Entwickle eine Änderung in einem eigenen Branch.
Prüfen: Untersuche den Diff, teste das Ergebnis und besprich es im Code-Review.
Zusammenführen: Integriere freigegebene Änderungen und löse mögliche Konflikte.

Lernvideo: Grundlagen zu Staging-Bereich und Commits, 3:36 Minuten, englisch.

Datei:Git Foundations - Commit.webm

Ausbildungsfall: Die Lernwerkstatt

Dein fiktives Ausbildungsteam entwickelt eine kleine Python-Anwendung zur Verwaltung von Workshop-Plätzen.

Ausgangssituation:

Teamrolle	Änderungsvorschlag	Begründung
Entwicklungsteam	12 Plätze	Aktueller Ausgangsstand
Raumplanung	14 Plätze	Größere Raumkapazität
Inklusionsplanung	13 Plätze	Zusätzlicher Bewegungsraum

Fachliche Anforderungen:

Die Platzanzahl muss positiv sein und darf 14 nicht überschreiten.
Änderungen müssen nachvollziehbar gespeichert werden.
Vor einer Freigabe müssen Tests und Reviews durchgeführt werden.
Bei widersprüchlichen Vorschlägen entscheidet das Team anhand fachlicher Kriterien.

Dein Auftrag: Simuliere diese Zusammenarbeit in zwei voneinander getrennten lokalen Git-Testlaboren. Die Personen und Anforderungen des Ausbildungsfalls sind erfunden.

Lerneinheit 1: Git verstehen

Dauer: 10 Minuten

Arbeitsverzeichnis, Staging und Repository

Arbeitsbereich	Bedeutung	Git-Befehl
Working Directory	Hier bearbeitest Du Dateien.	git status
Staging Area	Hier merkst Du Änderungen vor.	git add
Lokales Repository	Hier werden Commits gespeichert.	git commit

Datei bearbeiten
       |
       v
Working Directory
       |
     git add
       |
       v
Staging Area
       |
    git commit
       |
       v
Lokaler Commit

Video: Deutschsprachiges Git-Tutorial. Für diese Lerneinheit besonders relevant: 05:41–10:52.

Merksatz: Ein Commit ist ein gespeicherter Projektstand. Ein Commit ist weder ein Backup des gesamten Computers noch automatisch eine Veröffentlichung im Internet.

Mini-Check

Frage: Warum reicht das Bearbeiten einer Datei noch nicht aus, um einen Commit zu erstellen?

Feedback: Git unterscheidet Arbeitsverzeichnis, Staging und lokale Historie. Erst durch das Vormerken und Committen wird die Änderung Bestandteil der Git-Historie.

Lerneinheit 2: Lokales Git-Labor A einrichten

Dauer: 15 Minuten

Voraussetzungen: Git ab Version 2.28, Python 3 und eine Bash-Umgebung unter Linux, macOS oder WSL. Die Beispiele verwenden keine externen Python-Pakete.

Sicherheitsregel: Verwende ein Terminal auf Deinem eigenen Rechner oder in einer ausdrücklich freigegebenen Übungsumgebung. Führe die Befehle nicht in einem vorhandenen Projekt aus.

Testumgebung A: Repository und Python-Tests

Kopiere den folgenden vollständigen Block in eine Bash-Sitzung. Die Variable LAB_A bezeichnet das neu erzeugte temporäre Verzeichnis.

LAB_A="$(mktemp -d)"
cd "$LAB_A"

git init -b main
git config --local user.name "Azubi Lokal"
git config --local user.email "azubi@example.invalid"

printf 'Projekt: Lernwerkstatt\nPlaetze: 12\n' > kurs.txt
printf '__pycache__/\n*.pyc\n' > .gitignore

cat > app.py <<'PY'
from pathlib import Path

def kapazitaet():
    for zeile in Path("kurs.txt").read_text(
        encoding="utf-8"
    ).splitlines():
        if zeile.startswith("Plaetze:"):
            return int(zeile.split(":", 1)[1])
    raise ValueError("Plaetze fehlt")

def frei(gebucht):
    if gebucht < 0:
        raise ValueError("Negative Buchungen")
    return max(0, kapazitaet() - gebucht)
PY

cat > test_app.py <<'PY'
import unittest
from app import kapazitaet, frei

class LernwerkstattTests(unittest.TestCase):
    def test_limit(self):
        self.assertLessEqual(kapazitaet(), 14)

    def test_frei(self):
        self.assertEqual(frei(2), kapazitaet() - 2)

    def test_negativ(self):
        with self.assertRaises(ValueError):
            frei(-1)
PY

git add .gitignore kurs.txt app.py test_app.py
git commit -m "Lernwerkstatt mit Tests starten"

python3 -m unittest -v
git status --short

Erwartung: Drei erfolgreiche Tests mit der Abschlussmeldung OK. Nach dem Commit gibt `git status --short` bei einem unveränderten Repository keine Zeile aus.

Warum diese Tests? Sie überprüfen die maximale Kapazität, die Berechnung freier Plätze und die Zurückweisung negativer Buchungszahlen.

Gestufte Hilfen

Hilfe A – Orientierung: Prüfe mit git --version und python3 --version, ob die Werkzeuge verfügbar sind.
Hilfe B – Fehlersuche: Nutze git status, um den Zustand des Repositories zu erkennen.
Hilfe C – Lösungshinweis: Falls ein Commit wegen fehlender Identität nicht funktioniert, kontrolliere die beiden lokalen git config --local-Einträge.

Basisaufgabe: Erkläre den Unterschied zwischen einer bearbeiteten Datei und einem Commit.

Feedback: Eine bearbeitete Datei gehört zunächst zum Arbeitsverzeichnis. Ein Commit dokumentiert einen ausdrücklich gespeicherten Stand. Die Unterscheidung ist für reproduzierbare Änderungen entscheidend.

Lerneinheit 3: Feature-Branches verwenden

Dauer: 10 Minuten

Ein Feature-Branch trennt eine geplante Änderung zunächst von der Hauptentwicklung.

Abbildung: Ein Entwicklungszweig entsteht aus einem gemeinsamen Commit.

Praxis: Die Raumplanung ändern

Führe diese Befehle im Repository LAB_A aus:

git switch -c feature/raumplanung

printf 'Projekt: Lernwerkstatt\nPlaetze: 14\n' > kurs.txt

git diff -- kurs.txt
python3 -m unittest -v

git add kurs.txt
git commit -m "Kurskapazitaet auf 14 setzen"

git log --graph --oneline --decorate --all

Erwartung: Der Diff zeigt die Änderung von 12 auf 14 Plätze. Die drei Tests bleiben erfolgreich.

Wichtig: Ein erfolgreicher Test bestätigt nur die getesteten Regeln. Er beweist noch nicht, dass die erhöhte Raumkapazität fachlich genehmigt wurde.

Branch-Verlauf verstehen

Start-Commit A
      |
      +---- main
      |
      +---- feature/raumplanung
                     |
                     B: 12 -> 14

Kontrollfrage: Warum ist die Änderung auf main noch nicht enthalten?

Feedback: Der neue Commit liegt zunächst auf dem Feature-Branch. Branches ermöglichen parallele Arbeiten, ohne jede Änderung sofort in die Hauptentwicklung aufzunehmen.

Lerneinheit 4: Code-Reviews und Softwaretests

Dauer: 15 Minuten

Ein Code-Review prüft Änderungen hinsichtlich Korrektheit, Verständlichkeit, Wartbarkeit und Anforderungen.

Abbildung: Vereinfachter Team-Workflow mit Branches und Prüfung. Im Kurs wird der Review-Schritt ohne Server lokal nachgebildet.

Änderungen lokal reviewen

Bleibe in LAB_A und führe aus:

git diff main...feature/raumplanung -- kurs.txt

python3 -m unittest -v

git status

Review-Checkliste:

Anforderung: Ist die neue Platzanzahl fachlich zulässig?
Diff: Wurden nur die vorgesehenen Dateien verändert?
Tests: Sind die lokalen Tests erfolgreich?
Nachvollziehbarkeit: Ist die Commit-Nachricht verständlich?
Freigabe: Sind offene Fragen geklärt?

Kurzvideo: Unterschiede zwischen Dateiversionen mit Git Diff erkennen, 3:10 Minuten, englisch.

Datei:Git Foundations - Diff.webm

Review-Protokoll – lokale Übung

Prüfpunkt	Ergebnis im Ausbildungsfall
Technischer Test	Drei Tests erfolgreich
Änderung	Platzanzahl von 12 auf 14
Fachliche Freigabe	Noch zu klären
Review-Entscheidung	Änderung zunächst nicht integrieren

Beispiel für konstruktives Review-Feedback:

Die Änderung ist nachvollziehbar und erfüllt die bisher automatisiert geprüfte Obergrenze. Bitte kläre vor der Freigabe, ob die Inklusionsplanung einen zusätzlichen Platzbedarf für Bewegungsflächen vorsieht. Ein erfolgreicher Test ersetzt diese fachliche Abstimmung nicht.

Wichtig: Ein lokaler Diff ist noch kein formaler Pull Request. Auf Hosting-Plattformen können Reviews zusätzlich Kommentare, Genehmigungen und Änderungsanforderungen dokumentieren. Im Kurs werden diese Schritte ohne Online-Dienst simuliert.

Gestufte Review-Hilfen

Hilfe A: Frage Dich, welche fachliche Regel ein Test absichert.
Hilfe B: Vergleiche Ausgangszustand und Änderung mit git diff main...feature/raumplanung.
Hilfe C: Formuliere Dein Feedback nach dem Muster „Beobachtung – Risiko – konkrete Bitte“.

Anwendungsaufgabe: Schreibe einen eigenen Review-Kommentar zur Erhöhung der Kurskapazität.

Feedback: Gutes Review-Feedback nennt eine konkrete Beobachtung und begründet eine notwendige Entscheidung. Ein bloßes „Sieht gut aus“ reicht nicht aus, wenn eine fachliche Anforderung ungeklärt ist.

Lerneinheit 5: Merge-Konflikte erkennen

Dauer: 15 Minuten

Ein Merge-Konflikt kann entstehen, wenn zwei Branches denselben Textbereich unterschiedlich verändern und Git keine eindeutige automatische Zusammenführung vornehmen kann.

Abbildung: Zwei Entwicklungszweige und ihre Zusammenführung.

Testumgebung B: Konflikt gezielt auslösen

Neues, unabhängiges Testlabor: Der folgende Block funktioniert unabhängig von LAB_A. Er erzeugt ein zweites lokales Repository.

LAB_B="$(mktemp -d)"
cd "$LAB_B"

git init -b main
git config --local user.name "Azubi Lokal"
git config --local user.email "azubi@example.invalid"

printf 'Projekt: Lernwerkstatt\nPlaetze: 12\n' > kurs.txt
printf '__pycache__/\n*.pyc\n' > .gitignore

cat > test_kurs.py <<'PY'
from pathlib import Path
import unittest

class PlatzTest(unittest.TestCase):
    def test_obergrenze(self):
        daten = Path("kurs.txt").read_text(
            encoding="utf-8"
        )
        plaetze = int(
            daten.split("Plaetze: ", 1)[1].splitlines()[0]
        )
        self.assertLessEqual(plaetze, 14)
        self.assertGreater(plaetze, 0)
PY

git add kurs.txt .gitignore test_kurs.py
git commit -m "Kursplanung initialisieren"

git switch -c feature/raumplanung
printf 'Projekt: Lernwerkstatt\nPlaetze: 14\n' > kurs.txt
git commit -am "Raumplanung erlaubt 14"

git switch main
git switch -c feature/inklusion
printf 'Projekt: Lernwerkstatt\nPlaetze: 13\n' > kurs.txt
git commit -am "Inklusionsreserve setzt 13"

git switch main
git merge --no-ff feature/raumplanung \
  -m "Raumplanung integrieren"

git merge --no-ff feature/inklusion \
  -m "Inklusionsreserve integrieren"

git status --short
cat kurs.txt

Achtung: Der zweite Merge soll ausdrücklich mit einem Konflikt anhalten. Seine Fehlermeldung ist Teil der Übung und bedeutet nicht, dass das Testlabor beschädigt ist. Führe danach die Status- und Anzeige-Befehle aus.

Erwartete Statusanzeige:

UU kurs.txt

Möglicher Konfliktbereich:

<<<<<<< HEAD
Plaetze: 14
=======
Plaetze: 13
>>>>>>> feature/inklusion

Bedeutung:

Markierung	Bedeutung im Beispiel
HEAD	Aktueller Stand mit 14 Plätzen
Trennlinie	Trennt die beiden konkurrierenden Änderungen
feature/inklusion	Eingehender Stand mit 13 Plätzen

Warum stoppt Git? Beide Änderungen betreffen dieselbe Zeile. Git kennt die fachlichen Gründe für die unterschiedlichen Werte nicht.

Lernvideo: Branches und Merge-Konflikte. Deutschsprachige Ergänzung zum lokalen Konfliktlabor.

Gestufte Konflikthilfen

Hilfe A – Diagnose: Schaue zuerst mit git status nach, welche Datei nicht zusammengeführt ist.
Hilfe B – Vergleich: Lies beide Werte zwischen den Konfliktmarkierungen und identifiziere ihre jeweilige Herkunft.
Hilfe C – Fachliche Entscheidung: Vergleiche beide Vorschläge mit der maximalen Kapazität und dem zusätzlichen Raumbedarf.

Anwendungsaufgabe: Erkläre, warum Git den Konflikt nicht eigenständig entscheiden sollte.

Feedback: Git kann Textänderungen vergleichen, aber nicht beurteilen, welcher Vorschlag die räumlichen und organisatorischen Anforderungen besser erfüllt. Die Entscheidung liegt beim Team.

Lerneinheit 6: Konflikte lösen und Qualität sichern

Dauer: 10 Minuten

Im Ausbildungsfall entscheidet das Team nach der Abstimmung, 13 Plätze vorzusehen. Damit bleibt zusätzliche Bewegungsfläche verfügbar.

Abbildung: Nach dem Auflösen eines Konflikts kann die Zusammenführung abgeschlossen werden.

Konflikt auflösen

Führe die nächsten Befehle in LAB_B aus, während der Merge-Konflikt noch offen ist:

printf 'Projekt: Lernwerkstatt\nPlaetze: 13\n' > kurs.txt

git add kurs.txt

git diff --cached --check

python3 -m unittest -v

git commit -m "Konflikt nach Review auf 13 Plaetze loesen"

git status --short
git log --graph --oneline --all --decorate

Erwartung:

Die Konfliktmarkierungen sind entfernt.
Der automatisierte Test besteht.
Der Merge ist abgeschlossen.
Das Arbeitsverzeichnis ist sauber.
Der Commit-Verlauf zeigt die zusammengeführten Entwicklungslinien.

Abbruchmöglichkeit: Solange der Konflikt noch nicht abgeschlossen ist, kann git merge --abort den Mergeversuch abbrechen. Benutze diesen Befehl nur im Übungsrepository und beachte, dass ungesicherte Änderungen einen sicheren Abbruch erschweren können.

Visualisierte Ergebnisse

Merkmal	Ausgangszustand	Raumplanung	Teamentscheidung
Plätze	12	14	13
Obergrenze	Erfüllt	Erfüllt	Erfüllt
Zusätzliche Bewegungsreserve	Ausgangsplanung	Noch ungeklärt	Berücksichtigt
Entscheidung	Startzustand	Review erforderlich	Lokal integriert

Wichtig: Diese Tabelle zeigt die fiktiven Daten des Ausbildungsfalls. Die tatsächlichen Commit-Kennungen und der Commit-Graph werden von Git in Deiner eigenen Testumgebung erzeugt.

Reflexionsfrage

Warum ist ein erfolgreich abgeschlossener Merge allein noch kein Qualitätsnachweis?

Begründetes Feedback: Ein erfolgreicher Merge zeigt, dass Git die Änderungen technisch zusammenführen konnte. Ob die Software fachlich richtig, sicher und wartbar ist, muss zusätzlich durch Reviews, Tests und geeignete Freigabeprozesse bewertet werden.

Vertiefung: Teamregeln für gute Softwarequalität

Teamregel	Begründung
Kleine Commits	Änderungen bleiben verständlich.
Aussagekräftige Commit-Nachrichten	Entscheidungen werden besser nachvollziehbar.
Kurze Feature-Branches	Abweichungen von der Hauptentwicklung bleiben überschaubar.
Reviews vor dem Merge	Fehler und unklare Anforderungen können früh erkannt werden.
Automatisierte Tests	Bekannte Anforderungen werden wiederholbar geprüft.
Konflikte gemeinsam klären	Die Zusammenführung berücksichtigt technische und fachliche Aspekte.
Keine Secrets im Repository	Zugangsdaten sollen nicht in der Versionshistorie landen.

Zusammenhang: Continuous Integration, Softwaretest, Code-Review und Versionsverwaltung ergänzen sich. Keines dieser Verfahren ersetzt allein alle anderen Qualitätssicherungsmaßnahmen.

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Welcher Git-Befehl zeigt den Zustand des Arbeitsverzeichnisses? (git status) (!git commit) (!git merge) (!git branch)

Wozu dient die Staging Area? (Änderungen für den nächsten Commit vormerken) (!Änderungen automatisch auf einen Server übertragen) (!Alle Merge-Konflikte beseitigen) (!Automatisch ein Review genehmigen)

Was ist ein Commit? (Ein gespeicherter Projektstand in der lokalen Git-Historie) (!Eine automatische Veröffentlichung im Internet) (!Ein vollständiges Backup des Rechners) (!Ein dauerhaft laufender Testserver)

Warum verwendet ein Team Feature-Branches? (Um Änderungen zunächst getrennt zu entwickeln) (!Um automatisierte Tests überflüssig zu machen) (!Um die Versionshistorie zu löschen) (!Um alle Konflikte grundsätzlich zu verhindern)

Welcher Befehl erstellt einen neuen Branch und wechselt auf ihn? (git switch -c feature/planung) (!git status feature/planung) (!git add feature/planung) (!git log feature/planung)

Welcher Befehl eignet sich für die lokale Prüfung von Änderungen gegenüber main? (git diff main...feature/raumplanung) (!git init main) (!git config main) (!git commit main)

Was gehört zu einem guten Code-Review? (Änderungen anhand von Anforderungen und Tests begründet prüfen) (!Änderungen grundsätzlich ohne Prüfung übernehmen) (!Nur die Anzahl der geänderten Zeilen zählen) (!Automatisierte Tests immer ignorieren)

Wann kann ein Merge-Konflikt entstehen? (Wenn dieselben Textbereiche unterschiedlich verändert wurden) (!Bei jedem erfolgreichen Commit) (!Immer beim Anzeigen eines Git-Logs) (!Bei jeder Verwendung von git status)

Was musst Du nach der manuellen Konfliktlösung tun? (Die bereinigte Datei vormerken und den Merge abschließen) (!Das gesamte Repository löschen) (!Alle vorhandenen Tests entfernen) (!Die Konfliktmarkierungen unverändert committen)

Warum sind erfolgreiche Tests und Reviews gemeinsam wichtig? (Weil sie unterschiedliche Qualitätsrisiken abdecken) (!Weil beide immer denselben Fehler finden) (!Weil dadurch jede fachliche Abstimmung entfällt) (!Weil ein erfolgreicher Test jede Änderung automatisch freigibt)

Memory

Ordne den Git-Begriffen die passende Erklärung zu.

Working Directory	Bereich für bearbeitete Dateien
Staging Area	Vormerkbereich für einen Commit
Commit	Gespeicherter Projektstand
Feature-Branch	Getrennter Entwicklungszweig
Diff	Darstellung von Änderungen
Code-Review	Fachliche Prüfung einer Änderung
Merge-Konflikt	Nicht automatisch zusammenführbare Änderung
Repository	Speicherort der Git-Projekthistorie

Drag and Drop

Ordne die Befehle ihrer Funktion zu.

Ordne die richtigen Begriffe zu.	Funktion
git status	Arbeitszustand prüfen
git add	Änderung vormerken
git commit	Projektstand speichern
git diff	Änderungen vergleichen
git switch	Entwicklungszweig wechseln
git merge	Entwicklungszweige zusammenführen

Kreuzworträtsel

Branch	Wie heißt ein eigenständiger Entwicklungszweig in Git?
Commit	Wie nennt Git einen gespeicherten Projektstand?
Review	Wie heißt die fachliche Prüfung vorgeschlagener Änderungen?
Merge	Wie lautet der englische Begriff für das Zusammenführen von Entwicklungszweigen?
Konflikt	Was entsteht, wenn Änderungen nicht automatisch zusammengeführt werden können?
Repository	Wie nennt man einen Speicherort der Git-Projekthistorie?

LearningApps

Ergänzende Suchergebnisse für Lernübungen. Die Verfügbarkeit und Inhalte einzelner LearningApps sind unabhängig von diesem Kurs.

Lückentext

Git ist ein

Versionsverwaltungssystem.

Mit git

prüfst Du den Arbeitszustand.

Der Befehl git

merkt Änderungen für einen Commit vor.

Mit git

speicherst Du den vorgemerkten Stand.

Ein

ermöglicht parallele Entwicklung.

Mit git

wechselst Du den Entwicklungszweig.

Ein git

zeigt Unterschiede zwischen Dateiständen.

Bei einem

werden Änderungen fachlich geprüft.

Ein Merge-

erfordert eine Entscheidung über widersprüchliche Änderungen.

Nach einer Konfliktlösung müssen die Markierungen

sein.

Automatisierte

können bekannte Fehlerfälle erkennen.

Für eine gute Teamentscheidung ist die fachliche

entscheidend.

Basis-, Anwendungs- und Transferaufgaben mit Feedback

Niveau	Kontrollaufgabe	Begründetes Feedback
Basis	Prüfe den Git-Status nach einem Commit.	Ein sauberer Status zeigt, dass aktuell keine uncommitteten Änderungen vorliegen. Er beweist nicht automatisch die fachliche Korrektheit.
Anwendung	Prüfe einen Feature-Branch mit Diff, Tests und Review.	Erst die Verbindung technischer und fachlicher Prüfungen ergibt eine belastbare Grundlage für die Entscheidung.
Transfer	Löse den Kapazitätskonflikt und dokumentiere die Teamentscheidung.	Die Auswahl des Endwertes muss aus Anforderungen abgeleitet werden. Konfliktfreiheit allein ist kein Freigabekriterium.

Selbstkontrolle: Eine gute Antwort erklärt nicht nur, was Du getan hast, sondern auch, warum Deine Entscheidung für die Softwarequalität sinnvoll ist.

Offene Aufgaben

Leicht – Basis

Git-Protokoll: Erstelle eine kurze, kommentierte Übersicht über die Befehle status, add, commit und diff. Erkläre jeweils ihre Aufgabe.
Arbeitsablauf zeichnen: Gestalte eine Grafik mit Working Directory, Staging Area und lokalem Repository.
Branches erkunden: Erstelle einen zusätzlichen lokalen Übungsbranch und dokumentiere den Branchwechsel mit eigenen Screenshots.
Testergebnis verstehen: Führe die Python-Tests aus und erläutere, welche drei Anforderungen beziehungsweise Verhaltensweisen in LAB_A überprüft werden.

Standard – Anwendung

Review schreiben: Formuliere ein Review zur Raumplanung mit einer positiven Beobachtung und einer begründeten Änderungsanforderung.
Änderungen vergleichen: Erstelle zwei unterschiedliche Commits in einem eigenen lokalen Feature-Branch und analysiere die Diffs.
Merge-Konflikt dokumentieren: Wiederhole LAB_B und gestalte ein kurzes Bildschirmtutorial mit Diagnose, fachlicher Entscheidung und Konfliktlösung.
Qualitätstest erweitern: Ergänze einen Python-Test für den Fall, dass mehr Plätze gebucht werden als verfügbar sind. Begründe, welches Verhalten Du für sinnvoll hältst.

Schwer – Transfer

Moduländerung organisieren: Simuliere zwei parallele Änderungen an einer fiktiven Python-Anwendung und entwickle eine konfliktarme Branch-Strategie.
Review-Richtlinie entwickeln: Gestalte eine eigene Checkliste für kleine Entwicklungsteams. Begründe die Bedeutung jedes Qualitätskriteriums.
Fehlerorientiertes Testen: Verändere die lokale Anwendung absichtlich so, dass ein Test fehlschlägt. Dokumentiere Fehlerursache, Diagnose, Korrektur und Testergebnis.
Teamkonflikt lösen: Entwickle für eine fiktive Anforderung mit widersprüchlichen Änderungsvorschlägen ein Entscheidungsverfahren, das Sicherheit, Nutzerbedürfnisse und technische Qualität berücksichtigt.

Lernkontrolle

Bearbeite die folgenden Aufgaben selbstständig. Im Vordergrund stehen Zusammenhänge, begründete Entscheidungen und die Übertragung auf neue Situationen.

Änderungsstrategie: Zwei Auszubildende entwickeln gleichzeitig neue Funktionen. Erkläre, welche Branch-Strategie Du wählen würdest und wie sie Risiken begrenzen kann.
Freigabeentscheidung: Alle Tests bestehen, aber ein Reviewer entdeckt eine nicht geklärte Sicherheitsanforderung. Entscheide begründet über die Freigabe.
Konfliktanalyse: Zwei Branches verändern dieselbe Konfiguration unterschiedlich. Entwickle eine Methode, um technische und fachliche Konflikte voneinander zu unterscheiden.
Testqualität: Beschreibe ein Beispiel, bei dem alle vorhandenen Tests bestehen, obwohl die Software eine wichtige Anforderung verletzt.
Fehlerdiagnose: Nach einem Merge meldet Git weiterhin unzusammengeführte Dateien. Erläutere einen geeigneten Diagnose- und Lösungsablauf.
Transfer: Übertrage die Prinzipien des Ausbildungsfalls auf ein größeres Teamprojekt mit mehreren Komponenten. Entwickle eine begründete Reihenfolge für Änderung, Review, Tests und Integration.

Bewertungsraster

Kriterium	Basis	Gut	Sehr gut
Git-Verständnis	Befehle korrekt anwenden	Zustände erklären	Zusammenhänge selbstständig übertragen
Review	Fehler oder Fragen erkennen	Feedback begründen	Technische und fachliche Risiken abwägen
Konfliktlösung	Konflikt beseitigen	Lösung testen	Entscheidung nachvollziehbar dokumentieren
Softwarequalität	Tests durchführen	Grenzen von Tests erkennen	Weitere Prüfungen gezielt begründen

Lernnachweis

Für Deinen Lernnachweis solltest Du folgende Ergebnisse vorweisen können:

Ein selbstständig eingerichtetes, isoliertes lokales Git-Repository mit fiktiven Testdaten.
Einen nachvollziehbaren Commit-Verlauf mit sinnvoller Branch-Nutzung.
Einen dokumentierten Diff mit verständlicher Beschreibung der Änderung.
Mindestens einen begründeten Review-Kommentar mit fachlicher Bewertung.
Erfolgreiche lokale Testläufe und eine Erklärung der geprüften Anforderungen.
Ein Protokoll der Diagnose und Auflösung eines Merge-Konflikts.
Eine reflektierte Entscheidung darüber, weshalb die gewählte Lösung die Softwarequalität verbessert.
Eine Übertragung der erlernten Vorgehensweise auf eine weitere fiktive Entwicklungssituation.

Nachweisformen: Eigenes Lernprotokoll, kommentierte Screenshots, lokales Übungsrepository, kurze Bildschirmaufnahme oder mündliche Präsentation.

Datenschutz: Verwende ausschließlich Testdaten. Reiche keine Zugangsdaten, Kundendaten oder fremden Repository-Inhalte ein.

OERs zum Thema

Wikipedia: Versionsverwaltung

Wikipedia: Git

Fachlich geprüfte Informationsquellen

Pro Git – Einfaches Branching und Merging: Grundlagen zu Branches, Merges und Konflikten.
Offizielle Git-Dokumentation – Status: Arbeitsverzeichnis und unzusammengeführte Dateien.
Offizielle Git-Dokumentation – Diff: Änderungen vergleichen.
Offizielle Git-Dokumentation – Switch: Branches erstellen und wechseln.
Offizielle Git-Dokumentation – Merge: Zusammenführen und Konflikte bearbeiten.
GitHub-Dokumentation – Pull-Request-Reviews: Kommentare und Freigaben im Team.
Atlassian – Merge-Konflikte: Ergänzende technische Erklärung.

Mediennachweise und Rechte

Geprüfte Wikimedia-Commons-Medien:

Git operations.svg: Daniel Kinzler, CC BY 3.0.
Git branches fork.svg: Bunyk, CC BY-SA 4.0.
Git branches two forks and merge.svg: Bunyk, CC BY-SA 4.0.
Git branches merge.svg: Bunyk, CC BY-SA 4.0.
Basic git branching workflow: TheresNoTime, CC BY-SA 4.0.
Git Foundations – Commit: GitHub, CC BY 3.0.
Git Foundations – Diff: GitHub, CC BY 3.0.
Git Foundations – Merge: GitHub, CC BY 3.0.

YouTube: Die eingebetteten Git-Tutorials sind verlinkte externe Lehrmedien. Aus der öffentlichen Verfügbarkeit oder Einbettbarkeit wird keine Creative-Commons-Lizenz abgeleitet. Für eigene Weiterveröffentlichungen sind die jeweiligen Nutzungsrechte gesondert zu prüfen.

Lizenzhinweis: Die Lizenzangaben beziehen sich auf die jeweiligen Originaldateien bei Wikimedia Commons. Urheberangaben und Lizenzbedingungen, insbesondere Namensnennung und gegebenenfalls Weitergabe unter gleichen Bedingungen, sind bei einer Weiterverwendung einzuhalten.

Technischer Hinweis: Die Medien und Links stellen Informationsquellen dar. Der praktische Git-Teil arbeitet ausschließlich mit lokal erzeugten Dateien und benötigt weder eine Cloud-Plattform noch Zugriff auf ein fremdes Netzwerk.