chore: initial training material setup
This commit is contained in:
@@ -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.
|
||||
Reference in New Issue
Block a user