Tages-Workshop

Git wirklich verstehen & sicher nutzen

Von „Was ist das & wozu" über das mentale Modell und die tägliche Praxis bis zum eigenen Git-Server im Container — durchgängig im integrierten Terminal deiner IDE (VS Code, Cursor, Antigravity), unterstützt von Claude Code. In 9 Stufen.

Worum geht's?

Git ist das Versionskontrollsystem, das festhält, wer was wann warum geändert hat — und dir erlaubt, jederzeit zurückzugehen. Du lernst hier nicht nur Befehle, sondern das mentale Modell dahinter, die typischen Rettungs-Rezepte und die Plattform-Landschaft bis zum Self-Hosting.

Git ist IDE-unabhängig: Wir zeigen es im integrierten Terminal — das funktioniert in VS Code genauso wie in Cursor oder Antigravity. Die Befehle und Konzepte sind überall identisch; nur die Oberfläche drumherum sieht etwas anders aus.

Dieses Portal ist beides: Live-Präsentation für den Workshop und Selbstlern-Kurs zum Durchklicken. Dein Fortschritt wird lokal gespeichert.

? Für wen ist Git wichtig?

Längst nicht nur für Entwickler:innen — überall, wo Dateien über die Zeit verändert werden.

💻
Entwickler:innen
Code versionieren, zusammenarbeiten, Releases.
⚙️
DevOps / Admins
Infrastructure as Code, Konfig, Deploy-Skripte.
📊
Data & Analyse
Skripte, Notebooks, reproduzierbare Auswertungen.
📝
Doku / Redaktion
„Docs as Code" — Texte mit Verlauf & Review.
🔬
Wissenschaft
Reproduzierbarkeit & Nachvollziehbarkeit.
🤖
Alle, die KI nutzen
Git = Sicherheitsnetz für KI-Änderungen (Stufe 9).

🧠 Das mentale Modell in einem Bild

Git ist kein Backup-Knopf, sondern eine Kette von Schnappschüssen (Commits). Jeder zeigt auf seinen Vorgänger.

c1 c2 c3 c4 main

Jeder Punkt = ein Commit (ein gespeicherter Stand mit Nachricht). Ein Branch ist nur ein Zeiger auf einen dieser Punkte — Verzweigen und Zusammenführen lernst du in Stufe 3 und 5.

🛟 Git & KI gehören zusammen

Sicherheitsnetz für KI-Änderungen: Wenn Claude Code viele Dateien ändert, willst du jederzeit zurückkönnen. Git macht jede Änderung sichtbar und umkehrbar. Die Schwester-Schulung „Claude Code in Cursor" zeigt das Bauen — diese hier das Absichern.

🗺️ Die 9 Stufen

Keine Vorkenntnisse nötig. Einfache Terminal- und Datei-Grundlagen helfen. Module 1–5 funktionieren auch als kompakter Halbtag.
Stufe 1

Was ist Git & wozu?

Warum „Datei-Kopien mit Datum im Namen" nicht skalieren — und was Git stattdessen tut.

1 Das Chaos ohne Versionskontrolle

Jeder kennt es: Dateien werden kopiert, umbenannt, gemailt. Niemand weiß mehr, welche die aktuelle ist.

😵 Ohne Git: Datei-Kopien
✓ Mit Git: ein Verlauf
✗ Ordner-Chaos
  • angebot.docx
  • angebot_final.docx
  • angebot_final_v2.docx
  • angebot_final_WIRKLICH.docx
  • Wer hat was geändert? Unklar.
✓ Mit Git
  • Eine Datei, viele Versionen im Verlauf
  • Jede Änderung mit Autor, Zeit & Warum
  • Jederzeit zu einem alten Stand zurück
  • Mehrere Leute parallel, ohne sich zu überschreiben

2 Git in einem Satz

Git ist ein verteiltes Versionskontrollsystem: Es speichert die komplette Historie deiner Dateien als Kette von Schnappschüssen — bei jedem Beteiligten vollständig lokal, nicht nur auf einem zentralen Server.

„Verteilt" heißt: Du hast die ganze Geschichte auf deinem Rechner und kannst auch offline committen. Ein Server (GitHub, Forgejo …) ist nur ein gemeinsamer Treffpunkt zum Austauschen — kein Single Point of Failure.

3 Was du davon hast

⏪
Zurückgehen
Jeder alte Stand ist erreichbar — nichts geht „aus Versehen" verloren.
👥
Zusammenarbeit
Mehrere arbeiten parallel und führen Änderungen sauber zusammen.
🔍
Nachvollziehbarkeit
Wer/was/wann/warum — der Verlauf beantwortet es.
🧪
Experimentieren
In einem Branch ausprobieren, ohne den Hauptstand zu gefährden.

✓ Geschafft, wenn du …

Stufe 2

Eine kurze Geschichte

Woher Git kommt — und warum das erklärt, wie es heute funktioniert.

1 Der Zeitstrahl

Git entstand aus einem echten Konflikt im Linux-Kernel-Projekt. Das prägt bis heute sein „verteiltes" Wesen.

~2000Zentrale Systeme (CVS, SVN)
Ein zentraler Server hält die Historie. Offline arbeiten? Kaum. Server weg = Historie weg.
2002Linux-Kernel nutzt BitKeeper
Ein verteiltes, aber proprietäres System — kostenlos nutzbar, solange man brav ist.
2005Der Bruch
Die freie Lizenz von BitKeeper wird entzogen. Der Kernel braucht dringend Ersatz.
2005Linus Torvalds baut Git
In wenigen Wochen — Ziele: schnell, verteilt, integritätssicher (Hashes). Für den Kernel gebaut, für die Welt.
2008GitHub
Macht Git per Web-UI massentauglich; „Pull Request" wird zum Standard-Workflow.
HeuteÖkosystem
GitHub, GitLab, Codeberg sowie self-hostbar mit Gitea und Forgejo (mehr in Stufe 7/8).

2 Warum „verteilt" der Kern ist

Weil Git für ein weltweit verteiltes Team (Kernel-Entwickler) gebaut wurde, hat jeder die volle Historie. Das macht es robust, schnell und offline-fähig — und ist der Grund, warum ein Server nur „ein Treffpunkt" ist.

✓ Geschafft, wenn du …

Stufe 3

Das mentale Modell

Wenn du diese drei Bereiche und die Zeiger verstehst, ergibt der Rest sich fast von selbst.

1 Die drei Bereiche

Eine Änderung wandert in zwei Schritten in die Historie. Klick dich durch.

Working Dir

 
datei.txt

Staging

git add

Repository

git commit
Schritt 1: Änderung fürs nächste Commit vormerken.

Die Staging Area ist Gits Besonderheit: Du entscheidest bewusst, was in den nächsten Commit kommt — nicht zwangsläufig alles, was du geändert hast.

2 Commits, Hashes & HEAD

  • Commit — ein gespeicherter Schnappschuss mit Nachricht, Autor, Zeit.
  • Hash — die eindeutige ID eines Commits (z. B. a1b2c3d). Ändert sich der Inhalt, ändert sich der Hash → Manipulation fällt auf.
  • HEAD — ein Zeiger auf „wo du gerade stehst" (meist die Spitze deines Branches).
  • Branch — nur ein beweglicher Zeiger auf einen Commit. Neuer Branch = neues Etikett, kein Kopieren von Dateien.

3 Branches sind billig

Verzweigen heißt: ein zweiter Zeiger läuft eigene Wege und wird später wieder zusammengeführt.

c1 c2 c3 c4 main
f1 f2 feature

feature zweigt bei c2 ab. Später wird er nach main gemerged (Stufe 5).

✓ Geschafft, wenn du …

Stufe 4

Tägliche Praxis

Die Handvoll Befehle, die 90 % des Alltags abdecken — im integrierten Terminal deiner IDE.

1 Vom leeren Ordner zum ersten Commit

Terminal — VS Code / Cursor / Antigravity
  • git init — macht den Ordner zum Repository.
  • git add <datei> — merkt Änderungen fürs nächste Commit vor (Staging).
  • git commit -m "…" — speichert den Schnappschuss mit Nachricht.
  • git status / git log / git diff — Stand, Verlauf, Unterschiede.

2 .gitignore — was nicht ins Repo gehört

i.gitignore (Beispiel)
# Abhängigkeiten & Build
node_modules/
dist/
# Geheimnisse & lokale Konfig
.env
*.key
Wichtig: Secrets (Tokens, Passwörter) gehören nie ins Repo. Mehr dazu in Stufe 6 (falls doch passiert) und Stufe 8.

3 Branch, Merge, Remote

⎇Die wichtigsten Befehle
git switch -c feature   # neuen Branch anlegen & hinwechseln
git merge feature      # Branch in den aktuellen zusammenführen
git push               # Commits zum Server schicken
git pull               # Commits vom Server holen & einbauen
git fetch              # nur holen, noch nicht einbauen

4 Claude Code hilft beim Committen

Im integrierten Terminal deiner IDE musst du Befehle nicht auswendig können — beschreibe, was du willst.

Du

Schau dir meine Änderungen an und committe sie mit einer aussagekräftigen Nachricht.

Claude Code

Ich sehe Änderungen an app.js (Filter case-insensitive). Vorschlag: fix: Suche unabhängig von Groß-/Kleinschreibung. Soll ich git add + git commit ausführen?

VS Code — Source Control
Skizze
Schematisch: das „Source Control"-Panel (in VS Code, Cursor & Antigravity nahezu identisch) zeigt geänderte (M), neue (A) und gelöschte (D) Dateien — dieselben, die Claude Code committet.

✓ Geschafft, wenn du …

Stufe 5

Zusammenarbeit

Feature-Branches, Pull Requests, das ewige Merge-vs-Rebase und das Lösen von Konflikten.

1 Der Feature-Branch-Workflow

  1. Für jede Aufgabe einen eigenen Branch: git switch -c feature/login.
  2. Dort committen, bis das Feature fertig ist.
  3. Branch pushen und einen Pull Request (Merge Request) öffnen.
  4. Review → mergen → Branch löschen.
Pull Request (PR): die Bitte „bitte meine Änderungen in main übernehmen", inklusive Diff, Diskussion und Review — das Herzstück der Team-Arbeit.

2 Merge vs. Rebase

Zwei Wege, einen Branch auf den Stand von main zu bringen. Beide gültig — mit unterschiedlichem Ergebnis im Verlauf.

⛙ Merge
  • Erzeugt einen Merge-Commit
  • Historie bleibt wie sie war (ehrlich, verzweigt)
  • Sicher für geteilte Branches
⮃ Rebase
  • Setzt Commits neu auf die Spitze von main
  • Ergibt eine lineare, aufgeräumte Historie
  • Regel: nie bereits gepushte/geteilte Commits rebasen

Sieh dir den Unterschied im Verlauf an:

Faustregel: Rebase lokal zum Aufräumen, bevor du pushst. Geteilte Historie wird gemerged.

3 Konflikte lösen — mit Claude Code

Ein Konflikt entsteht, wenn zwei Seiten dieselbe Zeile unterschiedlich geändert haben. Git markiert die Stelle, du entscheidest.

Terminal — Merge-Konflikt
› git merge feature/login CONFLICT (content): Merge conflict in app.js Automatic merge failed; fix conflicts and commit.
Du

Erkläre mir den Merge-Konflikt in app.js und schlage eine Auflösung vor, die beide Änderungen behält.

Claude Code

Beide Seiten ändern die Funktion login(): main fügt ein Log hinzu, dein Branch die Validierung. Vorschlag: beides kombinieren. Soll ich die Konfliktmarker auflösen und committen?

4 Tags & Releases

git tag v1.0.0 markiert einen Stand als Version. Plattformen machen daraus „Releases" mit Download & Changelog.

✓ Geschafft, wenn du …

Stufe 6

Rettung & Fortgeschrittenes

„Mist — rückgängig!" Für fast jede Situation gibt es ein passendes Rezept.

1 Das richtige Undo wählen

Wähle dein Szenario — Git hat für jedes ein eigenes Werkzeug.

2 Detektivarbeit: blame & bisect

  • git blame <datei> — zeigt zeilenweise, wer was wann geändert hat.
  • git bisect — findet per binärer Suche den Commit, der einen Bug eingeführt hat.

3 Secrets aus der Historie entfernen (DSGVO)

Achtung: Ein versehentlich committetes Passwort ist auch nach dem Löschen noch in der Historie. Es muss aus allen Commits entfernt werden (z. B. mit git filter-repo) und das Secret sofort widerrufen/neu erstellt werden — denn es war öffentlich. Danach Historie neu pushen (force) und Team informieren.

✓ Geschafft, wenn du …

Stufe 7

Die Hosting-Landschaft

Git läuft lokal — geteilt wird über eine Plattform. Welche passt zu dir?

1 Die großen Anbieter

🐙
GitHub
Größtes Ökosystem, viele Integrationen. Microsoft. US-Cloud.
🦊
GitLab
Stark in CI/CD & DevOps; self-hostbar (Community Edition).
🏔️
Codeberg
Non-Profit aus Deutschland, läuft auf Forgejo. DSGVO-freundlich.

2 Self-Hosting: Gitea vs. Forgejo

Beide sind leichtgewichtige, self-hostbare Git-Server (ein Binary, wenig Ressourcen). Forgejo ist 2022 als Community-Fork aus Gitea entstanden.

🍵 Gitea
  • Ausgereift, große Verbreitung
  • Hinter einer Firma (Gitea Ltd.)
  • Sehr feature-reich
🌳 Forgejo
  • Community-/Non-Profit-getrieben (Codeberg e. V.)
  • Fork aus Gitea — vertraute Bedienung
  • Fokus auf Unabhängigkeit & Governance
Empfehlung für diese Schulung: Forgejo — offene Governance, läuft schlank im Container. Genau das bauen wir in Stufe 8.

3 So sieht eine self-hostbare Oberfläche aus

Browser — git.deinedomain.de
Skizze
Schematisch: Repo-Übersicht in Forgejo — vertraut für alle, die GitHub/Gitea kennen.
DSGVO: Self-Hosting oder ein EU-Anbieter (Codeberg) gibt dir Kontrolle über den Standort deiner Daten — relevant für viele Firmen.

✓ Geschafft, wenn du …

Stufe 8

Self-Hosting: Forgejo im Container

Dein eigener Git-Server auf dem VPS — mit Docker und Caddy, in wenigen Schritten.

1 Die docker-compose.yml

🐳docker-compose.yml (Forgejo)
services:
  forgejo:
    image: codeberg.org/forgejo/forgejo:latest
    container_name: forgejo
    restart: always
    environment: [ "USER_UID=1000", "USER_GID=1000" ]
    volumes: [ "./forgejo-data:/data" ]   # Persistenz: alle Repos
    ports: [ "3000:3000", "2222:22" ]      # Web-UI + Git-SSH
Das Volume ./forgejo-data ist entscheidend: Es hält alle Repos und Einstellungen über Container-Neustarts hinweg. (Gitea: image: gitea/gitea:latest.)

2 Caddy als Reverse Proxy (HTTPS automatisch)

🔒Caddyfile
git.deinedomain.de {
    reverse_proxy localhost:3000
}
Caddy holt automatisch ein Let's-Encrypt-Zertifikat und leitet auf Forgejo (Port 3000). Voraussetzung: ein DNS-Eintrag git.deinedomain.de → deine Server-IP.

3 Starten & erstes Repo pushen

Terminal — VPS
› docker compose up -d ✔ Container forgejo Started → Web-Setup unter https://git.deinedomain.de aufrufen › git remote add origin git@git.deinedomain.de:max/projekt.git › git push -u origin main ✓ Branch 'main' nach origin gepusht.
Browser — Forgejo Erst-Setup
Skizze
Schematisch: das einmalige Web-Setup von Forgejo. Danach legst du Repos an und pushst wie gewohnt.

4 Backup nicht vergessen

Backup = das Volume sichern. Regelmäßig forgejo-data/ sichern (z. B. per Cron + restic/rsync). Damit liegt deine komplette Git-Plattform in einem Ordner.

✓ Geschafft, wenn du …

Stufe 9

Git & Claude Code

Der Kreis schließt sich: Git ist das Sicherheitsnetz, das KI-Arbeit erst sorgenfrei macht.

1 Warum gerade bei KI-Änderungen

Ein Agent ändert schnell viel. Mit Git ist jede dieser Änderungen ein nachvollziehbarer, umkehrbarer Schritt. Du reviewst den Diff, committest bewusst — und kannst notfalls sauber zurück.

2 Diffs reviewen lassen

Du

Zeig mir den Diff der letzten Änderungen und erkläre kurz, was sich fachlich ändert. Ist etwas riskant?

Claude Code

3 Dateien geändert. Kernpunkt: die Preisberechnung rundet jetzt kaufmännisch. Achtung: config.json enthält einen API-Key — den solltest du entfernen und in .env auslagern.

Terminal — Review & Commit
› git diff app.js | 12 ++++++-- + const preis = round(netto * 1.19); - const preis = netto * 1.19; › git commit -m "feat: kaufmännische Rundung der Bruttopreise" ✓ committed — jederzeit umkehrbar.

3 Der sichere Rhythmus

  1. Kleine Aufgabe an Claude Code geben.
  2. Diff lesen — verstehst du jede Änderung?
  3. Committen (eine sinnvolle Nachricht pro Schritt).
  4. Lief etwas schief? git restore / git revert — kein Drama.
Zwei Netze: Claude Codes Checkpoints/Rewind für die schnelle Rücknahme in der Sitzung — und Git als dauerhaftes, nachvollziehbares Sicherheitsnetz. Mehr zum Bauen mit dem Agenten in der Claude-Code-Schulung.

✓ Geschafft, wenn du …

Bonus

Git-Cheat-Sheet

Die wichtigsten Befehle zum Mitnehmen. (Zählt nicht für den Fortschritt.)

▶ Alltag

git status
Was ist geändert / gestaged?
git add -p
Änderungen häppchenweise stagen.
git commit -m
Schnappschuss mit Nachricht.
git log --oneline
Kompakter Verlauf.
git switch -c x
Branch anlegen & wechseln.
git pull --rebase
Holen & sauber linear einbauen.

🛟 Rettung

git restore <f>
Datei auf letzten Commit-Stand.
git reset --soft HEAD~1
Letzten Commit lösen, Änderungen behalten.
git revert <hash>
Commit rückgängig — öffentlich-sicher.
git stash
Arbeit kurz beiseitelegen.
git reflog
Rettungsanker: zeigt fast alles, auch „Verlorenes".
git cherry-pick
Einen einzelnen Commit übernehmen.

★ Gute Gewohnheiten

  • Kleine, thematisch klare Commits — eine Sache pro Commit.
  • Aussagekräftige Nachrichten (Claude Code hilft dabei).
  • Niemals Secrets committen; .gitignore früh pflegen.
  • Vor dem Push: Diff lesen. Nach dem Bauen mit KI: Diff lesen.
Lernkontrolle

Quiz

10 Fragen quer durch die Stufen. Ab 8 richtigen Antworten schaltest du dein Zertifikat frei.

Frage 1 von 10
…
Abschluss

Dein Zertifikat

Glückwunsch! Trage deinen Namen ein und drucke das Zertifikat (oder speichere als PDF).

FL
Florian Ludwig
AI Consultant · Kutzschbach INNOVATIONS
Zertifikat
Git in der IDE
Hiermit wird bestätigt, dass
Dein Name hier
den Workshop „Git verstehen & sicher nutzen — in der IDE mit Claude Code" erfolgreich abgeschlossen hat.
—Datum
★GEPRÜFT
Florian LudwigAI Consultant · Kutzschbach INNOVATIONS