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.

ℹ️🖥️ Ihre Arbeitsumgebung: Windows + VS Code + PowerShell

In diesem Workshop arbeiten Sie auf einer Windows VM. Bitte beachten Sie:

  • Öffnen Sie ein Terminal in VS Code über Terminal → New Terminal (PowerShell)
  • Sie arbeiten in PowerShell auf Windows
  • Dateien erstellen/bearbeiten: Nutzen Sie den VS Code Editor (neue Datei erstellen, Inhalt eintippen, speichern)
  • Git-Befehle: Werden im PowerShell-Terminal ausgeführt

📚 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

📄 PowerShell
# 1️⃣ Sie bearbeiten eine Datei in VS Code (Working Directory)
# Öffnen Sie switch-config.yaml in VS Code und bearbeiten Sie sie

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

📄 PowerShell
# 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:

📄 PowerShell
# 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

📄 PowerShell
# 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

📄 PowerShell
# 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

📄 PowerShell
# 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:

📄 PowerShell
# 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

📄 PowerShell
# 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

📄 PowerShell
# 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.

📄 PowerShell
# 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

📄 PowerShell
# 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

📄 PowerShell
# 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 sind in zwei Phasen aufgeteilt:

📋 Phase 1: Lokales Git (Übungen 1-3)

Git-Grundlagen auf der Konsole üben – alles lokal auf Ihrem Desktop, ohne Server.

🌐 Phase 2: GitLab Integration (Übungen 4-6)

Zusammenarbeit mit GitLab – Push, Pull, Merge Requests und Team-Workflows.

⚠️⚙️ Einmalige Vorbereitung: Git konfigurieren

Führen Sie diese Befehle einmalig im PowerShell-Terminal aus:

📄 PowerShell
git config --global user.name "Ihr Name"
git config --global user.email "ihre.email@firma.de"
git config --global http.sslVerify false

Die letzte Zeile ist nötig, weil unser GitLab-Server ein selbstsigniertes SSL-Zertifikat verwendet.

⚠️⚙️ Einmalige Vorbereitung: Git konfigurieren

Führen Sie diese Befehle einmalig im PowerShell-Terminal aus:

📄 PowerShell
git config --global user.name "Ihr Name"
git config --global user.email "ihre.email@firma.de"
git config --global http.sslVerify false

Die letzte Zeile ist nötig, weil unser GitLab-Server ein selbstsigniertes SSL-Zertifikat verwendet.

📋 Phase 1: Lokales Git auf der Konsole

🔧Übung 1: Lokales Repository erstellen und erste Commits (15 Min)

Erstellen Sie ein lokales Git-Repository auf dem Desktop und machen Sie Ihre ersten Commits.

  1. VS Code öffnen und Terminal starten:

    Öffnen Sie VS Code über das Desktop-Icon. Dann öffnen Sie ein Terminal über das Menü: Terminal → New Terminal (oder Tastenkürzel Ctrl+`). Unten erscheint ein PowerShell-Terminal, in dem Sie alle Git-Befehle ausführen.

    VS Code mit geöffnetem PowerShell-Terminal unten: Terminal → New Terminal
    🔍 Vergrößern
    VS Code: Terminal öffnen über Terminal → New Terminal
  2. Zum Desktop navigieren und Ordner erstellen:
    📄 PowerShell
    cd ~\Desktop
mkdir git-uebung
cd git-uebung
  3. Git-Repository initialisieren:
    📄 PowerShell
    git init

# Repository erkunden
git status

# Welcher Branch? (sollte main oder master sein)
git branch
  4. Ordner in VS Code öffnen und erste Datei erstellen:

    Öffnen Sie zuerst den erstellten Ordner in VS Code: File → Open Folder und navigieren Sie zu Desktop\git-uebung. Klicken Sie auf "Select Folder".

    Jetzt sehen Sie den leeren Ordner in der Seitenleiste links. Erstellen Sie eine neue Datei, indem Sie in der Seitenleiste auf das 📄 New File Icon klicken (oder Ctrl+N) und die Datei als vlans.yaml speichern. Geben Sie folgenden Inhalt ein:

    VS Code: Ordner git-uebung geöffnet, neue Datei erstellen über das New File Icon in der Seitenleiste
    🔍 Vergrößern
    VS Code: Ordner öffnen und neue Datei erstellen
    📄 vlans.yaml
    # VLAN-Konfiguration für mein Netzwerk
vlans:
  - id: 100
    name: Produktion
    description: Produktionsserver

  - id: 200
    name: Entwicklung
    description: Entwicklungsumgebung
  5. Status prüfen – Datei ist "untracked":
    📄 PowerShell
    git status
# Untracked files:
#   vlans.yaml
  6. Datei stagen und committen:
    📄 PowerShell
    git add vlans.yaml
git status
# Changes to be committed:
#   new file: vlans.yaml (grün!)

git commit -m "VLAN-Konfiguration hinzugefügt: Prod + Dev"

# Erfolgsmeldung:
# [main abc1234] VLAN-Konfiguration hinzugefügt: Prod + Dev
#  1 file changed, 11 insertions(+)
  7. Historie anschauen:
    📄 PowerShell
    git log --oneline
git log
✅ Erfolgreich wenn: git log Ihren ersten Commit anzeigt.
🔧Übung 2: Branches erstellen und mergen (15 Min)

Erstellen Sie einen Feature-Branch, arbeiten Sie darin und mergen Sie zurück.

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

# Prüfen, auf welchem Branch wir sind
git branch
# * feature/vlan-300
#   master
  2. Änderung im neuen Branch machen:

    Öffnen Sie vlans.yaml in VS Code und fügen Sie am Ende folgendes hinzu:

    📄 vlans.yaml (am Ende hinzufügen)
    
  - id: 300
    name: Gaeste
    description: Gastnetzwerk mit Internet-Zugang
  3. Committen:
    📄 PowerShell
    git add vlans.yaml
git commit -m "VLAN 300 für Gäste hinzugefügt"
  4. Zurück zum master Branch und prüfen:
    📄 PowerShell
    git checkout master

# Prüfen: VLAN 300 ist hier noch NICHT!
Get-Content vlans.yaml
  5. Feature-Branch mergen:
    📄 PowerShell
    git merge feature/vlan-300

# Ausgabe:
# Updating abc1234..def5678
# Fast-forward
#  vlans.yaml | 4 ++++
#  1 file changed, 4 insertions(+)
  6. Ergebnis prüfen und aufräumen:
    📄 PowerShell
    # Jetzt ist VLAN 300 auch in main!
Get-Content vlans.yaml

# Log zeigt den Merge
git log --oneline

# Feature-Branch löschen
git branch -d feature/vlan-300
✅ Erfolgreich wenn: VLAN 300 ist im master Branch und der Feature-Branch wurde gelöscht.
🔧Übung 3: Merge-Konflikt simulieren und lösen (20 Min)

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

  1. Stellen Sie sicher, Sie sind auf master:
    📄 PowerShell
    git checkout master
  2. Branch A erstellen – Alice setzt MTU auf 9000:
    📄 PowerShell
    git checkout -b feature/mtu-change-alice

    Erstellen Sie in VS Code eine neue Datei interfaces.yaml mit folgendem Inhalt:

    📄 interfaces.yaml
    interfaces:
  Ethernet1:
    description: Uplink to Spine
    mtu: 9000
    📄 PowerShell
    git add interfaces.yaml
git commit -m "MTU auf 9000 gesetzt (Jumbo Frames)"
  3. Zurück zu master und Branch B erstellen – Bob will MTU 1500:
    📄 PowerShell
    git checkout master
git checkout -b feature/mtu-change-bob

    Erstellen Sie in VS Code die Datei interfaces.yaml (sie existiert auf diesem Branch noch nicht!) mit folgendem Inhalt:

    📄 interfaces.yaml
    interfaces:
  Ethernet1:
    description: Uplink to Spine
    mtu: 1500
    📄 PowerShell
    git add interfaces.yaml
git commit -m "MTU auf Standard 1500 belassen"
  4. Alice zuerst mergen (kein Problem):
    📄 PowerShell
    git checkout master
git merge feature/mtu-change-alice
# ✅ Fast-forward, alles gut
  5. Bob mergen → KONFLIKT!
    📄 PowerShell
    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
  6. Konflikt anschauen und lösen:

    Öffnen Sie interfaces.yaml in VS Code. Sie sehen die Konflikt-Marker. VS Code bietet Ihnen Buttons wie "Accept Current Change", "Accept Incoming Change" oder "Accept Both Changes". Entscheiden Sie sich für MTU 9000 – entfernen Sie die Konflikt-Marker und behalten Sie:

    📄 interfaces.yaml
    interfaces:
  Ethernet1:
    description: Uplink to Spine
    mtu: 9000
  7. Merge abschließen:
    📄 PowerShell
    git add interfaces.yaml
git commit -m "Merge: MTU 9000 beibehalten (Jumbo Frames benötigt)"
  8. Aufräumen:
    📄 PowerShell
    git branch -d feature/mtu-change-alice
git branch -d feature/mtu-change-bob

# Historie mit Merge anschauen
git log --oneline --graph --all
✅ Erfolgreich wenn: Sie verstanden haben, wie Konflikte entstehen und gelöst werden!

🌐 Phase 2: GitLab Integration

ℹ️GitLab-Zugang

Für die folgenden Übungen nutzen Sie den GitLab-Server:

  • URL: https://198.18.133.100/
  • Benutzer: root
  • Passwort: C1sco12345

⚠️ Der Browser wird eine Sicherheitswarnung anzeigen (selbstsigniertes Zertifikat). Klicken Sie auf "Erweitert" → "Weiter zu 198.18.133.100".

🔧Übung 4: GitLab-Projekt erstellen und verbinden (15 Min)

Erstellen Sie ein Projekt in GitLab und verbinden Sie Ihr lokales Repository damit.

  1. In GitLab einloggen und neues Projekt erstellen:
    • Öffnen Sie https://198.18.133.100/ im Browser
    • Login mit root / C1sco12345
    • Klicken Sie auf "New project" → "Create blank project"
    • Projektname: netzwerk-config
    • Deaktivieren Sie "Initialize repository with a README" (wir haben schon ein lokales Repo!)
    • Klicken Sie auf "Create project"
  2. Lokales Repository mit GitLab verbinden:
    📄 PowerShell
    # Stellen Sie sicher, Sie sind in Ihrem lokalen Repo
cd ~\Desktop\git-uebung

# GitLab als Remote hinzufügen
git remote add origin https://198.18.133.100/gitlab-instance-668e631e/netzwerk-config.git

# Prüfen, ob Remote konfiguriert ist
git remote -v
  3. Lokale Commits zu GitLab pushen:
    📄 PowerShell
    git push -u origin master

# Beim ersten Push werden Sie nach Benutzername und Passwort gefragt:
# Username: root
# Password: C1sco12345
  4. In GitLab überprüfen:

    Wechseln Sie zum Browser und laden Sie die Projektseite neu. Sie sollten jetzt Ihre Dateien (vlans.yaml, interfaces.yaml) und alle Commits sehen!

✅ Erfolgreich wenn: Ihre Dateien und Commits in GitLab sichtbar sind.
🔧Übung 5: Mit GitLab arbeiten – Push, Pull & Branches (15 Min)

Üben Sie den Workflow mit GitLab: Änderungen pushen und im Browser überprüfen.

  1. Neuen Branch erstellen und Änderung pushen:
    📄 PowerShell
    git checkout -b feature/bgp-config

    Erstellen Sie in VS Code eine neue Datei bgp.yaml mit folgendem Inhalt:

    📄 bgp.yaml
    # BGP-Konfiguration
bgp:
  local_as: 65001
  router_id: 10.0.0.1
  neighbors:
    - peer: 10.0.0.2
      remote_as: 65002
      description: ISP Uplink
    📄 PowerShell
    git add bgp.yaml
git commit -m "BGP-Konfiguration für ISP Uplink hinzugefügt"

# Branch zu GitLab pushen
git push -u origin feature/bgp-config
  2. In GitLab prüfen:
    • Wechseln Sie im Browser zu GitLab
    • Im Projekt sehen Sie jetzt den Branch feature/bgp-config
    • Klicken Sie auf den Branch und sehen Sie die bgp.yaml Datei
    • Schauen Sie unter "Repository → Commits" die History an
  3. Zurück zu master und mergen:
    📄 PowerShell
    git checkout master
git merge feature/bgp-config
git push

# Aufräumen
git branch -d feature/bgp-config
git push origin --delete feature/bgp-config
  4. In GitLab verifizieren:

    Laden Sie die Projektseite in GitLab neu. Die bgp.yaml sollte jetzt im master Branch sichtbar sein. Der Feature-Branch ist gelöscht.

✅ Erfolgreich wenn: bgp.yaml ist im master Branch auf GitLab sichtbar und der Feature-Branch gelöscht.
🔧Übung 6: Merge Request in GitLab erstellen (20 Min)

Erstellen Sie einen Merge Request (MR) – der professionelle Weg, Änderungen zu integrieren. In echten Teams werden Änderungen niemals direkt gemerged, sondern immer über einen MR mit Review.

  1. Feature-Branch erstellen und Änderung machen:
    📄 PowerShell
    git checkout -b feature/monitoring

    Erstellen Sie in VS Code eine neue Datei monitoring.yaml mit folgendem Inhalt:

    📄 monitoring.yaml
    # Monitoring-Konfiguration
monitoring:
  snmp:
    community: public
    version: 2c
    targets:
      - 10.0.0.1
      - 10.0.0.2
  syslog:
    server: 10.0.100.50
    port: 514
    level: informational
    📄 PowerShell
    git add monitoring.yaml
git commit -m "Monitoring-Konfiguration: SNMP + Syslog"

# Branch zu GitLab pushen
git push -u origin feature/monitoring
  2. Merge Request in GitLab erstellen:
    • Wechseln Sie im Browser zu GitLab
    • GitLab zeigt oben einen Banner: "Create merge request" – klicken Sie darauf
    • Alternativ: Links im Menü "Merge requests" → "New merge request"
    • Source Branch: feature/monitoring
    • Target Branch: master
    • Title: Monitoring-Konfiguration hinzufügen
    • Description: Fügt SNMP und Syslog Monitoring-Konfiguration hinzu
    • Klicken Sie auf "Create merge request"
  3. Merge Request anschauen:
    • Im MR sehen Sie den Tab "Changes" – hier sind alle Änderungen sichtbar
    • Sie können Kommentare zu einzelnen Zeilen hinzufügen (Code Review!)
    • Der Tab "Commits" zeigt alle Commits in diesem MR
  4. Merge Request mergen:
    • Klicken Sie oben auf den Tab "Overview"
    • Klicken Sie auf den blauen Button "Merge"
    • Optional: Aktivieren Sie "Delete source branch" (empfohlen!)
    • Nach dem Merge ist die Änderung im master Branch
  5. Lokal aktualisieren:
    📄 PowerShell
    git checkout master
git pull

# Prüfen: monitoring.yaml sollte jetzt da sein
dir
Get-Content monitoring.yaml

# Lokalen Branch aufräumen
git branch -d feature/monitoring
✅ Erfolgreich wenn: Der Merge Request in GitLab gemerged ist und Sie die Änderung lokal mit git pull geholt haben.

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 C:\Users\admin\Desktop\git-uebung
❌ "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 in VS Code öffnen, Marker entfernen, git add, git commit
❌ SSL certificate problem

Selbstsigniertes Zertifikat auf dem GitLab-Server.

✅ git config --global http.sslVerify false
❌ 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ühren Sie diese Befehle im PowerShell-Terminal aus, um Kurzformen zu konfigurieren:

📄 PowerShell
# Kurzbefehle
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit

# Schöne Logs
git config --global alias.lg "log --oneline --graph --all"
git config --global alias.last "log -1 HEAD"

# Branch-Übersicht
git config --global alias.branches "branch -a"

# Wer hat was gemacht?
git config --global alias.who "shortlog -sne"

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

❓ Quiz: Testen Sie Ihr Git-Wissen (5 Min)

Versuchen Sie, die Fragen ohne Zurückblättern zu beantworten.

1. Welche drei Zonen hat Git und was passiert in jeder?

Antwort anzeigen

Working Directory: Hier bearbeiten Sie Ihre Dateien.
Staging Area: Hier sammeln Sie Änderungen für den nächsten Commit (git add).
Repository: Hier werden Commits dauerhaft gespeichert (git commit).

2. Was ist der Unterschied zwischen git add und git commit?

Antwort anzeigen

git add verschiebt Änderungen in die Staging Area (Vorbereitung).git commit speichert den Inhalt der Staging Area als neuen Snapshot im Repository.

3. Warum sollte man aussagekräftige Commit-Messages schreiben?

Antwort anzeigen

Damit Kollegen (und man selbst in 6 Monaten) nachvollziehen können, warum eine Änderung gemacht wurde. Gute Messages beschreiben das "Was" und "Warum", nicht das "Wie". Beispiel: fix: VLAN 100 auf Leaf-3 korrigiert (falsches Interface)

4. Was macht git log --oneline?

Antwort anzeigen

Zeigt die Commit-Historie in kompakter Form an — ein Commit pro Zeile mit kurzem Hash und Message. Ideal für einen schnellen Überblick über die letzten Änderungen.

5. Wie können Sie eine Änderung rückgängig machen, die Sie noch nicht committed haben?

Antwort anzeigen

Mit git checkout -- dateiname oder git restore dateiname wird die Datei auf den Stand des letzten Commits zurückgesetzt. Bereits gestagete Änderungen erst mitgit restore --staged dateiname unstagen.

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

  • ☑️ Lokales Repository erstellen und erkunden
  • ☑️ Änderungen committen und pushen
  • ☑️ Branches erstellen, wechseln, mergen
  • ☑️ History mit log, diff, blame analysieren
  • ☑️ Konflikte erkennen und lösen
  • ☑️ GitLab: Push, Pull, Merge Requests
ℹ️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 →