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

Git und Versionskontrolle für KI-gestützte Projekte

QR-Code

Einleitung

Zielgruppe: Auszubildende im 1. oder 2. Ausbildungsjahr. Voraussetzung: Dateien und Maßeinheiten unterscheiden können; Programmierkenntnisse sind nicht erforderlich. Zeit: etwa vier bis sechs Lerneinheiten. Du benötigst einen Rechner mit lokal installierter Git-Software und einen Texteditor; optional Python, aber kein bezahltes KI-Konto, kein GitHub-Zugang und keine dauerhafte Internetverbindung.

Lernprodukt: Du erstellst ein lokales Repository für eine Messdaten-App, die ausschließlich synthetische Werte eines ungefährlichen Lehrbauteils anzeigt. Du verwendest einen eigenen Branch, prüfst einen Diff, löst einen absichtlich erzeugten Konflikt und stellst einen alten Dateistand wieder her. Am Ende erklärst du anhand von Belegen, warum du jede Änderung vorgenommen hast. Es gibt keine Verbindung zu realer Maschinensteuerung und keine technische Sicherheitsfreigabe.

Bekannte Grundlage aktivieren: Öffne die bereits vorhandene MOOCwiki-Lerneinheit und sammle drei Begriffe, die du schon kennst. Der Inhalt dieser Seite ließ sich bei der Recherche nicht abrufen und wird daher hier nicht behauptet. Überlege selbst: Weshalb sind Dateien namens app_neu.py, app_final.py und app_wirklich_final.py eine schlechte langfristige Änderungsdokumentation? Wie erkennst du, wer welche Entscheidung wann getroffen hat?

Am Ende kannst du: Repository, Arbeitsverzeichnis und Index unterscheiden; einen gut benannten Commit erzeugen; geänderte Textzeilen mit Diff erklären; eine Feature-Arbeit isolieren; einen Merge-Konflikt anhand einer Anforderung lösen; mit restore eine Datei gezielt zurücksetzen; eine KI-Empfehlung kritisch kontrollieren. Du lernst zuerst Begriffe, erprobst danach angeleitete Schritte und bearbeitest schließlich einen eigenständigen Transferfall.

Repository und Commits als Projektgedächtnis

Ordner, Index und Historie

Ein Repository ist ein Projekt, dessen Versionen Git verwaltet. Git führt eine Historie der verfolgten Dateien; im versteckten Unterordner .git liegen zugehörige Verwaltungsinformationen. Die drei wichtigsten Bereiche unterscheiden sich:

Bereich	Was liegt hier?	Prüfkommando oder Handlung
Arbeitsverzeichnis	Dateien, die du gerade bearbeitest	git status
Index oder Staging-Bereich	Ausgewählte Änderungen für den nächsten Commit	git add und git diff --staged
Lokale Git-Historie	Verknüpfte gespeicherte Projektstände	git commit und git log

Merke: Ändern → mit Diff prüfen → mit git add auswählen → Auswahl kontrollieren → mit git commit speichern. Der Commit hält einen Projektzustand mit einer eindeutigen Kennung, Verbindungen zu Vorgängern und einer Nachricht fest. Die Kennung ist kein Beleg dafür, dass die enthaltenen Werte sachlich richtig sind. Beschreibe das Warum einer Änderung, etwa „Synthetische Anzeige um Einheit ergänzt“ statt „Update“.

Git arbeitet auch ohne Internet. Git bezeichnet das Versionskontrollsystem; GitHub ist nur ein möglicher externer Hostingdienst. Ein Remote ist eine Verbindung zu einem anderen Repository, die in diesem Kurs nicht benötigt wird. Ein Commit ersetzt weder eine unabhängige Datensicherung noch eine fachliche Qualitätsprüfung.

Bildquelle: Wikimedia Commons, G.prof, CC BY-SA 4.0, englisch beschriftet. Ohne Bild: Von deinem lokalen Ordner geht es über Auswahl und Commit zur Historie; erst freiwilliges Veröffentlichen würde einen externen Dienst betreffen.

Privatsphäre und lesbare Historie

Nie Zugangstokens, Passwörter, vertrauliche Betriebsdaten oder persönliche Lerndaten committen. Auch ein späteres Löschen aus der aktuellen Datei beseitigt nicht zuverlässig alle Spuren in früheren Commits. In .gitignore kannst du beispielsweise __pycache__/ und *.pyc für neue, nicht zu verfolgende Dateien eintragen. Bereits versionierte Dateien verschwinden dadurch nicht automatisch aus der Historie.

Verständnischeck: Du hast app.py verändert, aber noch kein git add ausgeführt. Ein Commit aus bereits vorgemerkten Dateien wird nicht automatisch deine gerade veränderte app.py aufnehmen. Prüfe, wo die Änderung liegt und ob sie in den nächsten Commit gehört.

Änderungen mit Diffs verstehen und prüfen

Vergleichen statt raten

Ein Diff stellt Unterschiede zweier Zustände gegenüber. Bei Textdateien kennzeichnen mit Minus beginnende Zeilen häufig entfernten und Pluszeilen neu eingefügten Text. Beispiel einer erfundenen Anzeigeschwelle:

- grenzwert_mm = 10.5
+ grenzwert_mm = 11.0

Das bedeutet nur: Im neueren verglichenen Text steht 11.0 statt 10.5. Die Einheit bleibt mm. Nicht bewiesen sind die fachliche Richtigkeit, eine Sicherheitsfreigabe oder das Bestehen eines Softwaretests. Eine Differenz von 0.5 mm kann für unsere reine Bildschirmanzeige simuliert werden; es gibt keine Prüfung realer Bauteile.

Befehl	Bedeutung
git diff	Vergleich nicht vorgemerkter Arbeitsänderungen mit dem Index
git diff --staged	Vergleich der vorgemerkten Auswahl mit dem letzten Commit
git diff main..feature/grenzwert	Vergleich der aktuellen Endstände dieser zwei Branches
git show	Einen Commit einschließlich seiner Änderung ansehen

Lies bei jedem Diff Dateiname, minus- und plusmarkierte Zeilen sowie den Kontext. Erläutere danach drei Ebenen: Beobachtung (welcher Text wechselt?), Bedeutung (welches Verhalten könnte wechseln?) und Bewertung (welche Tests und Gründe sprechen dafür oder dagegen?). Dass ein KI-System die Änderung vorgeschlagen hat, ist für keine dieser drei Ebenen ein hinreichender Beleg.

KI-Vorschlag als Prüffall

Eine simulierte KI schlägt vor, messwert_mm in messwert umzubenennen und die Ausgabe von mm zu entfernen. Fachlich kann dies eine relevante Information über die Maßeinheit verlieren lassen. Ein prüfbarer Review würde beide Fundstellen im Diff markieren, die CSV-Spaltenüberschrift mit der Python-Ausleselogik vergleichen und die sichtbare Einheit in der Ausgabe erhalten. Entscheide erst nach dieser Kontrolle, ob du den Vorschlag annimmst, nachbesserst oder verwirfst. Schreibe einen kurzen Kommentar, der auch ohne KI-Chat verständlich bleibt.

Ergänzendes Video: „Lerne Git in 60 Minuten | Git Tutorial Deutsch“, Mit Mario, 2022; das Video beschreibt Commits, Diff, Restore und Branch/Merge. Videoquelle. Die Medienmetadaten waren auffindbar, die unmittelbare Wiedergabe konnte nicht unabhängig bestätigt werden. Offline-Alternative: Nutze die Tabelle und das vollständig ausgeschriebene Praxisprojekt.

Branches und Konflikte nachvollziehbar lösen

Parallel entwickeln

Ein Branch ist ein Name, der auf einen Commit zeigt und bei neuen Commits mitwandert. Der Hauptzweig main kann einen bewährten Stand halten; der Zweig feature/grenzwert ermöglicht ein Experiment, ohne die Hauptlinie sofort zu ändern. Typische Befehle sind git switch -c feature/grenzwert für neuen Branch, git switch main für den Wechsel und git branch für eine Übersicht. Prüfe vorher git status: Uncommittete Änderungen können beim Wechsel Schwierigkeiten verursachen oder mitgenommen werden.

Bildquelle: Wikimedia Commons, Elaine Cristina Meirelles, CC BY-SA 4.0; portugiesische Grafik. Ohne Bild: Nach einer Abzweigung können main und feature/grenzwert an verschiedenen Commits stehen.

Bildquelle: Wikimedia Commons, Autor laut Dateiseite „Self“, gemeinfrei; historische englische Darstellung. Ohne Bild: Die sichtbaren Linien entsprechen Beziehungen zwischen Commits und parallelen Arbeiten.

Merge und Entscheidung beim Konflikt

Mit git merge feature/grenzwert integrierst du auf dem gerade ausgewählten Branch die Entwicklung des angegebenen Branches. Nicht überlappende Änderungen lassen sich oft automatisch integrieren. Wenn zwei Branches denselben Abschnitt inkompatibel ändern, kann Git den Merge anhalten. In der betroffenen Datei erscheinen Konfliktmarker: ein beginnender Block für die aktuelle Variante, eine Trennzeile aus Gleichheitszeichen und ein endender Block für die andere Variante. Die erste Alternative lautet in unserem Lehrfall „Anzeige: Kompakt“, die zweite „Anzeige: Klartext“.

Auflösung: Betrachte beide Varianten, lege die Anforderung fest („Beide Darstellungsarten sollen dokumentiert werden“), ersetze den gesamten Konfliktblock durch Anzeige: Kompakt und Klartext, entferne die Marker und prüfe die Datei. Abschließend git add README.md und git commit -m "Anzeigekonflikt fachlich geloest". Kontrolliere mit git status, dass keine ungelösten Konflikte vorliegen. Eine mögliche Fehlentscheidung wäre, die Klartextanforderung kommentarlos wegzulassen. Begründe, was dadurch verloren ginge.

Mit git merge --abort kann ein noch laufender Merge abgebrochen werden. Bei zuvor uncommitteten Änderungen kann der ursprüngliche Zustand in bestimmten Fällen nicht sauber rekonstruiert werden; deshalb den Arbeitsbaum vorher kontrollieren.

Ergänzendes Video: „GIT Branch & Merge kurz erklärt“, Webdesign mit Eric Maechler, 2024. Videoquelle. Metadaten auffindbar, aktuelle Wiedergabemöglichkeit nicht unabhängig bestätigt. Offline-Alternative: Verwende die Konfliktbeschreibung und den praktischen Konfliktversuch im nächsten Kapitel.

Geführte Praxis: lokale App mit erfundenen Messwerten

Den ersten Stand erzeugen

Modellfall: Eine lokale Text-App zeigt drei erfundene Messwerte eines ungefährlichen Lehrbauteils. Sie verarbeitet nur eine Datei; es gibt keine Sensoranbindung, kein Urteil über reale Bauteile und keine Maschinensteuerung. Lege in einem Ordner messdaten-lehrprojekt vier Dateien mit diesen genauen Beispieldaten an.

README.md:

Lehrprojekt: synthetische Messdaten
Anzeige: Rohwerte
Einheit: mm
Nur Simulation, keine reale Bauteilfreigabe.

messdaten.csv:

bauteil_id,messwert_mm
L001,10.2
L002,10.8
L003,10.5

app.py (achte auf Einrückungen):

import csv
with open("messdaten.csv", encoding="utf-8", newline="") as datei:
    for zeile in csv.DictReader(datei):
        wert = float(zeile["messwert_mm"])
        print(zeile["bauteil_id"], wert, "mm")

.gitignore:

__pycache__/
*.pyc
.venv/

Öffne ein Terminal in diesem Ordner. Gib jeden folgenden Befehl separat ein:

git init -b main
git config user.name "Lernprojekt"
git config user.email "lernprojekt@example.invalid"
git status
git add README.md messdaten.csv app.py .gitignore
git diff --staged
git commit -m "Erste synthetische Messdatenanzeige"
git log --oneline

Dies sind lokal gesetzte synthetische Git-Identitätswerte. Ein kostenloser Git-Client genügt. Teste optional mit python app.py oder python3 app.py: Die Ausgabe soll die Kennungen L001, L002, L003 sowie 10.2 mm, 10.8 mm, 10.5 mm enthalten. Ohne Python beschreibst du erwartete Ergebnisse auf Papier; die Git-Aufgaben bleiben vollständig ausführbar.

Prüffragen: Wieso zeigt git status direkt nach dem Commit normalerweise keine zu speichernden Änderungen? Was hat git add ausgewählt? Welche Dateien gehören tatsächlich zum dokumentierten Stand?

Branch und Diff des Anzeigeexperiments

Prüfe git status und erzeuge den Entwicklungszweig:

git switch -c feature/grenzwert

Ersetze nur in diesem Branch die app.py durch:

import csv
grenzwert_mm = 10.5
with open("messdaten.csv", encoding="utf-8", newline="") as datei:
    for zeile in csv.DictReader(datei):
        wert = float(zeile["messwert_mm"])
        anzeige = "oberhalb" if wert > grenzwert_mm else "nicht oberhalb"
        print(zeile["bauteil_id"], wert, "mm", anzeige)

Prüfe mit git diff vor dem Vormerken; danach:

git add app.py
git diff --staged
git commit -m "Anzeigegrenze fuer fiktive Werte"
git log --oneline --graph --all

Die fiktive Ausgabe soll L002 als „oberhalb“ und L001 sowie L003 als „nicht oberhalb“ markieren. Das sind ausschließlich Textlabels für den Unterricht. Erkläre den neuen Grenzwert, den Zahlenvergleich und die in mm bleibende Einheit. Wechsel zurück:

git switch main

Ergänze in README.md die Zeile „Datensatz: nur fiktive Werte“ und committe sie auf main. Führe git merge feature/grenzwert aus. Beide Entwicklungen betreffen hier unterschiedliche Dateien und lassen sich daher in der Regel ohne Konflikt integrieren. Prüfe anschließend app.py und README.md.

Einen echten Konflikt simulieren

Für diese Übung enthält README.md auf main weiterhin die Zeile „Anzeige: Rohwerte“.

Lege per git switch -c versuch/anzeige einen zweiten Branch an. Ersetze in README.md „Anzeige: Rohwerte“ durch „Anzeige: Klartext“. Speichere mit git add README.md und einem aussagekräftigen git commit.
Wechsle mit git switch main zurück. Ersetze dort dieselbe ursprüngliche Zeile durch „Anzeige: Kompakt“ und committe die Änderung.
Führe git merge versuch/anzeige aus. Beobachte den Konflikt mit git status und lies die beiden markierten Varianten.
Ersetze den Konfliktblock durch eine einzige Zeile „Anzeige: Kompakt und Klartext“, entferne alle Konfliktmarker, speichere die Datei und schließe mit git add README.md sowie git commit -m "Anzeigekonflikt fachlich geloest" ab.

Pflichtprüfung: Zeige einen konfliktfreien git status; gib die finale Zeile an; erkläre, warum die automatische Auswahl nur einer Variante eine der beiden Anforderungen verlieren könnte. Begründe ausdrücklich den Fehlerfall „Die Klartext-Information wird kommentarlos verworfen“.

Restore ohne Verlust der Historie

Öffne messdaten.csv und füge testweise folgende vierte Zeile hinzu:

L004,99.9

Prüfe git diff -- messdaten.csv. Die neue Zeile ist weder ein realer Messwert noch eine Freigabe. Falls du die noch nicht vorgemerkte Änderung verwerfen willst, führe Folgendes aus:

git restore -- messdaten.csv

Vorsicht: Dieser Befehl ersetzt in der Regel die Datei im Arbeitsverzeichnis durch die Fassung aus dem Index und kann nicht anderweitig gesicherte Bearbeitungen verlieren lassen. Er stellt nicht automatisch einen beliebigen alten Commit wieder her. Belege mit git status und der Datei, dass L004 wieder fehlt.

Einen bestimmten älteren Stand zurückholen: Nutze git log --oneline -- app.py, um die Kennung des ersten App-Commits zu finden. Für einen Blick ohne Änderung verwende git show KENNUNG:app.py; ersetze das Wort KENNUNG durch die echte Kennung deines lokalen Projekts. Wenn du tatsächlich auf die frühere Fassung wechseln willst, sichere vorher uncommittete Änderungen an app.py und führe aus:

git restore --source=KENNUNG -- app.py
git diff -- app.py

Teste und beurteile den wiederhergestellten Dateiinhalt. Mit git add app.py und git commit -m "Alte Anzeige als neuen Stand gesichert" dokumentierst du die Rückkehr als neuen Commit, ohne ältere Commits zu löschen. Bei gemeinsam genutzten Branches kann git revert für das rückwirkende Aufheben eines schon geteilten Commits passender sein als das Umschreiben einer Historie. Das unterscheiden wir vom einfachen Dateirestore.

Abgabe: Lokales Repository samt feature/grenzwert, aussagekräftige Commits, dokumentierter Diff, behobener README-Konflikt und Vorher-Nachher-Nachweis für restore. Ein Textprotokoll genügt; keine Screenshots oder personenbezogenen Daten sind notwendig.

KI-gestützte Entwicklung: Wissen aus Versionen gewinnen

Änderungsvorschläge kontrollieren

Die Regel lautet Vorschlag → Diff → Begründung → lokaler Test → Entscheidung → Commit. Ein KI-Assistent kann Vorschläge produzieren, aber er übernimmt keine Verantwortung für die Richtigkeit eines Ergebnisses. Ohne Online-KI kannst du die vorgegebenen Übungsänderungen als simulierte KI-Vorschläge behandeln und denselben Prüfablauf einsetzen.

Lege protokoll.md im Repository an. Halte zu jeder wesentlichen Änderung sechs Angaben fest: Zweck, veränderte Dateien, beobachteter Diff, erwartete Auswirkung, Testergebnis und Entscheidung. Der Verlauf bewahrt Dateistände; das Protokoll macht die Gründe verständlich. So wird Versionierung eine nachhaltige Wissensgrundlage statt einer Folge rätselhafter Dateinamen. Ein Commit beweist jedoch keine vollständige Dokumentation und keine Wahrheit der gespeicherten Messwerte.

Sicherheit, Herkunft und Grenzen

NIST AI 600-1 (Juli 2024) gibt Empfehlungen zum freiwilligen Risikomanagement generativer KI. Das MCP-Dokument „Security Best Practices“ zur Spezifikation vom 28.07.2026 behandelt unter anderem Berechtigungsgrenzen und Tokenrisiken. Beide Quellen sind Hintergrund für verantwortungsvolle Entscheidungen, keine Anleitung zur Git-Bedienung und keine Zertifizierung unseres Modellfalls. Unsere didaktische Übertragung: Rechte minimieren, keine Zugangsdaten im Repository, jede Änderung lokal prüfen und keine ungeprüften KI-Ausgaben übernehmen.

Drei verbindliche Leistungskriterien: (A) Einen Diff mit Vorher-Nachher-Text, Einheit und möglicher Wirkung erklären. (B) Den Konflikt durch eine fachlich begründete Endfassung ohne Marker lösen und eine falsche Alternative diskutieren. (C) Einen Dateistand mit dem passenden restore-Befehl wiederherstellen und den nachweisbaren Zustand sowie verbleibende Historie erläutern.

Vertiefung: In größeren Teams ergänzen Tests, Reviews, dokumentierte Abnahmen, Tags und geeignete Branchregeln die persönliche Prüfung. Ein kryptographischer Bezeichner identifiziert einen gespeicherten Git-Stand; er bestätigt nicht die fachliche Zuverlässigkeit der Inhalte. Keine reale Maschine anschließen, keine Freigabeentscheidung für Bauteile simulieren, die mit realer Sicherheit verwechselt werden könnte.

Interaktive Aufgaben

Quiz: Fachwissen anwenden

Beantworte zehn Fragen. Die automatische Rückmeldung erfolgt über die Quizfunktion. Die nachgeschalteten Selbstprüfhinweise verraten keine einzelne Lösung vorab.

Was beschreibt ein lokales Repository? (Ein Projekt mit verfolgten Dateiständen und ihrer Git-Historie) (!Ein Messgerät mit automatischer Sicherheitsprüfung) (!Ein kostenloses Zertifikat für alle Codeänderungen) (!Eine zwingend online gehostete Software)

Selbstprüfhinweis: Prüfe den Unterschied zwischen Projektverlauf und Messverfahren.

Was geschieht bei git add app.py? (Die aktuelle Dateifassung wird im Index für den nächsten Commit vorgemerkt) (!Die Datei wird automatisch als fehlerfrei zertifiziert) (!Der Branch wird ohne Commit gelöscht) (!Alle Daten werden an einen Cloudanbieter geschickt)

Selbstprüfhinweis: Beachte die Station zwischen Arbeitsdatei und Historie.

Was zeigt git diff normalerweise? (Nicht vorgemerkte Arbeitsänderungen im Vergleich zum Index) (!Nur eine Liste aller jemals erzeugten Passwörter) (!Eine automatische Richtigkeitsprüfung der Messwerte) (!Einen garantierten Sicherheitsnachweis)

Selbstprüfhinweis: Benutze die drei Git-Ebenen als Entscheidungshilfe.

Was folgt aus einer Pluszeile mit einer geänderten Anzeigeschwelle? (Der neue verglichene Textstand enthält diese Zeile) (!Jede damit berechnete Anzeige ist fachlich freigegeben) (!Der vorherige Projektstand wurde vernichtet) (!Jeder mögliche Test wurde erfolgreich ausgeführt)

Selbstprüfhinweis: Unterscheide Beobachtung, Wirkung und Freigabe.

Was ist ein Branch? (Ein benannter Verweis auf einen Entwicklungsstand) (!Eine verpflichtende Internetverbindung) (!Ein physischer Bauteilsensor) (!Ein automatisch erstellter Prüfbericht)

Selbstprüfhinweis: Denke an Namen und Commit-Verbindungen.

Wann ist ein Merge-Konflikt wahrscheinlich? (Zwei Branches ändern denselben Textabschnitt unterschiedlich) (!Ein Repository wird offline benutzt) (!Eine Datei heißt app.py) (!Ein Commit hat eine lesbare Nachricht)

Selbstprüfhinweis: Betrachte die Schwierigkeit, zwei widersprüchliche Wünsche zu vereinen.

Welche Handlung löst einen Konflikt fachlich sauber? (Beide Varianten prüfen und eine begründete Endfassung speichern) (!Immer die jüngste Datei ungeprüft auswählen) (!Alle Konfliktmarker als endgültigen Inhalt stehen lassen) (!Ohne Kontrolle die komplette Historie löschen)

Selbstprüfhinweis: Frage nach den Anforderungen hinter den Varianten.

Wofür ist git restore -- messdaten.csv im Übungsfall gedacht? (Nicht vorgemerkte Arbeitsänderungen an der Datei aus dem Index ersetzen) (!Den aktuellen Stand automatisch veröffentlichen) (!Eine vollständige Sicherheitsanalyse ausführen) (!Ein neues Pythonprogramm erzeugen)

Selbstprüfhinweis: Klär zuerst, wo die Änderung gerade gespeichert ist.

Wie wird ein KI-Codevorschlag nachvollziehbar? (Mit Diff, lokalem Test und dokumentierter eigener Begründung) (!Nur mit der Behauptung des Sprachmodells) (!Durch das Committen privater Passwörter) (!Durch Verzicht auf alle Änderungsnachrichten)

Selbstprüfhinweis: Suche einen reproduzierbaren Nachweis außerhalb des KI-Chats.

Wie dokumentierst du die Rückkehr zu einer älteren Dateiversion? (Du kannst sie als neuen Commit speichern und die alte Historie behalten) (!Du musst alle früheren Commits löschen) (!Git misst dann automatisch reale Bauteile) (!Der Restore bestätigt jede externe Sicherheitsnorm)

Selbstprüfhinweis: Die aktuelle Dateifassung und die vorhandene Geschichte sind nicht identisch.

Memory

Ordne die sechs Begriffe genau einer Erklärung zu.

Repository	Git-verwaltetes Projekt
Commit	Dokumentierter Projektstand
Branch	Benannter Entwicklungszeiger
Index	Vorgemerkte Änderungswahl
Diff	Textvergleich zwischen Zuständen
Restore	Gezielte Dateiwiederherstellung

Drag-and-Drop

Finde fünf passende Paare zwischen Handlung und fachlicher Wirkung.

Git-Handlung	Passende Wirkung
Arbeitsänderung vergleichen	Unvorgemerkten Textunterschied erkennen
Datei vormerken	Geprüften Inhalt für nächsten Commit auswählen
Commit erstellen	Einen beschrifteten Projektstand speichern
Branch wechseln	Einen anderen Entwicklungszeiger aktivieren
Konflikt abschließen	Gewählte Endfassung bestätigen und dokumentieren

Kreuzworträtsel

Löse alle sechs Einwortbegriffe anhand der Hinweise.

Branch	Benannter Zeiger in einer Git-Entwicklung
Commit	Gespeicherter und beschrifteter Projektstand
Index	Zwischenauswahl für den nächsten Commit
Merge	Zusammenführung von Entwicklungszweigen
Restore	Befehl zur Rückkehr zu einem Dateistand
Konflikt	Widerspruch zweier Änderungen in demselben Textbereich

LearningApps

Suche passende Übungen zu Git und Versionskontrolle. Fremde LearningApps-Inhalte sind nicht redaktionell geprüft; bei fehlender Verbindung verwende das Memory und die Zuordnung direkt darüber.

Lückentext

Ergänze jeden Satz mit einem Fachwort. Jede Satzlücke prüft eine eigenständige Idee.

Ein Git-verwaltetes Projekt ist ein

.

Der Vormerkbereich für Änderungen heißt

.

Ein gespeicherter Projektzustand heißt

.

Ein benannter Entwicklungszweig heißt

.

Ein Vergleich zweier Textstände heißt

.

Zweige lassen sich mit einem

zusammenführen.

Unvereinbare Bearbeitungen können einen

auslösen.

Nicht vorgemerkte Dateiänderungen werden mit git

zurückgesetzt.

Den überprüfbaren Effekt einer Änderung untersucht ein

.

Eine informative Commit-Nachricht sollte die Absicht

.

Offene Aufgaben

Leicht

Begriffslandkarte: Zeichne die drei Ebenen Arbeitsdatei, Index und Historie und beschreibe in ganzen Sätzen den Weg zur neuen Version.
Commits benennen: Ersetze die unklaren Nachrichten „Update“, „neu“ und „fertig“ durch drei konkrete Änderungserklärungen für die synthetische Messdaten-App.
Textänderung deuten: Stelle grenzwert_mm = 10.5 und grenzwert_mm = 11.0 gegenüber, markiere Vorher und Nachher und erkläre die Aussagegrenze des Diffs.
Branchgrafik verstehen: Zeichne zwei von einem Commit abzweigende Entwicklungen und erkläre, weshalb main und feature/grenzwert nicht immer denselben Stand enthalten.

Standard

Lokales Repository: Erzeuge alle vier Dateien des Modellfalls, initialisiere Git und dokumentiere den ersten Commit und git status mit rein synthetischen Angaben.
Feature prüfen: Bearbeite app.py auf feature/grenzwert, untersuche git diff und git diff --staged und teste die erwarteten Anzeigen für L001, L002 und L003.
Widerspruch vereinbaren: Führe den Konflikt „Anzeige: Kompakt“ gegen „Anzeige: Klartext“ herbei, löse ihn und begründe die finale README-Zeile.
Rücknahme zeigen: Füge die rein fiktive Zeile L004 hinzu, dokumentiere den Diff, stelle die CSV mit git restore zurück und prüfe das Resultat.

Schwer

KI-Vorschlag prüfen: Bewerte die simulierte KI-Änderung mit entferntem mm, nenne konkrete Risiken und entwickle einen überprüfbaren Korrekturvorschlag.
Fehlerfall begründen: Untersuche, warum eine stillschweigende Auswahl nur einer Konfliktvariante Informationsverlust erzeugt, und formuliere ein menschliches Review-Verfahren.
Historischen Stand rekonstruieren: Ermittle einen alten Commit für app.py, verwende git restore --source mit seiner Kennung und begründe einen optionalen neuen Wiederherstellungs-Commit.
Versionierung als Wissen: Entwirf ein Richtliniendokument zu Branches, Reviews, vertraulichen Dateien, Tests und Commit-Protokollen für ein ausschließlich fiktives KI-Projekt.

Lernkontrolle

Diff fachlich erklären: Lege einen echten lokalen Vorher-Nachher-Diff aus dem Modellprojekt vor; erkläre jede geänderte Zeile, Einheit, mögliche Wirkung und Grenze der Aussage.
Konflikt sicher lösen: Zeige die zwei Varianten der Anzeige-Dokumentation, deine finale Zeile, den sauberen Git-Status und einen nachvollziehbaren fachlichen Grund.
Restore nachweisen: Dokumentiere die neue CSV-Testzeile vor der Rücknahme, das passende Kommando und den nachweisbaren früheren Inhalt nach der Rücknahme.
Fehlentscheidung diagnostizieren: Jemand führt restore ohne vorherige Prüfung aus und verliert ungespeicherte Änderungen. Erkläre Ursache, Auswirkungen und zwei vorbeugende Maßnahmen.
KI-Annahme kontrollieren: Plane einen Offline-Test einer vorgeschlagenen Änderung mit ausschließlich erfundenen Werten, bewerte Unsicherheit und begründe Annahme oder Ablehnung.
Transfer erklären: Zeige, wie Branch, Tests, Commit-Nachricht und Änderungsprotokoll späteres Verständnis fördern und weshalb keiner dieser Nachweise eine reale Sicherheitsfreigabe ersetzt.

Lernnachweis

Pflichtprodukt: Lokales Repository messdaten-lehrprojekt mit den synthetischen Daten, README.md, app.py, .gitignore, einem Branch feature/grenzwert und einem von dir erstellten protokoll.md. Nachweise: mindestens drei sinnvolle Commits, ein erklärter Diff, der bewusst erzeugte und gelöste Konflikt, ein dokumentierter restore und eine begründete Fehlentscheidung. Ein Textprotokoll der Git-Befehle ist ausreichend; ein Video, ein öffentlicher Account oder echte Messdaten sind nicht notwendig.

Kriterium	Mindestbeleg	Fachliche Vertiefung
Diff erklären	Geänderte Zeilen und mm-Einheit richtig zuordnen	Wirkung und Ungewissheit trennen
Konflikt lösen	Beide Varianten und markerfreie Endfassung mit sauberem Status	Einen plausiblen Fehlerfall mit Informationsverlust erklären
Alten Stand wiederherstellen	Datei vor und nach restore sowie gewählten Befehl belegen	Den Unterschied von Rücknahme und neu dokumentierter Wiederherstellung erläutern
Wissen sichern	Commits, Testnotizen und Entscheidungsgründe übergeben	Fremde können den Verlauf ohne Chatprotokoll nachvollziehen

Selbstbewertung: Kann eine andere Person A, B und C am lokalen Stand reproduzieren? Fehlt ein Nachweis, ergänze ihn vor der Abgabe. Keine persönlichen Schülerdaten, Zugangsdaten oder vertraulichen Informationen einreichen. Unabhängiges Bildungsangebot, keine offizielle Zertifizierung durch Liebherr, IHK oder andere Unternehmen.

OER und Wikipedia

Recherche- und Bearbeitungsstand: 22.10.2026. Die eigene Git-Installation kann eine andere Versionsnummer haben; git --version zeigt sie. Quellen sind Erklärungsgrundlage und keine Sicherheitsfreigabe.

Git-Dokumentation: diff, englische Primärquelle, Handbuchstand Git 2.56.0 laut Versionsübersicht; definiert Vergleichsbereiche.
Git-Dokumentation: restore, englische Primärquelle, letzte dokumentierte Textänderung in der Versionsübersicht 2.55.0 (29.06.2026).
Git-Dokumentation: merge, englische Primärquelle zu Merge-Konflikten und deren Auflösung.
Pro Git, deutschsprachiges frei zugängliches Handbuch; Ausgabe am Abrufort kontrollieren.
NIST AI 600-1, Juli 2024, freiwilliges Risikomanagement-Profil generativer KI; nicht als Git-Standard ausgeben.
MCP Security Best Practices, Spezifikation 2026-07-28, für Berechtigungs- und Sicherheitsrisiken; nicht als industrielle Prüfzulassung verwenden.
Wikipedia: Git, nachprüfbarer Überblick, kein Ersatz für offizielle Befehlsdokumentation.
Vorhandene MOOCwiki-Grundlage, als Vorwissenslink angegeben; ihr Inhalt war bei der Vorbereitung technisch nicht einsehbar.

Medien mit Herkunft und Rechten:

Medium	Nachprüfbare Dateiseite	Urheberschaft	Rechte oder Hinweis
GitHub-workflow.png	Wikimedia Commons	G.prof	CC BY-SA 4.0, englische Grafik
Git branch.png	Wikimedia Commons	Elaine Cristina Meirelles	CC BY-SA 4.0, portugiesische Grafik
Git branches example.png	Wikimedia Commons	„Self“ laut Commons	Auf Dateiseite als gemeinfrei freigegeben, englisches Gitk-Beispiel
Git in 60 Minuten	YouTube-Videoeintrag	Mit Mario	Rechte beim Videokanal; deutsch; aktuelle direkte Abspielbarkeit nicht gesondert bestätigt
Branch und Merge	YouTube-Videoeintrag	Webdesign mit Eric Maechler	Rechte beim Videokanal; deutsch; aktuelle direkte Abspielbarkeit nicht gesondert bestätigt

Die genannten Commons-Dateiseiten, Lizenzhinweise und Urheberangaben wurden recherchiert. Die YouTube-Metadaten konnten gefunden, die aktuelle Wiedergabe aber nicht unabhängig getestet werden. Daher gibt es für jedes Medium eine vollständige Textalternative im Kurs. Es wurden keine thematisch unpassenden Audio- oder Animationsdateien aufgenommen; keine eigenen Medien erstellt. Lizenzhinweise der Urheber bleiben bei Weitergabe verbindlich.