Glanz: aiMOOC über GPT aiMOOC Action erstellt

2026-10-09T19:33:49Z

aiMOOC über GPT aiMOOC Action erstellt

Neue Seite

{{T}}
{{BR}}
= 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.

{{BR}}
= 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.

[[Datei:Git operations.svg|500px|rahmenlos|center]]

''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|500px|center]]

{{BR}}
= Ausbildungsfall: Die Lernwerkstatt =

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

'''Ausgangssituation:'''

{| class="wikitable"
! 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.

{{BR}}
= Lerneinheit 1: Git verstehen =

'''Dauer:''' 10 Minuten

{{BR}}
== Arbeitsverzeichnis, Staging und Repository ==

{| class="wikitable"
! 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
|}

<pre>
Datei bearbeiten
|
v
Working Directory
|
git add
|
v
Staging Area
|
git commit
|
v
Lokaler Commit
</pre>

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

{{#ev:youtube|https://www.youtube.com/watch?v=v1ibwg3zaQQ|500|center}}

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

{{BR}}
== 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.

{{BR}}
= 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.

{{BR}}
== 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.

<pre>
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
</pre>

'''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.

{{BR}}
== Gestufte Hilfen ==

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

{{BR}}
= Lerneinheit 3: Feature-Branches verwenden =

'''Dauer:''' 10 Minuten

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

[[Datei:Git branches fork.svg|500px|rahmenlos|center]]

''Abbildung: Ein Entwicklungszweig entsteht aus einem gemeinsamen Commit.''

{{BR}}
== Praxis: Die Raumplanung ändern ==

'''Führe diese Befehle im Repository LAB_A aus:'''

<pre>
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
</pre>

'''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.

{{BR}}
== Branch-Verlauf verstehen ==

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

'''Kontrollfrage:''' Warum ist die Änderung auf <code>main</code> 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.

{{BR}}
= Lerneinheit 4: Code-Reviews und Softwaretests =

'''Dauer:''' 15 Minuten

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

[[Datei:Basic git branching workflow (GitLab).svg|500px|rahmenlos|center]]

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

{{BR}}
== Änderungen lokal reviewen ==

'''Bleibe in LAB_A und führe aus:'''

<pre>
git diff main...feature/raumplanung -- kurs.txt

python3 -m unittest -v

git status
</pre>

'''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|500px|center]]

{{BR}}
== Review-Protokoll – lokale Übung ==

{| class="wikitable"
! 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:'''

<blockquote>
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.
</blockquote>

'''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.

{{BR}}
== Gestufte Review-Hilfen ==

# '''Hilfe A:''' Frage Dich, welche fachliche Regel ein Test absichert.
# '''Hilfe B:''' Vergleiche Ausgangszustand und Änderung mit <code>git diff main...feature/raumplanung</code>.
# '''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.

{{BR}}
= 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.

[[Datei:Git branches two forks and merge.svg|500px|rahmenlos|center]]

''Abbildung: Zwei Entwicklungszweige und ihre Zusammenführung.''

{{BR}}
== 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.

<pre>
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
</pre>

'''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:'''

<pre>
UU kurs.txt
</pre>

'''Möglicher Konfliktbereich:'''

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

'''Bedeutung:'''

{| class="wikitable"
! 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.

{{#ev:youtube|https://www.youtube.com/watch?v=_VPpFU3Jyq4|500|center}}

{{BR}}
== Gestufte Konflikthilfen ==

# '''Hilfe A – Diagnose:''' Schaue zuerst mit <code>git status</code> 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.

{{BR}}
= 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.

[[Datei:Git branches merge.svg|500px|rahmenlos|center]]

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

{{BR}}
== Konflikt auflösen ==

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

<pre>
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
</pre>

'''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 <code>git merge --abort</code> den Mergeversuch abbrechen. Benutze diesen Befehl nur im Übungsrepository und beachte, dass ungesicherte Änderungen einen sicheren Abbruch erschweren können.

{{BR}}
== Visualisierte Ergebnisse ==

{| class="wikitable"
! 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.

{{BR}}
== 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.

{{BR}}
= Vertiefung: Teamregeln für gute Softwarequalität =

[[Datei:Git operations.svg|400px|rahmenlos|center]]

{| class="wikitable"
! 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.

{{BR}}
= Interaktive Aufgaben =

{{BR}}
== Quiz: Teste Dein Wissen ==

{{MC}}

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

{{E}}
<br>

{{MC}}

'''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)

{{E}}
<br>

{{MC}}

'''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)

{{E}}
<br>

{{MC}}

'''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)

{{E}}
<br>

{{MC}}

'''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)

{{E}}
<br>

{{MC}}

'''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)

{{E}}
<br>

{{MC}}

'''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)

{{E}}
<br>

{{MC}}

'''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)

{{E}}
<br>

{{MC}}

'''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)

{{E}}
<br>

{{MC}}

'''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)

{{E}}
<br>

{{BR}}
== Memory ==

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

<div class="memo-quiz">
{|
|-
| 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
|}
{{E}}
<br>

{{BR}}
== Drag and Drop ==

Ordne die Befehle ihrer Funktion zu.

<div class="lueckentext-quiz">

{| class="wikitable"
! 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
|}

{{E}}
<br>

{{BR}}
== Kreuzworträtsel ==

<div class="kreuzwort-quiz">
{|
|-
| 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?
|}
{{E}}
<br>

{{BR}}
== LearningApps ==

<iframe> https://learningapps.org/index.php?s=Anwendungsentwicklung+und+Softwarequalität+Versionsverwaltung+im+Team+verwenden </iframe>

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

{{BR}}
== Lückentext ==

<quiz display=simple>
{'''Vervollständige den Text.'''<br>
|type="{}"}
Git ist ein { verteiltes } Versionsverwaltungssystem.
Mit git { status } prüfst Du den Arbeitszustand.
Der Befehl git { add } merkt Änderungen für einen Commit vor.
Mit git { commit } speicherst Du den vorgemerkten Stand.
Ein { Branch } ermöglicht parallele Entwicklung.
Mit git { switch } wechselst Du den Entwicklungszweig.
Ein git { diff } zeigt Unterschiede zwischen Dateiständen.
Bei einem { Review } werden Änderungen fachlich geprüft.
Ein Merge-{ Konflikt } erfordert eine Entscheidung über widersprüchliche Änderungen.
Nach einer Konfliktlösung müssen die Markierungen { entfernt } sein.
Automatisierte { Tests } können bekannte Fehlerfälle erkennen.
Für eine gute Teamentscheidung ist die fachliche { Begründung } entscheidend.
</quiz>

<br>

{{BR}}
= Basis-, Anwendungs- und Transferaufgaben mit Feedback =

{| class="wikitable"
! 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.

{{BR}}
= Offene Aufgaben =

{{BR}}
=== Leicht – Basis ===

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

{{BR}}
=== Standard – Anwendung ===

# [[Code-Review|Review schreiben]]: Formuliere ein Review zur Raumplanung mit einer positiven Beobachtung und einer begründeten Änderungsanforderung.
# [[Git#Branches|Änderungen vergleichen]]: Erstelle zwei unterschiedliche Commits in einem eigenen lokalen Feature-Branch und analysiere die Diffs.
# [[Merge|Merge-Konflikt dokumentieren]]: Wiederhole LAB_B und gestalte ein kurzes Bildschirmtutorial mit Diagnose, fachlicher Entscheidung und Konfliktlösung.
# [[Softwarequalität|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.

{{BR}}
=== Schwer – Transfer ===

# [[Softwarearchitektur|Moduländerung organisieren]]: Simuliere zwei parallele Änderungen an einer fiktiven Python-Anwendung und entwickle eine konfliktarme Branch-Strategie.
# [[Code-Review|Review-Richtlinie entwickeln]]: Gestalte eine eigene Checkliste für kleine Entwicklungsteams. Begründe die Bedeutung jedes Qualitätskriteriums.
# [[Softwaretest|Fehlerorientiertes Testen]]: Verändere die lokale Anwendung absichtlich so, dass ein Test fehlschlägt. Dokumentiere Fehlerursache, Diagnose, Korrektur und Testergebnis.
# [[Projektmanagement|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.

{{:Offene Aufgabe - MOOC erstellen}}

{{BR}}
= Lernkontrolle =

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

# [[Versionsverwaltung|Änderungsstrategie]]: Zwei Auszubildende entwickeln gleichzeitig neue Funktionen. Erkläre, welche Branch-Strategie Du wählen würdest und wie sie Risiken begrenzen kann.
# [[Code-Review|Freigabeentscheidung]]: Alle Tests bestehen, aber ein Reviewer entdeckt eine nicht geklärte Sicherheitsanforderung. Entscheide begründet über die Freigabe.
# [[Merge-Konflikt|Konfliktanalyse]]: Zwei Branches verändern dieselbe Konfiguration unterschiedlich. Entwickle eine Methode, um technische und fachliche Konflikte voneinander zu unterscheiden.
# [[Softwaretest|Testqualität]]: Beschreibe ein Beispiel, bei dem alle vorhandenen Tests bestehen, obwohl die Software eine wichtige Anforderung verletzt.
# [[Git|Fehlerdiagnose]]: Nach einem Merge meldet Git weiterhin unzusammengeführte Dateien. Erläutere einen geeigneten Diagnose- und Lösungsablauf.
# [[Softwarequalität|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.

{{BR}}
= Bewertungsraster =

{| class="wikitable"
! 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
|}

{{BR}}
= 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.

<br>
<br>

{{BR}}
= OERs zum Thema =

'''Wikipedia: Versionsverwaltung'''

<iframe> https://de.m.wikipedia.org/wiki/Versionsverwaltung </iframe>

'''Wikipedia: Git'''

<iframe> https://de.m.wikipedia.org/wiki/Git </iframe>

{{BR}}
== Fachlich geprüfte Informationsquellen ==

# [https://git-scm.com/book/de/v2/Git-Branching-Einfaches-Branching-und-Merging Pro Git – Einfaches Branching und Merging]: Grundlagen zu Branches, Merges und Konflikten.
# [https://git-scm.com/docs/git-status Offizielle Git-Dokumentation – Status]: Arbeitsverzeichnis und unzusammengeführte Dateien.
# [https://git-scm.com/docs/git-diff Offizielle Git-Dokumentation – Diff]: Änderungen vergleichen.
# [https://git-scm.com/docs/git-switch Offizielle Git-Dokumentation – Switch]: Branches erstellen und wechseln.
# [https://git-scm.com/docs/git-merge Offizielle Git-Dokumentation – Merge]: Zusammenführen und Konflikte bearbeiten.
# [https://docs.github.com/de/pull-requests/how-tos/review-pull-requests GitHub-Dokumentation – Pull-Request-Reviews]: Kommentare und Freigaben im Team.
# [https://www.atlassian.com/de/git/tutorials/using-branches/merge-conflicts Atlassian – Merge-Konflikte]: Ergänzende technische Erklärung.

{{BR}}
== Mediennachweise und Rechte ==

'''Geprüfte Wikimedia-Commons-Medien:'''

# [https://commons.wikimedia.org/wiki/File:Git_operations.svg Git operations.svg]: Daniel Kinzler, CC BY 3.0.
# [https://commons.wikimedia.org/wiki/File:Git_branches_fork.svg Git branches fork.svg]: Bunyk, CC BY-SA 4.0.
# [https://commons.wikimedia.org/wiki/File:Git_branches_two_forks_and_merge.svg Git branches two forks and merge.svg]: Bunyk, CC BY-SA 4.0.
# [https://commons.wikimedia.org/wiki/File:Git_branches_merge.svg Git branches merge.svg]: Bunyk, CC BY-SA 4.0.
# [https://commons.wikimedia.org/wiki/File:Basic_git_branching_workflow_(GitLab).svg Basic git branching workflow]: TheresNoTime, CC BY-SA 4.0.
# [https://commons.wikimedia.org/wiki/File:Git_Foundations_-_Commit.webm Git Foundations – Commit]: GitHub, CC BY 3.0.
# [https://commons.wikimedia.org/wiki/File:Git_Foundations_-_Diff.webm Git Foundations – Diff]: GitHub, CC BY 3.0.
# [https://commons.wikimedia.org/wiki/File:Git_Foundations_-_Merge.webm 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.

{{BR}}
= Verknüpfte Lernbereiche =

{| align=center
{{:D-Tab}}
'''[[Anwendungsentwicklung und Softwarequalität]]'''
# [[Versionsverwaltung]]
# [[Git]]
# [[Repository]]
# [[Commit]]
# [[Branch]]
# [[Merge]]
# [[Merge-Konflikt]]
# [[Code-Review]]
# [[Softwaretest]]
# [[Softwarequalität]]
# [[Continuous Integration]]
# [[Softwareentwicklung]]
|}

[[Kategorie:Informatik]]
[[Kategorie:Anwendungsentwicklung]]
[[Kategorie:Softwarequalität]]
[[Kategorie:Versionsverwaltung]]
[[Kategorie:Git]]
[[Kategorie:Softwareentwicklung]]
[[Kategorie:Ausbildung]]
[[Kategorie:Fachinformatiker]]
[[Kategorie:Interaktive Lernkurse]]

{{BR}}
= aiMOOC-Projekte =
[[Kategorie:AI_MOOC]] [[Kategorie:GPT aiMOOC]]
{{MT}}

Anwendungsentwicklung und Softwarequalität – Versionsverwaltung im Team verwenden - Versionsgeschichte

Glanz: aiMOOC über GPT aiMOOC Action erstellt