chore: initial training material setup

2026-05-12 20:34:39 +02:00
commit 2314a14916
20 changed files with 1865 additions and 0 deletions
@@ -0,0 +1,7 @@
 .DS_Store
 Thumbs.db
 *.swp
 *.swo
 *~
 .vscode/
 .idea/
@@ -0,0 +1,108 @@
 # 📦 Modul 00 – Vorbereitung
 Bevor du mit Git arbeiten kannst, muss es installiert und eingerichtet sein. Dieses Modul zeigt dir wie.
 ---
 ## 1. Git installieren
 ### Windows
 Lade den Installer von [git-scm.com](https://git-scm.com/download/win) herunter und führe ihn aus. Die Standard-Einstellungen im Installer sind gut gewählt – du kannst einfach auf „Weiter" klicken.
 Nach der Installation öffnest du **Git Bash** (wird automatisch mitinstalliert).
 ### macOS
 **Option A – Xcode Command Line Tools** (kein Download nötig):
 ```bash
 xcode-select --install
 ```
 **Option B – Homebrew** (empfohlen, wenn Homebrew bereits installiert ist):
 ```bash
 brew install git
 ```
 ### Linux (Debian/Ubuntu)
 ```bash
 sudo apt update && sudo apt install git
 ```
 ### Linux (Fedora/RHEL)
 ```bash
 sudo dnf install git
 ```
 ---
 ## 2. Git-Version prüfen
 Öffne ein Terminal und gib ein:
 ```bash
 git --version
 ```
 ```text
 git version 2.43.0
 ```
 Wenn du eine Versionsnummer siehst, hat die Installation funktioniert. Die genaue Nummer kann bei dir abweichen – Hauptsache, Git antwortet.
 ---
 ## 3. Git konfigurieren
 Git muss deinen Namen und deine E-Mail-Adresse kennen, damit deine Commits korrekt zugeordnet werden. Diese Konfiguration machst du **einmalig** auf deinem Rechner:
 ```bash
 git config --global user.name "Vorname Nachname"
 git config --global user.email "name@example.com"
 git config --global init.defaultBranch main
 git config --global core.editor "nano"
 ```
 > **Tipp für Windows-Nutzer:** Ersetze `nano` durch `notepad` oder lass die Editor-Zeile weg – dann öffnet Git den Standard-Editor.
 ### Was bedeuten diese Einstellungen?
 | Einstellung | Bedeutung |
 |-------------|-----------|
 | `user.name` | Dein Name erscheint in jedem Commit |
 | `user.email` | Deine E-Mail wird dem Commit zugeordnet |
 | `init.defaultBranch main` | Neue Repos starten mit `main` statt `master` |
 | `core.editor` | Editor für Commit-Nachrichten |
 ---
 ## 4. Konfiguration prüfen
 ```bash
 git config --list
 ```
 ```text
 user.name=Vorname Nachname
 user.email=name@example.com
 init.defaultBranch=main
 core.editor=nano
 ```
 Du siehst möglicherweise noch weitere Einträge – das ist normal.
 ---
 ## ✅ Erfolgskriterien
 - [ ] `git --version` zeigt eine Versionsnummer
 - [ ] `git config --list` zeigt deinen Namen und deine E-Mail
 - [ ] Du kannst ein Terminal öffnen und Befehle eingeben
 ---
 **Weiter geht's mit:** [01 – Grundkonzepte](../01-grundkonzepte/README.md)
@@ -0,0 +1,90 @@
 # 💡 Modul 01 – Grundkonzepte
 Bevor du Git-Befehle tippst, lohnt es sich, das Konzept dahinter zu verstehen. Dieses Modul erklärt, wie Git Dateien verwaltet und was ein Commit wirklich ist.
 ---
 ## Das 3-Bereiche-Modell
 Git arbeitet mit drei Bereichen. Jede Datei befindet sich immer in genau einem davon:
 | Bereich | Deutsch | Was passiert hier? |
 |---------|---------|-------------------|
 | **Working Directory** | Arbeitsverzeichnis | Hier bearbeitest du deine Dateien normal |
 | **Staging Area** | Bereitstellungsbereich | Hier sammelst du Änderungen für den nächsten Commit |
 | **Repository** | Versionsdatenbank | Hier werden Commits dauerhaft gespeichert |
 ```mermaid
 flowchart LR
    WD[Working Directory\n📝 Dateien bearbeiten] -->|git add| SA[Staging Area\n📋 Änderungen vorbereiten]
    SA -->|git commit| REPO[Repository\n🗄️ Versionshistorie]
    REPO -->|git checkout| WD
 ```
 ### Der Weg einer Änderung
 1. Du änderst eine Datei im **Working Directory**
 2. Mit `git add` legst du die Änderung in die **Staging Area** – du entscheidest, *was* in den nächsten Commit kommt
 3. Mit `git commit` speicherst du alles aus der Staging Area als neuen **Commit** im Repository
 > **Warum gibt es eine Staging Area?**
 > Sie gibt dir die Kontrolle. Du kannst in 5 Dateien arbeiten, aber nur 2 davon in einem Commit zusammenfassen – weil sie thematisch zusammengehören.
 ---
 ## Was ist ein Commit?
 Ein Commit ist ein **unveränderlicher Snapshot** deines Projekts zu einem bestimmten Zeitpunkt. Stell dir Commits wie **Speicherstände in einem Videospiel** vor:
 - Du speicherst regelmäßig deinen Fortschritt
 - Du kannst jederzeit zu einem früheren Speicherstand zurückkehren
 - Jeder Speicherstand hat einen Zeitstempel und eine Beschreibung
 Jeder Commit enthält:
 - Einen eindeutigen **Hash** (z. B. `a3f9c12`) als ID
 - Den **Autor** und **Zeitstempel**
 - Eine **Commit-Nachricht** (von dir geschrieben)
 - Den **Snapshot** aller Dateien in diesem Moment
 - Eine Referenz auf den **vorherigen Commit** (den „Eltern-Commit")
 ---
 ## Lineare Commit-Historie
 Eine typische Projekthistorie sieht so aus – jeder Commit zeigt auf seinen Vorgänger:
 ```mermaid
 gitGraph
    commit id: "Projekt angelegt"
    commit id: "README hinzugefügt"
    commit id: "Erste Inhalte"
    commit id: "Tippfehler behoben"
    commit id: "Version 1.0 fertig"
 ```
 Der neueste Commit ist immer ganz rechts. Der Zeiger `HEAD` markiert, wo du dich gerade befindest.
 ---
 ## Wichtige Begriffe auf einen Blick
 | Begriff | Bedeutung |
 |---------|-----------|
 | `HEAD` | Zeiger auf den aktuellen Commit / Branch |
 | `main` | Standardname des Hauptbranches |
 | Hash | Eindeutige ID eines Commits (z. B. `a3f9c12`) |
 | Staging Area | Auch „Index" genannt |
 | Tracked | Datei ist Git bekannt |
 | Untracked | Datei ist Git noch nicht bekannt |
 ---
 ## ✅ Erfolgskriterien
 - [ ] Du kannst die drei Bereiche von Git nennen und erklären
 - [ ] Du weißt, was ein Commit ist und warum er unveränderlich ist
 - [ ] Du verstehst, warum es eine Staging Area gibt
 ---
 **Weiter geht's mit:** [02 – Erste Schritte](../02-erste-schritte/README.md)
@@ -0,0 +1,197 @@
 # 🚀 Modul 02 – Erste Schritte
 In diesem Modul legst du dein erstes Git-Repository an und machst deine ersten Commits. Du lernst die grundlegenden Befehle, die du täglich brauchst.
 ---
 ## Schritt 1 – Repository anlegen
 Wechsle in einen neuen Ordner und initialisiere ein Git-Repository:
 ```bash
 mkdir mein-projekt
 cd mein-projekt
 git init
 ```
 ```text
 Initialized empty Git repository in /pfad/zu/mein-projekt/.git/
 ```
 Git hat einen versteckten Ordner `.git/` angelegt. Dort speichert Git alles – lösche diesen Ordner nie manuell.
 ---
 ## Schritt 2 – Status prüfen
 ```bash
 git status
 ```
 ```text
 On branch main
 No commits yet
 nothing to commit (create/copy files and use "git add" to track)
 ```
 `git status` ist dein wichtigster Befehl. Er zeigt immer, was gerade los ist.
 ---
 ## Schritt 3 – Erste Datei anlegen
 Erstelle eine Datei:
 ```bash
 echo "# Mein Projekt" > README.md
 ```
 Prüfe den Status erneut:
 ```bash
 git status
 ```
 ```text
 On branch main
 No commits yet
 Untracked files:
  (use "git add <file>..." to include in what you will be committed)
        README.md
 nothing added to commit but untracked files present (use "git add" to track)
 ```
 `README.md` ist **untracked** – Git sieht sie, aber verfolgt sie noch nicht.
 ---
 ## Schritt 4 – Datei zur Staging Area hinzufügen
 ```bash
 git add README.md
 ```
 ```bash
 git status
 ```
 ```text
 On branch main
 No commits yet
 Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   README.md
 ```
 Die Datei ist jetzt **staged** – bereit für den nächsten Commit.
 > **Tipp:** Mit `git add .` fügst du alle geänderten Dateien im aktuellen Ordner hinzu.
 ---
 ## Schritt 5 – Ersten Commit erstellen
 ```bash
 git commit -m "chore: README hinzugefügt"
 ```
 ```text
 [main (root-commit) a3f9c12] chore: README hinzugefügt
 1 file changed, 1 insertion(+)
 create mode 100644 README.md
 ```
 Glückwunsch! Du hast deinen ersten Commit erstellt. Der Hash (`a3f9c12`) ist die eindeutige ID dieses Commits.
 ### Gute Commit-Nachrichten
 Eine gute Commit-Nachricht beschreibt, **warum** eine Änderung gemacht wurde, nicht nur was:
 | Schlecht ❌ | Gut ✅ |
 |------------|--------|
 | `änderungen` | `fix: Tippfehler in Einleitung behoben` |
 | `update` | `feat: Kontaktformular hinzugefügt` |
 | `asdf` | `docs: Installationsanleitung ergänzt` |
 ---
 ## Schritt 6 – Weitere Commits
 Füge mehr Inhalt hinzu und erstelle weitere Commits:
 ```bash
 echo "Dieses Projekt ist toll." >> README.md
 git add README.md
 git commit -m "docs: Beschreibung ergänzt"
 ```
 ```text
 [main b7e2f45] docs: Beschreibung ergänzt
 1 file changed, 1 insertion(+)
 ```
 ---
 ## Schritt 7 – Commit-Historie ansehen
 ```bash
 git log
 ```
 ```text
 commit b7e2f45abc123def456abc789def012abc345def (HEAD -> main)
 Author: Vorname Nachname <name@example.com>
 Date:   Mon May 12 10:30:00 2025 +0200
    docs: Beschreibung ergänzt
 commit a3f9c12def456abc789def012abc345def678abc
 Author: Vorname Nachname <name@example.com>
 Date:   Mon May 12 10:25:00 2025 +0200
    chore: README hinzugefügt
 ```
 Für eine kompaktere Ansicht:
 ```bash
 git log --oneline
 ```
 ```text
 b7e2f45 docs: Beschreibung ergänzt
 a3f9c12 chore: README hinzugefügt
 ```
 > `HEAD -> main` zeigt dir, auf welchem Branch und Commit du gerade bist.
 ---
 ## Befehlsübersicht
 | Befehl | Was er macht |
 |--------|-------------|
 | `git init` | Neues Repository anlegen |
 | `git status` | Aktuellen Zustand anzeigen |
 | `git add <datei>` | Datei zur Staging Area hinzufügen |
 | `git add .` | Alle Änderungen stagen |
 | `git commit -m "..."` | Commit mit Nachricht erstellen |
 | `git log` | Vollständige Commit-Historie |
 | `git log --oneline` | Kompakte Commit-Historie |
 ---
 ## 📝 Jetzt bist du dran!
 Weiter zur [Aufgabe](aufgabe.md) – dort übst du alles selbst.
 ---
 **Weiter geht's mit:** [03 – Branches](../03-branches/README.md)
@@ -0,0 +1,57 @@
 # 📝 Aufgabe 02 – Erste Schritte
 Jetzt bist du dran! Arbeite die folgenden Schritte selbst durch, ohne in die [Lösung](../loesungen/02-loesung.md) zu schauen.
 ---
 ## Aufgabe
 ### 1. Neuen Ordner anlegen und initialisieren
 Erstelle einen Ordner namens `meine-notizen` und initialisiere darin ein Git-Repository.
 ### 2. Erste Datei anlegen
 Erstelle im Ordner eine Datei namens `notizen.md`. Öffne sie in einem Texteditor und schreibe **drei Zeilen** hinein:
 ```text
 Zeile 1: Git ist ein Versionskontrollsystem.
 Zeile 2: Commits sind Snapshots meines Projekts.
 Zeile 3: Die Staging Area bereitet Commits vor.
 ```
 ### 3. Drei separate Commits erstellen
 Erstelle **nicht** einen einzigen Commit mit allen drei Zeilen! Mache stattdessen:
 - **Commit 1:** Nur Zeile 1 ist in `notizen.md`, diese stagen und committen
 - **Commit 2:** Zeile 2 hinzufügen, stagen und committen
 - **Commit 3:** Zeile 3 hinzufügen, stagen und committen
 > **Hinweis:** Du musst die Datei nach jeder Bearbeitung erneut mit `git add` stagen.
 ### 4. Commit-Historie prüfen
 Führe am Ende folgenden Befehl aus:
 ```bash
 git log --oneline
 ```
 Du solltest drei Commits sehen. Vergleiche dein Ergebnis mit der [Lösung](../loesungen/02-loesung.md).
 ---
 ## Hilfreiche Datei
 Im Ordner liegt eine Datei [beispiel.txt](beispiel.txt) – schau rein, wenn du ein Beispiel für den Ablauf brauchst.
 ---
 ## ✅ Erfolgskriterien
 - [ ] Der Ordner `meine-notizen` existiert und enthält einen `.git/`-Ordner
 - [ ] `notizen.md` enthält drei Zeilen Text
 - [ ] `git log --oneline` zeigt genau **drei Commits**
 - [ ] Jeder Commit hat eine sinnvolle Nachricht
 - [ ] `git status` zeigt am Ende `nothing to commit, working tree clean`
@@ -0,0 +1,7 @@
 Dies ist eine Beispieldatei für Modul 02.
 Sie zeigt, wie eine einfache Textdatei aussehen kann,
 die du mit Git versionieren möchtest.
 Du kannst diese Datei verändern und die Änderungen
 mit git add und git commit speichern.
@@ -0,0 +1,130 @@
 # 🌿 Modul 03 – Branches
 Branches sind das Herzstück von Git. Sie ermöglichen es dir, an neuen Features zu arbeiten, ohne den stabilen Hauptcode zu verändern.
 ---
 ## Was ist ein Branch?
 Ein Branch ist ein **beweglicher Zeiger** auf einen Commit. Wenn du auf einem Branch einen neuen Commit machst, rückt der Zeiger automatisch vorwärts.
 Das klingt abstrakt – stell dir vor:
 - `main` ist dein **veröffentlichter Stand** (funktioniert immer)
 - Du erstellst einen Branch `feature/begruessung` für neue Arbeit
 - Dort probierst du aus, änderst, brichst ab – `main` bleibt unberührt
 - Wenn du fertig bist, **mergst** du den Feature-Branch zurück in `main`
 ---
 ## Branch-Workflow visualisiert
 ```mermaid
 gitGraph
    commit id: "Projekt start"
    commit id: "README fertig"
    branch feature/begruessung
    checkout feature/begruessung
    commit id: "hallo.txt angelegt"
    commit id: "Begrüßung verbessert"
    checkout main
    merge feature/begruessung id: "Feature gemergt"
 ```
 Auf `main` hat sich nichts verändert, solange du auf `feature/begruessung` gearbeitet hast. Erst beim Merge kommen die Änderungen zusammen.
 ---
 ## Befehle im Überblick
 ### Branch anlegen und wechseln
 ```bash
 git branch feature/begruessung
 git switch feature/begruessung
 ```
 Oder in einem Schritt:
 ```bash
 git switch -c feature/begruessung
 ```
 ### Aktuellen Branch anzeigen
 ```bash
 git branch
 ```
 ```text
 * feature/begruessung
  main
 ```
 Das Sternchen `*` zeigt, auf welchem Branch du gerade bist.
 ### Alle Branches anzeigen (auch remote)
 ```bash
 git branch -a
 ```
 ### Zurück zu main wechseln
 ```bash
 git switch main
 ```
 ### Branch mergen
 ```bash
 git switch main
 git merge feature/begruessung
 ```
 ```text
 Updating a3f9c12..d4e5f67
 Fast-forward
 hallo.txt | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 hallo.txt
 ```
 ### Branch löschen (nach dem Merge)
 ```bash
 git branch -d feature/begruessung
 ```
 ---
 ## Unterschied sehen
 Bevor du mergst, kannst du sehen, was sich auf dem Feature-Branch geändert hat:
 ```bash
 git diff main..feature/begruessung
 ```
 Oder alle Branches in der Übersicht:
 ```bash
 git log --all --oneline --graph
 ```
 ```text
 * d4e5f67 (feature/begruessung) Begrüßung verbessert
 * c3d4e56 hallo.txt angelegt
 * b7e2f45 (HEAD -> main) README fertig
 * a3f9c12 Projekt start
 ```
 ---
 ## 📝 Jetzt bist du dran!
 Weiter zur [Aufgabe](aufgabe.md).
 ---
 **Weiter geht's mit:** [04 – Merge & Konflikte](../04-merge-und-konflikte/README.md)
@@ -0,0 +1,85 @@
 # 📝 Aufgabe 03 – Branches
 Arbeite die folgenden Schritte durch. Schau erst in die [Lösung](../loesungen/03-loesung.md), wenn du nicht weiterkommst.
 ---
 ## Aufgabe
 ### 1. Ausgangssituation
 Nimm das Repo aus Aufgabe 02 (`meine-notizen`) oder lege ein frisches Repo an:
 ```bash
 mkdir branch-uebung
 cd branch-uebung
 git init
 echo "# Branch-Übung" > README.md
 git add README.md
 git commit -m "chore: Projekt angelegt"
 ```
 ### 2. Feature-Branch anlegen
 Erstelle einen neuen Branch namens `feature/begruessung` und wechsle direkt dorthin:
 ```bash
 git switch -c feature/begruessung
 ```
 ### 3. Neue Datei auf dem Feature-Branch
 Erstelle eine Datei `hallo.txt` mit folgendem Inhalt:
 ```text
 Hallo, Welt!
 Willkommen in meinem ersten Git-Projekt.
 ```
 Füge die Datei hinzu und committe sie.
 ### 4. Zurück zu main
 Wechsle zurück zu `main`:
 ```bash
 git switch main
 ```
 Schau dir den Ordner an – `hallo.txt` ist **nicht da**! Das ist korrekt: auf `main` existiert sie noch nicht.
 ### 5. Unterschied sehen
 Zeige die Commit-Historie beider Branches:
 ```bash
 git log --all --oneline --graph
 ```
 ### 6. Feature-Branch mergen
 Merge `feature/begruessung` in `main`:
 ```bash
 git merge feature/begruessung
 ```
 Jetzt ist `hallo.txt` auch auf `main` vorhanden.
 ### 7. Branch aufräumen
 Lösche den Feature-Branch, da er nicht mehr gebraucht wird:
 ```bash
 git branch -d feature/begruessung
 ```
 ---
 ## ✅ Erfolgskriterien
 - [ ] `git switch -c feature/begruessung` hat einen neuen Branch erstellt
 - [ ] `hallo.txt` existiert auf `feature/begruessung`, aber **nicht** auf `main` (vor dem Merge)
 - [ ] `git log --all --oneline --graph` zeigt beide Branches
 - [ ] Nach dem Merge ist `hallo.txt` auf `main` vorhanden
 - [ ] `git branch` zeigt nur noch `main` (nach dem Löschen)
@@ -0,0 +1,115 @@
 # ⚡ Modul 04 – Merge & Konflikte
 Beim Mergen bringt Git Änderungen aus verschiedenen Branches zusammen. Das klappt meistens automatisch – aber manchmal muss du eingreifen.
 ---
 ## Fast-Forward-Merge
 Ein **Fast-Forward-Merge** ist der einfachste Fall: `main` hat sich nicht verändert, während du auf deinem Feature-Branch gearbeitet hast. Git „spult" `main` einfach vorwärts.
 ```mermaid
 gitGraph
    commit id: "A"
    commit id: "B"
    branch feature/schnell
    checkout feature/schnell
    commit id: "C"
    commit id: "D"
    checkout main
    merge feature/schnell id: "Fast-Forward"
 ```
 Kein echter Merge-Commit entsteht – `main` zeigt einfach auf `D`.
 ---
 ## 3-Way-Merge
 Ein **3-Way-Merge** passiert, wenn beide Branches seit dem letzten gemeinsamen Commit neue Commits haben. Git vergleicht den gemeinsamen Vorfahren mit beiden Spitzen und kombiniert die Änderungen.
 ```mermaid
 gitGraph
    commit id: "Basis"
    commit id: "A"
    branch feature/konflikt
    checkout feature/konflikt
    commit id: "F1 – auf feature"
    checkout main
    commit id: "M1 – auf main"
    merge feature/konflikt id: "Merge Commit"
 ```
 Git erstellt dabei einen **Merge-Commit** mit zwei Eltern-Commits.
 ---
 ## Wenn ein Konflikt entsteht
 Ein Konflikt tritt auf, wenn **beide Branches dieselbe Zeile** einer Datei unterschiedlich geändert haben. Git weiß nicht, welche Version "richtig" ist – du musst entscheiden.
 ```bash
 git merge feature/konflikt
 ```
 ```text
 Auto-merging konflikt-vorlage.txt
 CONFLICT (content): Merge conflict in konflikt-vorlage.txt
 Automatic merge failed; fix conflicts and then commit the result.
 ```
 ---
 ## Konfliktmarker verstehen
 Git markiert den betroffenen Bereich in der Datei so:
 ```text
 <<<<<<< HEAD
 Diese Zeile stammt vom main-Branch.
 =======
 Diese Zeile stammt vom feature-Branch.
 >>>>>>> feature/konflikt
 ```
 | Marker | Bedeutung |
 |--------|-----------|
 | `<<<<<<< HEAD` | Beginn des Konfliktbereichs – deine aktuelle Version (main) |
 | `=======` | Trennlinie zwischen den beiden Versionen |
 | `>>>>>>> feature/konflikt` | Ende des Konfliktbereichs – die eingehende Version |
 ---
 ## Konflikt auflösen
 1. **Öffne die Datei** in einem Texteditor
 2. **Entscheide**, welche Version du behalten willst (oder kombiniere beide)
 3. **Entferne alle Konfliktmarker** (`<<<<<<<`, `=======`, `>>>>>>>`)
 4. **Stage die Datei** und committe:
 ```bash
 git add konflikt-vorlage.txt
 git commit -m "fix: Merge-Konflikt aufgelöst"
 ```
 ---
 ## Notausgang: Merge abbrechen
 Wenn du den Überblick verlierst und von vorn anfangen willst:
 ```bash
 git merge --abort
 ```
 Das setzt alles auf den Zustand vor dem Merge-Versuch zurück.
 ---
 ## 📝 Jetzt bist du dran!
 Weiter zur [Aufgabe](aufgabe.md).
 ---
 **Weiter geht's mit:** [05 – Remote & Pull Requests](../05-remote-und-pullrequests/README.md)
@@ -0,0 +1,133 @@
 # 📝 Aufgabe 04 – Merge & Konflikte
 In dieser Aufgabe provozierst du absichtlich einen Merge-Konflikt und löst ihn auf. Das ist der beste Weg, um Konflikte zu verstehen – bevor sie im echten Projekt auftreten!
 ---
 ## Ausgangssituation
 Lege ein neues Repo an:
 ```bash
 mkdir konflikt-uebung
 cd konflikt-uebung
 git init
 ```
 Kopiere die Datei [konflikt-vorlage.txt](konflikt-vorlage.txt) in den Ordner (oder erstelle sie neu):
 ```bash
 cp ../04-merge-und-konflikte/konflikt-vorlage.txt .
 git add konflikt-vorlage.txt
 git commit -m "chore: Vorlage hinzugefügt"
 ```
 ---
 ## Aufgabe
 ### 1. Ersten Feature-Branch anlegen
 ```bash
 git switch -c feature/version-a
 ```
 Öffne `konflikt-vorlage.txt` und ändere Zeile 3 (`[HIER ÄNDERN]`) zu:
 ```text
 Dies ist Version A – geändert von Branch feature/version-a.
 ```
 Committe die Änderung:
 ```bash
 git add konflikt-vorlage.txt
 git commit -m "feat: Version A in Zeile 3 eingetragen"
 ```
 ### 2. Ersten Branch in main mergen (Fast-Forward)
 ```bash
 git switch main
 git merge feature/version-a
 ```
 Da `main` sich nicht verändert hat, ist das ein **Fast-Forward-Merge** – kein Konflikt.
 ### 3. Zweiten Feature-Branch anlegen
 Erstelle vom aktuellen Stand von `main` einen zweiten Branch:
 ```bash
 git switch -c feature/version-b
 ```
 Öffne `konflikt-vorlage.txt` und ändere dieselbe Zeile 3 zu:
 ```text
 Dies ist Version B – geändert von Branch feature/version-b.
 ```
 Committe die Änderung:
 ```bash
 git add konflikt-vorlage.txt
 git commit -m "feat: Version B in Zeile 3 eingetragen"
 ```
 ### 4. Auch main verändern (Konflikt vorbereiten)
 ```bash
 git switch main
 ```
 Öffne `konflikt-vorlage.txt` und ändere Zeile 3 **nochmals** zu:
 ```text
 Dies ist die main-Version – direkt auf main geändert.
 ```
 Committe:
 ```bash
 git add konflikt-vorlage.txt
 git commit -m "fix: Zeile 3 auf main angepasst"
 ```
 ### 5. Konflikt provozieren
 Merge `feature/version-b` in `main`:
 ```bash
 git merge feature/version-b
 ```
 Git meldet einen Konflikt. Öffne `konflikt-vorlage.txt` und schau dir die Konfliktmarker an.
 ### 6. Konflikt auflösen
 Entscheide dich für eine Version (oder kombiniere beide) und entferne alle Konfliktmarker. Dann:
 ```bash
 git add konflikt-vorlage.txt
 git commit -m "fix: Merge-Konflikt in konflikt-vorlage.txt aufgelöst"
 ```
 ### 7. Ergebnis prüfen
 ```bash
 git log --oneline --graph
 ```
 Du solltest einen Merge-Commit mit zwei Eltern-Commits sehen.
 ---
 ## ✅ Erfolgskriterien
 - [ ] Der Fast-Forward-Merge (Schritt 2) hat keinen Merge-Commit erstellt
 - [ ] `git merge feature/version-b` hat einen Konflikt gemeldet
 - [ ] Du hast die Konfliktmarker in der Datei gesehen (`<<<<<<<`, `=======`, `>>>>>>>`)
 - [ ] Der Konflikt ist aufgelöst und committed
 - [ ] `git log --oneline --graph` zeigt einen Merge-Commit mit zwei Linien
 - [ ] `git status` zeigt `nothing to commit, working tree clean`
@@ -0,0 +1,5 @@
 Zeile 1: Diese Zeile wird nicht verändert.
 Zeile 2: Diese Zeile wird auch nicht verändert.
 Zeile 3: [HIER ÄNDERN] – Diese Zeile wird in beiden Branches unterschiedlich verändert.
 Zeile 4: Diese Zeile bleibt wieder gleich.
 Zeile 5: Ende der Vorlage.
@@ -0,0 +1,139 @@
 # 🌐 Modul 05 – Remote & Pull Requests
 Bisher hast du nur lokal gearbeitet. In diesem Modul verbindest du dein Repo mit einem Server und lernst, wie Teams zusammenarbeiten.
 ---
 ## Lokales vs. Remote-Repository
 Ein **lokales Repository** liegt auf deinem Rechner. Ein **Remote-Repository** liegt auf einem Server (z. B. GitHub oder GitLab) und ist für alle Teammitglieder erreichbar.
 ```mermaid
 flowchart LR
    LOCAL[Lokales Repo\n💻 dein Rechner] -->|git push| REMOTE[origin\n☁️ GitHub / GitLab]
    REMOTE -->|git pull| LOCAL
    REMOTE -->|git fetch| LOCAL
    COLLEAGUE[Kollegen-Repo\n💻 anderer Rechner] -->|git push| REMOTE
    REMOTE -->|git pull| COLLEAGUE
 ```
 ---
 ## Remote-Verbindung einrichten
 ### Schritt 1: Remote-Repo anlegen
 Erstelle auf [GitHub](https://github.com) oder [GitLab](https://gitlab.com) ein **leeres** Repository (ohne README, ohne .gitignore).
 ### Schritt 2: Remote-URL verknüpfen
 ```bash
 git remote add origin https://github.com/deinname/mein-repo.git
 ```
 ### Schritt 3: Remote-Verbindung prüfen
 ```bash
 git remote -v
 ```
 ```text
 origin  https://github.com/deinname/mein-repo.git (fetch)
 origin  https://github.com/deinname/mein-repo.git (push)
 ```
 ---
 ## Push – Commits hochladen
 ```bash
 git push -u origin main
 ```
 ```text
 Enumerating objects: 5, done.
 Counting objects: 100% (5/5), done.
 Writing objects: 100% (5/5), 432 bytes | 432.00 KiB/s, done.
 Total 5 (delta 0), reused 0 (delta 0), pack-reused 0
 To https://github.com/deinname/mein-repo.git
 * [new branch]      main -> main
 Branch 'main' set up to track remote branch 'main' from 'origin'.
 ```
 Das `-u` speichert die Verbindung. Ab jetzt reicht `git push`.
 ---
 ## Pull & Fetch – Änderungen herunterladen
 ```bash
 git pull
 ```
 Lädt neue Commits vom Remote und integriert sie direkt in deinen aktuellen Branch (= `git fetch` + `git merge`).
 ```bash
 git fetch
 ```
 Lädt neue Commits, integriert sie aber **noch nicht**. Du kannst erst prüfen, was sich geändert hat:
 ```bash
 git fetch
 git log HEAD..origin/main --oneline
 git merge origin/main
 ```
 | Befehl | Was passiert |
 |--------|-------------|
 | `git fetch` | Holt neue Commits, verändert deinen Branch nicht |
 | `git pull` | Holt + merged (= fetch + merge) |
 ---
 ## Der Pull-Request-Workflow
 Ein **Pull Request (PR)** ist keine Git-Funktion, sondern eine Funktion von GitHub/GitLab. Er ermöglicht Code-Review, bevor Änderungen in `main` landen.
 ### Typischer Ablauf:
 1. Du erstellst einen Feature-Branch lokal
 2. Du machst Commits auf dem Branch
 3. Du pushst den Branch auf das Remote:
   ```bash
   git push -u origin feature/mein-feature
   ```
 4. Auf GitHub/GitLab klickst du auf **"New Pull Request"** (GitHub) oder **"New Merge Request"** (GitLab)
 5. Du wählst `main` als Zielbranch und deinen Feature-Branch als Quellbranch
 6. Du gibst Titel und Beschreibung ein
 7. Kollegen reviewen den Code und hinterlassen Kommentare
 8. Du bearbeitest Feedback und machst weitere Commits (erscheinen automatisch im PR)
 9. Nach Freigabe klickt jemand auf **"Merge"**
 ---
 ## Mini-Aufgabe
 > **Voraussetzung:** Du hast einen Account auf GitHub oder GitLab.
 1. Erstelle ein leeres Remote-Repo (kein README!)
 2. Verbinde dein lokales Repo aus Modul 02 mit dem Remote:
   ```bash
   git remote add origin <URL-deines-Repos>
   git push -u origin main
   ```
 3. Öffne das Remote-Repo im Browser – deine Dateien sind da!
 4. Erstelle einen Branch `feature/test`, mache einen Commit, push ihn und erstelle einen Pull Request
 ---
 ## ✅ Erfolgskriterien
 - [ ] `git remote -v` zeigt deine Remote-URL
 - [ ] `git push` hat alle Commits hochgeladen (Status 200 / kein Fehler)
 - [ ] Du kannst deine Dateien im Browser auf GitHub/GitLab sehen
 - [ ] Du hast einen Pull Request erstellt
 ---
 **Weiter geht's mit:** [06 – Quick Reference](../06-quick-reference/cheatsheet.md)
@@ -0,0 +1,106 @@
 # 📋 Quick Reference – Git Cheatsheet
 Die wichtigsten Git-Befehle auf einen Blick.
 ---
 ## Setup
 | Befehl | Was er macht | Beispiel |
 |--------|-------------|---------|
 | `git config --global user.name` | Deinen Namen setzen | `git config --global user.name "Anna Muster"` |
 | `git config --global user.email` | E-Mail setzen | `git config --global user.email "anna@example.com"` |
 | `git config --list` | Alle Einstellungen anzeigen | `git config --list` |
 ---
 ## Lokale Änderungen
 | Befehl | Was er macht | Beispiel |
 |--------|-------------|---------|
 | `git init` | Neues Repo anlegen | `git init` |
 | `git status` | Aktuellen Zustand prüfen | `git status` |
 | `git add <datei>` | Datei stagen | `git add README.md` |
 | `git add .` | Alle Änderungen stagen | `git add .` |
 | `git commit -m "..."` | Commit erstellen | `git commit -m "feat: Login hinzugefügt"` |
 | `git diff` | Unstaged Änderungen ansehen | `git diff` |
 | `git diff --staged` | Staged Änderungen ansehen | `git diff --staged` |
 | `git restore <datei>` | Lokale Änderungen verwerfen | `git restore index.html` |
 | `git restore --staged <datei>` | Datei aus Staging Area entfernen | `git restore --staged index.html` |
 ---
 ## History
 | Befehl | Was er macht | Beispiel |
 |--------|-------------|---------|
 | `git log` | Vollständige Commit-Historie | `git log` |
 | `git log --oneline` | Kompakte Übersicht | `git log --oneline` |
 | `git log --all --graph` | Alle Branches grafisch | `git log --all --oneline --graph` |
 | `git show <hash>` | Einzelnen Commit ansehen | `git show a3f9c12` |
 ---
 ## Branches
 | Befehl | Was er macht | Beispiel |
 |--------|-------------|---------|
 | `git branch` | Alle lokalen Branches | `git branch` |
 | `git branch <name>` | Neuen Branch erstellen | `git branch feature/login` |
 | `git switch <name>` | Zu Branch wechseln | `git switch feature/login` |
 | `git switch -c <name>` | Branch erstellen & wechseln | `git switch -c feature/login` |
 | `git merge <name>` | Branch in aktuellen mergen | `git merge feature/login` |
 | `git branch -d <name>` | Branch löschen | `git branch -d feature/login` |
 | `git merge --abort` | Laufenden Merge abbrechen | `git merge --abort` |
 ---
 ## Remote
 | Befehl | Was er macht | Beispiel |
 |--------|-------------|---------|
 | `git remote -v` | Remote-URLs anzeigen | `git remote -v` |
 | `git remote add` | Remote verknüpfen | `git remote add origin <URL>` |
 | `git push -u origin main` | Ersten Push + Tracking setzen | `git push -u origin main` |
 | `git push` | Commits hochladen | `git push` |
 | `git pull` | Commits herunterladen & mergen | `git pull` |
 | `git fetch` | Commits holen, nicht mergen | `git fetch` |
 | `git clone <url>` | Repo herunterladen | `git clone https://github.com/...` |
 ---
 ## Notfall
 | Befehl | Was er macht | Beispiel |
 |--------|-------------|---------|
 | `git stash` | Änderungen temporär wegräumen | `git stash` |
 | `git stash pop` | Weggeräumte Änderungen zurückholen | `git stash pop` |
 | `git revert <hash>` | Commit rückgängig machen (sicher!) | `git revert a3f9c12` |
 | `git merge --abort` | Merge abbrechen | `git merge --abort` |
 ---
 ## Datei-Zustände
 ```mermaid
 stateDiagram-v2
    [*] --> Untracked : Neue Datei erstellt
    Untracked --> Staged : git add
    Staged --> Committed : git commit
    Committed --> Modified : Datei bearbeitet
    Modified --> Staged : git add
    Staged --> Modified : git restore --staged
    Modified --> Committed : git restore (Änderungen verwerfen)
    Committed --> [*]
 ```
 | Zustand | Bedeutung |
 |---------|-----------|
 | **Untracked** | Git kennt die Datei noch nicht |
 | **Modified** | Datei geändert, aber nicht gestagter |
 | **Staged** | Bereit für den nächsten Commit |
 | **Committed** | Sicher in der Versionshistorie gespeichert |
 ---
 *Zurück zur [Startseite](../README.md)*
@@ -0,0 +1,21 @@
 MIT License
 Copyright (c) 2025 Git-Schulung Contributors
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
 in the Software without restriction, including without limitation the rights
 to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 copies of the Software, and to permit persons to whom the Software is
 furnished to do so, subject to the following conditions:
 The above copyright notice and this permission notice shall be included in all
 copies or substantial portions of the Software.
 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
@@ -0,0 +1,55 @@
 # 🎓 Git-Schulung für Einsteiger
 Willkommen! Diese Schulung führt dich Schritt für Schritt durch die wichtigsten Git-Konzepte – ohne Vorkenntnisse, in 60–90 Minuten.
 ## Lernziele
 Nach dieser Schulung kannst du:
 1. **Commits** erstellen und die Versionshistorie lesen
 2. **Branches** anlegen und zwischen ihnen wechseln
 3. Branches **mergen** und dabei auftretende Konflikte lösen
 4. Ein lokales Repo mit einem **Remote-Repository** verbinden
 5. Den **Pull-Request-Workflow** auf GitHub oder GitLab anwenden
 ## Voraussetzungen
 - Git ist installiert (→ [00-vorbereitung](00-vorbereitung/README.md))
 - Du kannst ein Terminal / eine Kommandozeile öffnen
 - Du hast einen Texteditor (z. B. VS Code, Notepad++, nano)
 ## Zeitplan
 | Modul | Dauer | Inhalt |
 |-------|-------|--------|
 | [00 – Vorbereitung](00-vorbereitung/README.md) | 10 min | Git installieren & konfigurieren |
 | [01 – Grundkonzepte](01-grundkonzepte/README.md) | 15 min | 3-Bereiche-Modell, Commits verstehen |
 | [02 – Erste Schritte](02-erste-schritte/README.md) | 15 min | init, add, commit, log |
 | [03 – Branches](03-branches/README.md) | 15 min | Branches anlegen und mergen |
 | [04 – Konflikte](04-merge-und-konflikte/README.md) | 15 min | Merge-Konflikte lösen |
 | [05 – Remote & PRs](05-remote-und-pullrequests/README.md) | 10 min | push, pull, Pull Requests |
 | [06 – Cheatsheet](06-quick-reference/cheatsheet.md) | Referenz | Die 20 wichtigsten Befehle |
 > **Hinweis:** Bearbeite die Module in der Reihenfolge der Nummern. Jedes Modul baut auf dem vorherigen auf.
 ## 🗺 Lernpfad
 ```mermaid
 flowchart TD
    A([Start]) --> B[00 – Vorbereitung\nGit installieren & konfigurieren]
    B --> C[01 – Grundkonzepte\n3-Bereiche-Modell & Commits]
    C --> D[02 – Erste Schritte\ninit · add · commit · log]
    D --> E[03 – Branches\nbranch · switch · merge]
    E --> F[04 – Merge & Konflikte\nKonflikte erkennen & lösen]
    F --> G[05 – Remote & Pull Requests\npush · pull · PR-Workflow]
    G --> H[06 – Quick Reference\nCheatsheet]
    H --> I([Fertig! 🎉])
 ```
 ## Lösungen
 Die Lösungen zu den Aufgaben findest du im Ordner [loesungen/](loesungen/). Schau erst rein, wenn du selbst einen Versuch gemacht hast!
 ---
 *Bei Fragen wende dich an deine Trainerin oder deinen Trainer.*
@@ -0,0 +1,100 @@
 # ✅ Lösung – Aufgabe 02: Erste Schritte
 > Schau dir diese Lösung erst an, nachdem du die Aufgabe selbst versucht hast!
 ---
 ## Schritt-für-Schritt-Lösung
 ### 1. Ordner anlegen und initialisieren
 ```bash
 mkdir meine-notizen
 cd meine-notizen
 git init
 ```
 ```text
 Initialized empty Git repository in /pfad/zu/meine-notizen/.git/
 ```
 ### 2. Datei anlegen – Commit 1
 Erstelle `notizen.md` und füge die erste Zeile ein:
 ```bash
 echo "Git ist ein Versionskontrollsystem." > notizen.md
 git add notizen.md
 git commit -m "docs: Erste Notiz – Was ist Git?"
 ```
 ```text
 [main (root-commit) a1b2c3d] docs: Erste Notiz – Was ist Git?
 1 file changed, 1 insertion(+)
 create mode 100644 notizen.md
 ```
 ### 3. Zweite Zeile – Commit 2
 Öffne `notizen.md` und füge Zeile 2 hinzu. Dann:
 ```bash
 git add notizen.md
 git commit -m "docs: Zweite Notiz – Was sind Commits?"
 ```
 ```text
 [main e4f5g6h] docs: Zweite Notiz – Was sind Commits?
 1 file changed, 1 insertion(+)
 ```
 ### 4. Dritte Zeile – Commit 3
 Öffne `notizen.md` und füge Zeile 3 hinzu. Dann:
 ```bash
 git add notizen.md
 git commit -m "docs: Dritte Notiz – Was ist die Staging Area?"
 ```
 ```text
 [main i7j8k9l] docs: Dritte Notiz – Was ist die Staging Area?
 1 file changed, 1 insertion(+)
 ```
 ### 5. Erwartete Log-Ausgabe
 ```bash
 git log --oneline
 ```
 ```text
 i7j8k9l (HEAD -> main) docs: Dritte Notiz – Was ist die Staging Area?
 e4f5g6h docs: Zweite Notiz – Was sind Commits?
 a1b2c3d docs: Erste Notiz – Was ist Git?
 ```
 ### 6. Abschlussprüfung
 ```bash
 git status
 ```
 ```text
 On branch main
 nothing to commit, working tree clean
 ```
 ---
 ## Fertiger Inhalt von notizen.md
 ```text
 Git ist ein Versionskontrollsystem.
 Commits sind Snapshots meines Projekts.
 Die Staging Area bereitet Commits vor.
 ```
 ---
 *Zurück zur [Aufgabe](../02-erste-schritte/aufgabe.md)*
@@ -0,0 +1,125 @@
 # ✅ Lösung – Aufgabe 03: Branches
 > Schau dir diese Lösung erst an, nachdem du die Aufgabe selbst versucht hast!
 ---
 ## Schritt-für-Schritt-Lösung
 ### 1. Ausgangssituation herstellen
 ```bash
 mkdir branch-uebung
 cd branch-uebung
 git init
 echo "# Branch-Übung" > README.md
 git add README.md
 git commit -m "chore: Projekt angelegt"
 ```
 ### 2. Feature-Branch anlegen
 ```bash
 git switch -c feature/begruessung
 ```
 ```text
 Switched to a new branch 'feature/begruessung'
 ```
 ### 3. Datei erstellen und committen
 ```bash
 echo "Hallo, Welt!" > hallo.txt
 echo "Willkommen in meinem ersten Git-Projekt." >> hallo.txt
 git add hallo.txt
 git commit -m "feat: Begrüßungsdatei hinzugefügt"
 ```
 ```text
 [feature/begruessung c3d4e56] feat: Begrüßungsdatei hinzugefügt
 1 file changed, 2 insertions(+)
 create mode 100644 hallo.txt
 ```
 ### 4. Zurück zu main
 ```bash
 git switch main
 ```
 ```text
 Switched to branch 'main'
 ```
 Prüfe, ob `hallo.txt` da ist:
 ```bash
 ls
 ```
 ```text
 README.md
 ```
 `hallo.txt` fehlt – korrekt! Auf `main` existiert sie noch nicht.
 ### 5. Commit-Übersicht beider Branches
 ```bash
 git log --all --oneline --graph
 ```
 ```text
 * c3d4e56 (feature/begruessung) feat: Begrüßungsdatei hinzugefügt
 * a1b2c3d (HEAD -> main) chore: Projekt angelegt
 ```
 ### 6. Merge
 ```bash
 git merge feature/begruessung
 ```
 ```text
 Updating a1b2c3d..c3d4e56
 Fast-forward
 hallo.txt | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 hallo.txt
 ```
 `hallo.txt` ist jetzt auf `main` vorhanden.
 ### 7. Branch aufräumen
 ```bash
 git branch -d feature/begruessung
 ```
 ```text
 Deleted branch feature/begruessung (was c3d4e56).
 ```
 ### Abschlusszustand
 ```bash
 git log --oneline
 ```
 ```text
 c3d4e56 (HEAD -> main) feat: Begrüßungsdatei hinzugefügt
 a1b2c3d chore: Projekt angelegt
 ```
 ```bash
 git branch
 ```
 ```text
 * main
 ```
 ---
 *Zurück zur [Aufgabe](../03-branches/aufgabe.md)*
@@ -0,0 +1,158 @@
 # ✅ Lösung – Aufgabe 04: Merge & Konflikte
 > Schau dir diese Lösung erst an, nachdem du die Aufgabe selbst versucht hast!
 ---
 ## Schritt-für-Schritt-Lösung
 ### 1. Ausgangssituation
 ```bash
 mkdir konflikt-uebung
 cd konflikt-uebung
 git init
 cp ../04-merge-und-konflikte/konflikt-vorlage.txt .
 git add konflikt-vorlage.txt
 git commit -m "chore: Vorlage hinzugefügt"
 ```
 ### 2. Ersten Feature-Branch erstellen und ändern
 ```bash
 git switch -c feature/version-a
 ```
 Öffne `konflikt-vorlage.txt` und ändere Zeile 3 zu:
 ```text
 Zeile 3: Dies ist Version A – geändert von Branch feature/version-a.
 ```
 ```bash
 git add konflikt-vorlage.txt
 git commit -m "feat: Version A in Zeile 3 eingetragen"
 ```
 ### 3. Fast-Forward-Merge
 ```bash
 git switch main
 git merge feature/version-a
 ```
 ```text
 Updating a1b2c3d..b2c3d4e
 Fast-forward
 konflikt-vorlage.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 ```
 Kein Merge-Commit! `main` wurde einfach vorgespult.
 ### 4. Zweiten Feature-Branch erstellen
 ```bash
 git switch -c feature/version-b
 ```
 Öffne `konflikt-vorlage.txt` und ändere Zeile 3 zu:
 ```text
 Zeile 3: Dies ist Version B – geändert von Branch feature/version-b.
 ```
 ```bash
 git add konflikt-vorlage.txt
 git commit -m "feat: Version B in Zeile 3 eingetragen"
 ```
 ### 5. main auch ändern (Konflikt vorbereiten)
 ```bash
 git switch main
 ```
 Öffne `konflikt-vorlage.txt` und ändere Zeile 3 zu:
 ```text
 Zeile 3: Dies ist die main-Version – direkt auf main geändert.
 ```
 ```bash
 git add konflikt-vorlage.txt
 git commit -m "fix: Zeile 3 auf main angepasst"
 ```
 ### 6. Konflikt provozieren
 ```bash
 git merge feature/version-b
 ```
 ```text
 Auto-merging konflikt-vorlage.txt
 CONFLICT (content): Merge conflict in konflikt-vorlage.txt
 Automatic merge failed; fix conflicts and then commit the result.
 ```
 ### 7. Konflikt ansehen
 Öffne `konflikt-vorlage.txt`. Du siehst:
 ```text
 Zeile 1: Diese Zeile wird nicht verändert.
 Zeile 2: Diese Zeile wird auch nicht verändert.
 <<<<<<< HEAD
 Zeile 3: Dies ist die main-Version – direkt auf main geändert.
 =======
 Zeile 3: Dies ist Version B – geändert von Branch feature/version-b.
 >>>>>>> feature/version-b
 Zeile 4: Diese Zeile bleibt wieder gleich.
 Zeile 5: Ende der Vorlage.
 ```
 ### 8. Konflikt auflösen
 Entscheide dich für eine Lösung – zum Beispiel eine Kombination:
 ```text
 Zeile 1: Diese Zeile wird nicht verändert.
 Zeile 2: Diese Zeile wird auch nicht verändert.
 Zeile 3: Finale Version – kombiniert aus main und feature/version-b.
 Zeile 4: Diese Zeile bleibt wieder gleich.
 Zeile 5: Ende der Vorlage.
 ```
 Alle Konfliktmarker entfernen, dann:
 ```bash
 git add konflikt-vorlage.txt
 git commit -m "fix: Merge-Konflikt in konflikt-vorlage.txt aufgelöst"
 ```
 ```text
 [main f6g7h8i] fix: Merge-Konflikt in konflikt-vorlage.txt aufgelöst
 ```
 ### 9. Abschlusszustand
 ```bash
 git log --oneline --graph
 ```
 ```text
 *   f6g7h8i (HEAD -> main) fix: Merge-Konflikt aufgelöst
 |\
 | * e5f6g7h (feature/version-b) feat: Version B in Zeile 3 eingetragen
 * | d4e5f6g fix: Zeile 3 auf main angepasst
 |/
 * b2c3d4e feat: Version A in Zeile 3 eingetragen
 * a1b2c3d chore: Vorlage hinzugefügt
 ```
 Der Merge-Commit `f6g7h8i` hat zwei Eltern-Commits (`d4e5f6g` und `e5f6g7h`).
 ---
 *Zurück zur [Aufgabe](../04-merge-und-konflikte/aufgabe.md)*
@@ -0,0 +1,62 @@
 #!/bin/bash
 # Setzt Übungsordner zurück, die Teilnehmende während der Schulung angelegt haben.
 # Führe dieses Skript aus dem Stammverzeichnis des Schulungs-Repos aus.
 set -euo pipefail
 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 echo "=== Git-Schulung: Übungen zurücksetzen ==="
 echo "Arbeitsverzeichnis: $SCRIPT_DIR"
 echo ""
 # Sicherheitsabfrage
 read -rp "Alle Übungsordner (meine-notizen, branch-uebung, konflikt-uebung) löschen? [j/N] " antwort
 if [[ "${antwort,,}" != "j" ]]; then
    echo "Abgebrochen."
    exit 0
 fi
 # Übungsordner entfernen (aus Sicherheit nur bekannte Namen)
 UEBUNGSORDNER=("meine-notizen" "branch-uebung" "konflikt-uebung")
 for ordner in "${UEBUNGSORDNER[@]}"; do
    ziel="$SCRIPT_DIR/$ordner"
    if [[ -d "$ziel" ]]; then
        rm -rf "$ziel"
        echo "  ✓ Entfernt: $ordner"
    else
        echo "  – Nicht vorhanden: $ordner (übersprungen)"
    fi
 done
 # konflikt-vorlage.txt zurücksetzen
 VORLAGE="$SCRIPT_DIR/04-merge-und-konflikte/konflikt-vorlage.txt"
 if [[ -f "$VORLAGE" ]]; then
    cat > "$VORLAGE" <<'EOF'
 Zeile 1: Diese Zeile wird nicht verändert.
 Zeile 2: Diese Zeile wird auch nicht verändert.
 Zeile 3: [HIER ÄNDERN] – Diese Zeile wird in beiden Branches unterschiedlich verändert.
 Zeile 4: Diese Zeile bleibt wieder gleich.
 Zeile 5: Ende der Vorlage.
 EOF
    echo "  ✓ konflikt-vorlage.txt zurückgesetzt"
 fi
 # Prüfen, ob das Schulungs-Repo selbst sauber ist
 cd "$SCRIPT_DIR"
 if git rev-parse --git-dir > /dev/null 2>&1; then
    STATUS=$(git status --porcelain)
    if [[ -n "$STATUS" ]]; then
        echo ""
        echo "  ⚠ Das Schulungs-Repo hat ungespeicherte Änderungen:"
        git status --short
        echo ""
        echo "  Tipp: 'git restore .' setzt alle Änderungen zurück."
    else
        echo "  ✓ Schulungs-Repo ist sauber"
    fi
 fi
 echo ""
 echo "=== Fertig! Das Repo ist bereit für die nächste Schulung. ==="
@@ -0,0 +1,165 @@
 # 📖 Trainerhandbuch
 Dieses Dokument richtet sich an Personen, die diese Git-Schulung durchführen. Es enthält Hinweise zur Vorbereitung, typische Stolpersteine und Vorschläge für Diskussionen.
 ---
 ## Vorbereitung vor der Schulung
 ### Checkliste (30 Minuten vorher)
 - [ ] Repo geklont oder frisch aufgesetzt: `git clone <url> git-schulung`
 - [ ] Eigene Git-Konfiguration geprüft: `git config --list`
 - [ ] Test-Remote-Repository angelegt (leer, für Modul 05)
 - [ ] Terminal / Git Bash geöffnet und getestet
 - [ ] Projektor / Bildschirmübertragung eingerichtet
 - [ ] Alle Teilnehmenden haben Git installiert (Modul 00 vorab schicken)
 - [ ] Backup-Plan: USB-Stick mit Git-Installer für alle gängigen Betriebssysteme
 ### Empfohlene Werkzeuge am Rechner des Trainers
 - Git (aktuell)
 - VS Code mit GitLens-Extension (gute Visualisierung)
 - Browser mit GitHub/GitLab Account
 ---
 ## Zeitplan und Pausen
 | Modul | Dauer | Pause danach |
 |-------|-------|-------------|
 | 00 – Vorbereitung | 10 min | – |
 | 01 – Grundkonzepte | 15 min | **5 min Pause** |
 | 02 – Erste Schritte | 15 min | – |
 | 03 – Branches | 15 min | **10 min Pause** |
 | 04 – Konflikte | 15 min | – |
 | 05 – Remote & PRs | 10 min | – |
 | 06 – Cheatsheet + Q&A | 10 min | Ende |
 **Gesamt:** ca. 90 Minuten mit Pausen, 70 Minuten ohne.
 ---
 ## Typische Stolpersteine bei Anfängern
 ### 1. Detached HEAD
 **Was passiert:** Jemand hat direkt einen alten Commit mit `git checkout <hash>` ausgecheckt.
 **Was Git sagt:**
 ```text
 HEAD detached at a3f9c12
 ```
 **Lösung:**
 ```bash
 git switch main
 ```
 **Erklärung für Teilnehmende:** "HEAD" ist wie ein Lesezeichen. Normalerweise zeigt es auf einen Branch-Namen (wie `main`). Im "Detached HEAD"-Zustand zeigt es direkt auf einen Commit – kein Branch wird bewegt. Mit `git switch main` befestigst du das Lesezeichen wieder am richtigen Branch.
 ---
 ### 2. Falscher Branch
 **Was passiert:** Jemand macht einen Commit auf `main`, obwohl er auf einem Feature-Branch sein wollte.
 **Lösung (wenn noch nicht gepusht):**
 ```bash
 git switch -c feature/mein-feature  # Branch erstellen (nimmt den Commit mit)
 git switch main
 git reset --hard HEAD~1             # Commit von main entfernen
 ```
 **Einfachere Lösung:** `git cherry-pick` erwähnen als Hinweis, nicht als Pflicht.
 ---
 ### 3. Commit-Nachricht vergessen / schlecht
 **Was passiert:** `git commit` ohne `-m` öffnet den Editor. Viele Anfänger wissen nicht, wie sie ihn schließen.
 **Nano:** `Ctrl+O`, Enter, `Ctrl+X`
 **Vim:** `i` zum Editieren, `Esc`, dann `:wq` und Enter
 **Empfehlung:** Immer `-m "..."` verwenden, bis der Workflow sitzt.
 ---
 ### 4. Tippfehler in Branch-Namen
 **Was passiert:** `git switch feautre/login` → Fehler.
 **Lösung:**
 ```bash
 git branch -m feautre/login feature/login  # Branch umbenennen
 ```
 ---
 ### 5. Staging Area vergessen
 **Was passiert:** Jemand ruft `git commit -m "..."` auf, obwohl nichts gestagtet ist.
 **Git sagt:**
 ```text
 nothing to commit, working tree clean
 ```
 **Erinnerung:** Immer `git status` vor `git commit` schauen!
 ---
 ### 6. Merge-Konflikt-Panik
 **Was passiert:** Jemand sieht Konfliktmarker zum ersten Mal und weiß nicht, was zu tun ist.
 **Tipp:** Ruhig bleiben. `git merge --abort` als Notausgang zeigen. Erklären, dass der Konflikt nur in der Datei ist – nichts ist kaputt.
 ---
 ## Diskussionsfragen pro Modul
 ### Nach Modul 01
 - "Warum macht eine Staging Area Sinn? Wann würdet ihr nicht alle Änderungen in einen Commit packen?"
 ### Nach Modul 02
 - "Wie oft sollte man committen? Nach jeder Zeile? Nach jedem Feature?"
 - "Was ist eine gute Commit-Nachricht? Zeigt ein Beispiel aus eurem Alltag."
 ### Nach Modul 03
 - "Wann würdet ihr einen Branch anlegen? Immer? Nur bei größeren Features?"
 - "Was ist der Unterschied zwischen Branch und Fork?"
 ### Nach Modul 04
 - "Was passiert, wenn zwei Leute gleichzeitig dieselbe Datei ändern – wer 'gewinnt'?"
 - "Könnt ihr euch einen Fall vorstellen, wo ein Fast-Forward unerwünscht wäre?"
 ### Nach Modul 05
 - "Was ist der Vorteil eines Pull Requests gegenüber direktem Push auf main?"
 - "Wer sollte einen PR reviewen? Wie lange darf ein PR offen bleiben?"
 ---
 ## Repo für die nächste Schulung frisch machen
 Führe das Reset-Skript aus:
 ```bash
 bash reset-uebung.sh
 ```
 Das Skript entfernt alle Übungsordner, die Teilnehmende angelegt haben, und stellt sicher, dass das Schulungs-Repo sauber ist. Lies das Skript vorher kurz durch, um sicherzugehen, dass es in deiner Umgebung korrekt funktioniert.
 ---
 ## Häufige Fragen (FAQ)
 **Frage:** "Kann ich Git auch ohne GitHub nutzen?"
 **Antwort:** Ja! Git ist lokal. GitHub ist nur eine Hosting-Plattform. Du brauchst GitHub erst für Remote-Repos und Zusammenarbeit.
 **Frage:** "Was ist der Unterschied zwischen Git und GitHub?"
 **Antwort:** Git ist das Werkzeug (lokal installiert). GitHub ist ein Dienst im Internet, der Git-Repos hostet und zusätzliche Funktionen (PRs, Issues, Actions) bietet.
 **Frage:** "Was ist ein 'origin'?"
 **Antwort:** Ein Kurzname für das Remote-Repo – per Konvention heißt das erste Remote immer `origin`. Du könntest es auch `meinserver` nennen.