Home/Modul 2

📝 Modul 2: Versionskontrolle mit Git

⏱️ Dauer: ca. 90 Minuten

Lernziele: Sie verstehen die Git-Architektur (Working Directory, Staging, Repository), können mit Branches arbeiten, Merge-Konflikte lösen, die Git-History analysieren und kennen bewährte Branching-Strategien für Netzwerkumgebungen.

📚 Inhalt dieses Moduls

  • 1. Was ist Git?
  • 2. Die drei Zonen von Git
  • 3. Git-Grundbefehle
  • 4. Branching-Strategien
  • 5. Merge-Konflikte verstehen
  • 6. Git History & Logs
  • 7. Praxis-Übungen (6 Stück)
  • 8. Cheat Sheet & Troubleshooting

1. Was ist Git?

Stellen Sie sich Git vor wie Speicherpunkte in einem Videospiel. Sie können jederzeit speichern, und wenn etwas schiefgeht, laden Sie einfach einen früheren Spielstand. Nur viel besser: Git speichert ALLE Spielstände, nicht nur den letzten.

💡Git in einem Satz
Git ist ein verteiltes Versionskontrollsystem, das jede Änderung an Ihren Dateien aufzeichnet und es ermöglicht, jederzeit zu einem früheren Zustand zurückzukehren – und das alles, ohne dass Sie eine permanente Serververbindung brauchen.

Warum Git für Netzwerkkonfigurationen?

In der klassischen Netzwerkwelt kennt jeder das Problem: "Wer hat denn gestern Nacht den Switch-Port geändert?" Mit Git gehört das der Vergangenheit an.

  • Vollständige History: Wer hat wann welche Änderung gemacht – und warum?
  • Rollback in Sekunden: Letzte Änderung war Mist? Ein Befehl, alles wieder gut.
  • Paralleles Arbeiten: Drei Leute, drei Features, null Konflikte
  • Automatisches Backup: Ihr Code ist sicher auf einem Server (GitLab, GitHub)
  • Code Review: Vier-Augen-Prinzip vor der Produktion
  • Audit-Trail: Für Compliance unverzichtbar
ℹ️Vergleich: Vorher vs. Nachher
❌ Ohne Git:
  • switch-config_v2_final_FINAL.txt
  • switch-config_backup_jan_neu.txt
  • "Wer hat das geändert?!"
  • Rollback = Panik
✅ Mit Git:
  • Eine Datei, vollständige History
  • Jede Änderung dokumentiert
  • git blame → sofort sichtbar
  • git revert → 5 Sekunden

2. Die drei Zonen von Git verstehen

Bevor wir mit den Befehlen loslegen, müssen Sie verstehen, wie Git intern funktioniert. Stellen Sie sich Git wie eine Baustelle mit drei Bereichen vor:

┌─────────────────────────────────────────────────────────────────────────┐
│                        GIT - Die drei Zonen                              │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   ┌─────────────────┐    git add     ┌─────────────────┐    git commit  │
│   │                 │ ─────────────> │                 │ ─────────────> │
│   │    WORKING      │                │    STAGING      │                │
│   │   DIRECTORY     │                │     AREA        │                │
│   │                 │ <───────────── │    (Index)      │                │
│   │  📁 Ihre Dateien│   git restore  │  📋 Vorbereit.  │                │
│   └─────────────────┘                └─────────────────┘                │
│          │                                                               │
│          │                                    │                          │
│          │                                    │                          │
│          │                                    ▼                          │
│          │                          ┌─────────────────┐                 │
│          │                          │                 │                 │
│          │                          │   REPOSITORY    │                 │
│          │  <───────────────────────│    (.git)       │                 │
│          │       git checkout       │                 │                 │
│                                     │  💾 Geschichte  │                 │
│                                     └─────────────────┘                 │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘
📁

Working Directory

Die Baustelle: Hier arbeiten Sie! Alle Dateien, die Sie sehen und bearbeiten können. Änderungen hier sind noch nicht gesichert.

Analogie: Der Schreibtisch, auf dem Sie gerade arbeiten.

📋

Staging Area (Index)

Der Warenkorb: Hier sammeln Sie Änderungen, die zusammen committet werden sollen. Wie ein Einkaufswagen vor der Kasse.

Analogie: Das Tablett vor dem Fotografieren – Sie arrangieren erst, dann knipsen.

💾

Repository (.git)

Das Archiv: Alle Commits, die gesamte Geschichte. Hier ist alles sicher gespeichert – für immer.

Analogie: Das Videospiel-Archiv mit allen Speicherständen.

💡Der Workflow in einem Satz

Sie bearbeiten Dateien im Working Directory, stagen sie für den nächsten Commit, und committen sie ins Repository. Erst dann ist die Änderung wirklich gespeichert!

Beispiel: Eine Änderung durch alle Zonen

📄 Terminal
# 1️⃣ Sie bearbeiten eine Datei (Working Directory)
nano switch-config.yaml

# 2️⃣ Status zeigt: Datei wurde geändert (rot = nicht gestaged)
git status
# modified:   switch-config.yaml  (rot)

# 3️⃣ Datei in die Staging Area verschieben
git add switch-config.yaml

# 4️⃣ Status zeigt: Datei ist zum Commit bereit (grün = gestaged)
git status
# modified:   switch-config.yaml  (grün)

# 5️⃣ Commit erstellen (ab ins Repository!)
git commit -m "VLAN 100 auf Switch konfiguriert"

# 6️⃣ Status zeigt: Alles sauber
git status
# nothing to commit, working tree clean

3. Die wichtigsten Git-Befehle

3.1 Repository erstellen oder klonen

Zwei Wege zum Repository:

📄 Terminal
# Option A: Bestehendes Repository klonen
git clone https://gitlab.local/netzwerk/fabric-config.git
cd fabric-config

# Option B: Neues Repository erstellen
mkdir mein-projekt
cd mein-projekt
git init

3.2 Änderungen verfolgen und committen

Der tägliche Workflow:

📄 Terminal
# Status anzeigen - was hat sich geändert?
git status

# Alle Änderungen zum Commit vormerken (stagen)
git add .

# Oder nur bestimmte Dateien
git add fabric.yaml
git add configs/spine-1.yaml

# Oder mit Wildcards
git add *.yaml

# Änderungen aus der Staging Area entfernen (ohne Datei zu löschen!)
git restore --staged fabric.yaml

# Commit erstellen mit aussagekräftiger Message
git commit -m "VLAN 100 hinzugefügt für Produktion"

# Änderungen zum Server hochladen
git push
💡Gute Commit-Messages schreiben

Die Commit-Message sollte erklären, was und warum geändert wurde:

❌ Schlecht:
  • "Update"
  • "Fix"
  • "Änderungen"
  • "asdf"
✅ Gut:
  • "VLAN 100 für Produktions-Server hinzugefügt"
  • "BGP-Peer zu ISP2 konfiguriert (AS65002)"
  • "MTU auf 9000 für Jumbo Frames angepasst"
  • "Tippfehler in Spine-1 Hostname behoben"

3.3 Änderungen vom Server holen

📄 Terminal
# Neueste Änderungen vom Server holen und integrieren
git pull

# Nur Informationen holen (ohne zu mergen)
git fetch

# Was hat sich auf dem Server geändert?
git log origin/main --oneline -5
⚠️Pull vor Push!

Bevor Sie git push machen, immer erst git pull! Sonst riskieren Sie Konflikte, wenn jemand anders in der Zwischenzeit Änderungen gepusht hat.

4. Branching-Strategien verstehen

Branches sind wie Baustellen auf der Autobahn: Der Verkehr (Produktion) läuft weiter, während Sie in Ruhe an der Seite umbauen. Erst wenn die Baustelle fertig ist, wird die neue Spur freigegeben.

4.1 Branches erstellen und wechseln

📄 Terminal
# Alle Branches anzeigen
git branch

# Neuen Branch erstellen
git branch feature/vlan-200

# Zu einem Branch wechseln
git checkout feature/vlan-200

# ODER: Erstellen und direkt wechseln (empfohlen!)
git checkout -b feature/vlan-200

# Neuere Alternative (ab Git 2.23):
git switch -c feature/vlan-200

# Zurück zum main Branch
git checkout main

# Branch löschen (nachdem er gemerged wurde)
git branch -d feature/vlan-200

# Branch forciert löschen (auch ohne Merge)
git branch -D feature/vlan-200

4.2 Branching-Strategie: GitFlow vs. Trunk-Based

Für Netzwerkteams gibt es zwei gängige Strategien. Die Wahl hängt von Ihrer Team-Größe und Änderungsfrequenz ab:

🌳 GitFlow

Mehrere langlebige Branches für verschiedene Umgebungen.

main ─────────────────────────
└── develop ────────────────
└── feature/vlan-200 ─
└── feature/bgp-peer ──
✅ Vorteile:
  • Klare Trennung: Dev/Test/Prod
  • Gut für Release-Zyklen
  • Einfaches Rollback
❌ Nachteile:
  • Komplex bei vielen Branches
  • Lange Lebenszeiten = Merge-Hölle

🎯 Trunk-Based Development

Ein Hauptbranch, kurzlebige Feature-Branches.

main ─────────────────────────
└── feature/vlan ─┐ (1-2 Tage)
└──────────
└── fix/typo ─┐ (Stunden)
└────────────
✅ Vorteile:
  • Einfach und schnell
  • Weniger Merge-Konflikte
  • Ideal für CI/CD
❌ Nachteile:
  • Erfordert gute Tests
  • Feature Flags manchmal nötig
💡Empfehlung für Netzwerkteams

Für die meisten Netzwerkteams empfehlen wir Trunk-Based Development:

  • Feature-Branch erstellen (max. 1-2 Tage Lebenszeit)
  • Kleine, fokussierte Änderungen
  • Schneller Merge Request + Review
  • CI/CD-Pipeline validiert automatisch

GitFlow macht nur Sinn, wenn Sie strikte Release-Zyklen haben (z.B. monatliche Rollouts).

4.3 Branch-Namenskonventionen

Einheitliche Namen erleichtern die Zusammenarbeit:

Prefix
Verwendung
feature/
Neue Funktionen (feature/vlan-200)
bugfix/
Fehlerbehebungen (bugfix/wrong-subnet)
hotfix/
Dringende Fixes für Produktion
refactor/
Code-Verbesserungen (refactor/yaml-structure)
docs/
Dokumentationsänderungen

5. Merge-Konflikte verstehen und lösen

Ein Merge-Konflikt passiert, wenn zwei Leute die gleiche Zeile in der gleichen Datei geändert haben. Git kann nicht automatisch entscheiden, welche Version richtig ist – Sie müssen helfen.

5.1 Wie ein Konflikt entsteht

Situation:
                      
Alice (main):        Bob (feature/vlan):
─────────────        ───────────────────
vlan_id: 100         vlan_id: 200     ← Gleiche Zeile!
name: Prod           name: Dev

Beim Merge: 💥 KONFLIKT!
Git weiß nicht: 100 oder 200?

5.2 Konflikt erkennen

📄 Terminal
# Merge versuchen
git merge feature/vlan-200

# Ausgabe bei Konflikt:
# Auto-merging fabric.yaml
# CONFLICT (content): Merge conflict in fabric.yaml
# Automatic merge failed; fix conflicts and then commit the result.

# Status zeigt:
git status
# both modified: fabric.yaml

5.3 Konflikt in der Datei

So sieht ein Konflikt in der Datei aus:

📄 fabric.yaml
vlans:
<<<<<<< HEAD
  - id: 100
    name: Produktion
=======
  - id: 200
    name: Entwicklung
>>>>>>> feature/vlan-200

Die Konflikt-Marker erklärt:

  • <<<<<<< HEAD – Beginn Ihrer aktuellen Version (main)
  • ======= – Trennlinie zwischen den Versionen
  • >>>>>>> feature/vlan-200 – Ende der anderen Version

5.4 Konflikt lösen

Sie haben drei Optionen:

📄 fabric.yaml
# Option 1: NUR Ihre Version behalten
vlans:
  - id: 100
    name: Produktion

# Option 2: NUR die andere Version behalten
vlans:
  - id: 200
    name: Entwicklung

# Option 3: BEIDE kombinieren (meistens die beste Lösung!)
vlans:
  - id: 100
    name: Produktion
  - id: 200
    name: Entwicklung

Nach dem Editieren:

📄 Terminal
# Konflikt ist gelöst - Datei stagen
git add fabric.yaml

# Merge abschließen
git commit -m "Merge feature/vlan-200: Beide VLANs behalten"

# Push
git push
💡Konflikte vermeiden
  • Kleine, fokussierte Commits (weniger Überlappung)
  • Regelmäßig git pull ausführen
  • Kurze Branch-Lebenszeiten
  • Mit dem Team kommunizieren: "Ich arbeite an fabric.yaml!"

6. Git History und Logs verstehen

Die Git-History ist Ihr Protokoll aller Änderungen. Richtig genutzt, beantwortet sie Fragen wie: "Wer hat das geändert?", "Wann wurde das eingeführt?" und "Was war der Grund?"

6.1 git log – Die Historie durchsuchen

📄 Terminal
# Einfache Historie (kompakt)
git log --oneline
# a1b2c3d VLAN 100 hinzugefügt
# d4e5f6g BGP Peer konfiguriert
# 7h8i9j0 Initial commit

# Letzte 5 Commits mit Details
git log -5

# Schöne grafische Darstellung
git log --oneline --graph --all

# Nach Autor filtern
git log --author="alice" --oneline

# Nach Datum filtern
git log --since="2024-01-01" --until="2024-01-31"

# Nach Suchbegriff in Commit-Message
git log --grep="VLAN" --oneline

# Änderungen an einer bestimmten Datei
git log --oneline -- fabric.yaml

# Mit Diff (was wurde geändert?)
git log -p -2  # Letzte 2 Commits mit Änderungen

6.2 git diff – Unterschiede anzeigen

📄 Terminal
# Nicht gestaged Änderungen vs. letzte Version
git diff

# Gestagte Änderungen vs. letzte Version
git diff --staged

# Unterschied zwischen zwei Commits
git diff a1b2c3d d4e5f6g

# Unterschied zwischen Branches
git diff main feature/vlan-200

# Nur Dateinamen anzeigen (nicht den Inhalt)
git diff --name-only main feature/vlan-200

# Änderungen einer bestimmten Datei
git diff fabric.yaml

6.3 git blame – Wer hat diese Zeile geschrieben?

Das mächtigste Werkzeug für Debugging: Zeigt für jede Zeile, wer sie zuletzt geändert hat.

📄 Terminal
# Blame für eine Datei
git blame fabric.yaml

# Ausgabe:
# a1b2c3d (Alice  2024-01-15 10:30)  vlans:
# a1b2c3d (Alice  2024-01-15 10:30)    - id: 100
# d4e5f6g (Bob    2024-01-16 14:22)      name: Produktion  ← Bob hat das geändert!
# 7h8i9j0 (Alice  2024-01-15 10:30)    - id: 200

# Nur bestimmte Zeilen (10-20)
git blame -L 10,20 fabric.yaml

# Ignoriert Whitespace-Änderungen
git blame -w fabric.yaml
💡Blame ohne Schuldzuweisung

Trotz des Namens geht es bei git blame nicht um Schuld! Es ist ein Werkzeug, um herauszufinden, wen Sie nach dem "Warum" einer Änderung fragen können. Die Person weiß am besten, was sie sich dabei gedacht hat.

6.4 git show – Details zu einem Commit

📄 Terminal
# Details zum letzten Commit
git show

# Details zu einem spezifischen Commit
git show a1b2c3d

# Nur die geänderten Dateinamen
git show --stat a1b2c3d

# Eine bestimmte Datei aus einem alten Commit anzeigen
git show a1b2c3d:fabric.yaml

6.5 Änderungen rückgängig machen

📄 Terminal
# Lokale Änderungen verwerfen (nicht gestaged)
git restore fabric.yaml

# Gestagte Änderungen zurück ins Working Directory
git restore --staged fabric.yaml

# Letzten Commit rückgängig machen (behält Änderungen)
git reset --soft HEAD~1

# Letzten Commit komplett löschen (Änderungen weg!)
git reset --hard HEAD~1

# Einen Commit "umkehren" (neuer Commit, der alte Änderung rückgängig macht)
git revert a1b2c3d
# ☝️ Sicher für geteilte Branches! Erzeugt neuen Commit.
⚠️Reset vs. Revert
  • git reset – Ändert die History. Niemals auf geteilten Branches nutzen!
  • git revert – Erstellt neuen Commit. Sicher für geteilte Branches.

Faustregel: Alles, was Sie gepusht haben, nur mit revert rückgängig machen!

7. Praxis-Übungen

Jetzt wird es praktisch! Die folgenden 6 Übungen decken alle wichtigen Git-Operationen ab. Arbeiten Sie diese der Reihe nach durch.

🔧Übung 1: Repository klonen und erkunden (10 Min)

Klonen Sie das Schulungsrepository und machen Sie sich damit vertraut.

  1. Repository klonen:
    📄 Terminal
    git clone https://gitlab.local/schulung/ihr-name.git
cd ihr-name
  2. Struktur erkunden:
    📄 Terminal
    # Was ist im Ordner?
ls -la

# Git-Ordner anschauen (hier ist die Magic!)
ls -la .git

# Aktueller Status
git status

# Welcher Branch?
git branch

# Remotes konfiguriert?
git remote -v
  3. Historie anschauen:
    📄 Terminal
    # Commit-History
git log --oneline -10

# Grafische Darstellung
git log --oneline --graph --all
✅ Erfolgreich wenn: Sie im geklonten Repository sind und die History sehen können.
🔧Übung 2: Erste Änderung committen (15 Min)

Erstellen Sie eine neue Datei und committen Sie diese.

  1. Neue YAML-Datei erstellen:
    📄 Terminal
    cat > vlans.yaml << 'EOF'
# VLAN-Konfiguration für mein Netzwerk
vlans:
  - id: 100
    name: Produktion
    description: Produktionsserver

  - id: 200
    name: Entwicklung
    description: Entwicklungsumgebung
EOF
  2. Status prüfen – Datei ist "untracked":
    📄 Terminal
    git status
# Untracked files:
#   vlans.yaml
  3. Datei stagen:
    📄 Terminal
    git add vlans.yaml

git status
# Changes to be committed:
#   new file: vlans.yaml (grün!)
  4. Commit erstellen:
    📄 Terminal
    git commit -m "VLAN-Konfiguration hinzugefügt: Prod + Dev"

# Erfolgsmeldung:
# [main abc1234] VLAN-Konfiguration hinzugefügt: Prod + Dev
#  1 file changed, 11 insertions(+)
  5. Push zum Server:
    📄 Terminal
    git push
✅ Erfolgreich wenn: Ihr Commit in GitLab sichtbar ist.
🔧Übung 3: Branch erstellen und wechseln (15 Min)

Erstellen Sie einen Feature-Branch und arbeiten Sie darin.

  1. Neuen Branch erstellen:
    📄 Terminal
    # Branch erstellen UND wechseln
git checkout -b feature/vlan-300

# Prüfen, auf welchem Branch wir sind
git branch
# * feature/vlan-300
#   main
  2. Änderung im neuen Branch machen:
    📄 Terminal
    cat >> vlans.yaml << 'EOF'

  - id: 300
    name: Gaeste
    description: Gastnetzwerk mit Internet-Zugang
EOF
  3. Committen:
    📄 Terminal
    git add vlans.yaml
git commit -m "VLAN 300 für Gäste hinzugefügt"
  4. Branch zum Server pushen:
    📄 Terminal
    git push -u origin feature/vlan-300
# ☝️ -u setzt den "upstream" für künftige Pushes
  5. Branches vergleichen:
    📄 Terminal
    # Was ist in feature, aber nicht in main?
git log main..feature/vlan-300 --oneline

# Unterschiede anzeigen
git diff main feature/vlan-300
✅ Erfolgreich wenn: In GitLab erscheint der neue Branch mit Ihrem Commit.
🔧Übung 4: Merge durchführen (10 Min)

Mergen Sie Ihren Feature-Branch zurück in main.

  1. Zurück zum main Branch:
    📄 Terminal
    git checkout main

# Prüfen: VLAN 300 ist hier noch NICHT!
cat vlans.yaml
  2. Feature-Branch mergen:
    📄 Terminal
    git merge feature/vlan-300

# Ausgabe:
# Updating abc1234..def5678
# Fast-forward
#  vlans.yaml | 4 ++++
#  1 file changed, 4 insertions(+)
  3. Ergebnis prüfen:
    📄 Terminal
    # Jetzt ist VLAN 300 auch in main!
cat vlans.yaml

# Log zeigt den Merge
git log --oneline -5
  4. Push und aufräumen:
    📄 Terminal
    git push

# Feature-Branch lokal löschen
git branch -d feature/vlan-300

# Feature-Branch remote löschen
git push origin --delete feature/vlan-300
✅ Erfolgreich wenn: VLAN 300 ist jetzt im main Branch auf GitLab.
🔧Übung 5: Merge-Konflikt simulieren und lösen (20 Min)

Diese Übung simuliert einen echten Merge-Konflikt – die wichtigste Übung!

  1. Zwei Branches erstellen, die das Gleiche ändern:
    📄 Terminal
    # Stellen Sie sicher, Sie sind auf main
git checkout main

# Branch A erstellen
git checkout -b feature/mtu-change-alice

# MTU ändern
cat > interfaces.yaml << 'EOF'
interfaces:
  Ethernet1:
    description: Uplink to Spine
    mtu: 9000
EOF

git add interfaces.yaml
git commit -m "MTU auf 9000 gesetzt (Jumbo Frames)"
  2. Zurück zu main und zweiten Branch erstellen:
    📄 Terminal
    git checkout main

# Branch B erstellen (basiert auf main OHNE Alices Änderung!)
git checkout -b feature/mtu-change-bob

# Bob setzt anderen MTU-Wert
cat > interfaces.yaml << 'EOF'
interfaces:
  Ethernet1:
    description: Uplink to Spine
    mtu: 1500
EOF

git add interfaces.yaml
git commit -m "MTU auf Standard 1500 belassen"
  3. Alice zuerst mergen (kein Problem):
    📄 Terminal
    git checkout main
git merge feature/mtu-change-alice
# ✅ Fast-forward, alles gut
  4. Bob mergen → KONFLIKT!
    📄 Terminal
    git merge feature/mtu-change-bob

# 💥 CONFLICT (content): Merge conflict in interfaces.yaml
# Automatic merge failed; fix conflicts and then commit.

git status
# both modified: interfaces.yaml
  5. Konflikt anschauen:
    📄 interfaces.yaml
    interfaces:
  Ethernet1:
    description: Uplink to Spine
<<<<<<< HEAD
    mtu: 9000
=======
    mtu: 1500
>>>>>>> feature/mtu-change-bob
  6. Konflikt lösen – Sie entscheiden für 9000:
    📄 Terminal
    cat > interfaces.yaml << 'EOF'
interfaces:
  Ethernet1:
    description: Uplink to Spine
    mtu: 9000
EOF
  7. Merge abschließen:
    📄 Terminal
    git add interfaces.yaml
git commit -m "Merge: MTU 9000 beibehalten (Jumbo Frames benötigt)"
git push
  8. Aufräumen:
    📄 Terminal
    git branch -d feature/mtu-change-alice
git branch -d feature/mtu-change-bob
✅ Erfolgreich wenn: Sie verstanden haben, wie Konflikte entstehen und gelöst werden!
🔧Übung 6: History analysieren (15 Min)

Nutzen Sie die Git-Werkzeuge, um die Historie zu verstehen.

  1. Commit-Historie durchsuchen:
    📄 Terminal
    # Alle Commits anzeigen
git log --oneline

# Commits mit MTU im Namen finden
git log --grep="MTU" --oneline

# Grafische Darstellung (zeigt Merge)
git log --oneline --graph --all
  2. Blame nutzen:
    📄 Terminal
    # Wer hat welche Zeile geschrieben?
git blame interfaces.yaml

# Blame für vlans.yaml
git blame vlans.yaml
  3. Änderungen zwischen Commits:
    📄 Terminal
    # Ersten und letzten Commit-Hash finden
git log --oneline

# Diff zwischen zwei Commits
git diff <erster-hash> <letzter-hash>

# Was hat sich an einer Datei geändert?
git log -p vlans.yaml
  4. Einen alten Zustand anschauen (ohne zu ändern!):
    📄 Terminal
    # Datei aus altem Commit anzeigen (NICHT auschecken!)
git show HEAD~3:vlans.yaml

# Zurück zur aktuellen Version
git checkout main
✅ Erfolgreich wenn: Sie die Änderungshistorie Ihrer Dateien verstehen und navigieren können.

8. Cheat Sheet & Troubleshooting

📋 Git Cheat Sheet – Komplettübersicht

Basis-Befehle

git init
Neues Repo erstellen
git clone <url>
Repo klonen
git status
Status anzeigen
git add .
Alle Änderungen stagen
git add <datei>
Datei stagen
git commit -m "msg"
Commit erstellen
git push
Zum Server hochladen
git pull
Vom Server holen

Branches

git branch
Branches auflisten
git branch <name>
Branch erstellen
git checkout <name>
Branch wechseln
git checkout -b <name>
Erstellen + wechseln
git merge <branch>
Branch mergen
git branch -d <name>
Branch löschen

Historie

git log --oneline
Kompakte Historie
git log --graph
Grafische Historie
git diff
Änderungen anzeigen
git diff --staged
Gestagte Änderungen
git blame <datei>
Zeilenweise Autor
git show <commit>
Commit-Details

Rückgängig machen

git restore <datei>
Lokale Änderung verwerfen
git restore --staged <datei>
Unstagen
git revert <commit>
Commit rückgängig (sicher!)
git reset --soft HEAD~1
Letzten Commit aufheben
git reset --hard HEAD~1
⚠️ Commit + Änderungen weg!

🔥 Häufige Fehler und Lösungen

❌ "fatal: not a git repository"

Sie sind nicht in einem Git-Ordner.

✅ cd /pfad/zum/repository
❌ "Your branch is behind origin/main"

Jemand hat Änderungen gepusht, die Sie noch nicht haben.

✅ git pull
❌ "error: failed to push some refs"

Der Server hat neuere Commits als Sie.

✅ git pull --rebase && git push
❌ "You have unstaged changes"

Sie wollen den Branch wechseln, haben aber ungespeicherte Änderungen.

✅ git stash && git checkout <branch> && git stash pop
❌ "Merge conflict in ..."

Zwei Änderungen an der gleichen Stelle.

✅ Datei öffnen, Marker entfernen, git add, git commit
❌ "Permission denied (publickey)"

SSH-Key nicht konfiguriert oder falsch.

✅ ssh-add ~/.ssh/id_rsa oder HTTPS statt SSH nutzen
❌ Falschen Commit gepusht!

Ein Commit auf dem Server muss rückgängig gemacht werden.

✅ git revert <commit-hash> && git push

⚠️ NICHT git reset auf geteilten Branches!

⚡ Zeit sparen: Git Aliases einrichten

Fügen Sie diese Zeilen zu Ihrer ~/.gitconfig hinzu:

📄 ~/.gitconfig
[alias]
    # Kurzbefehle
    st = status
    co = checkout
    br = branch
    ci = commit
    
    # Schöne Logs
    lg = log --oneline --graph --all
    last = log -1 HEAD
    
    # Schnelles Committen
    ac = !git add -A && git commit -m
    
    # Branch-Übersicht
    branches = branch -a
    
    # Wer hat was gemacht?
    who = shortlog -sne

Nutzung: git st statt git status,git lg für schöne Logs, etc.

Zusammenfassung

✅ Das haben Sie gelernt

Konzepte

  • ☑️ Die drei Zonen: Working Dir, Staging, Repository
  • ☑️ Branches als parallele Entwicklungslinien
  • ☑️ GitFlow vs. Trunk-Based Development
  • ☑️ Wie Merge-Konflikte entstehen und gelöst werden

Praktische Skills

  • ☑️ Repository klonen und erkunden
  • ☑️ Änderungen committen und pushen
  • ☑️ Branches erstellen, wechseln, mergen
  • ☑️ History mit log, diff, blame analysieren
  • ☑️ Konflikte erkennen und lösen
ℹ️Nächste Schritte

Im nächsten Modul lernen Sie GitLab kennen – die Plattform, die Git um Merge Requests, CI/CD-Pipelines und Kollaborationsfeatures erweitert. Dort setzen wir alles zusammen, was Sie hier gelernt haben!

Weiter zu Modul 3: GitLab →