Tech-Basics für moderne Teams
Warum jeder der mit KI Code schreibt Git verstehen sollte — und wie es wirklich einfach ist.
Kennt ihr das?
"Ich hab was geändert und jetzt funktioniert nichts mehr."
"Welche Version war nochmal die funktionierende?"
"Ich hab die Datei überschrieben..."
Git löst genau diese Probleme. Für immer.
Was ist Git?
Git macht Fotos von deinem Code — sogenannte Commits. Du kannst jederzeit zurück.
Experimentiere in einem separaten Zweig. Funktioniert's? Zusammenführen. Nicht? Einfach löschen.
GitHub/GitLab ist die Cloud-Kopie. Backup, Teamwork und Deployment in einem.
Warum besonders für Vibe Coder?
Claude schreibt 200 Zeilen — und du weißt nicht mehr was du hattest.
Git zeigt dir genau was sich geändert hat (diff)
Ein Prompt macht alles kaputt.
Ein Commit zurück — fertig, als wäre nichts gewesen
Du willst zwei Ideen parallel ausprobieren.
Branch A und Branch B — kein Überschreiben, kein Stress
Jemand anderes soll deinen Code reviewen oder weiterarbeiten.
GitHub macht das zum Einzeiler: Link teilen, fertig
Das Minimum
Änderungen vorbereiten
Snapshot speichern
In die Cloud laden
Vom Server holen
→ Alles andere (branch, merge, revert, log) lernt man wenn man es braucht.
Das Wichtigste zuerst
Lokal
dein Rechner
Remote (GitHub)
die Cloud-Kopie
Wie Git Daten speichert
Wie "Änderungen verfolgen" in Word — aber für Code. Jede geänderte Zeile wird einzeln erfasst.
git diff — was sich geändert hat
Rote Zeilen = entfernt
Was vorher da war — wird gelöscht
Blaue Zeilen = hinzugefügt
Was neu dazukommt
Graue Zeilen = unverändert
Kontext — werden nicht übertragen
→ Push überträgt also keine ganze Datei. Nur die 2 geänderten Zeilen. Schnell, effizient, und du siehst genau was passiert ist.
Merge Konflikte
Konflikte klingen schlimm. Sind sie nicht. Git markiert sie nur — du entscheidest.
So sieht ein Konflikt aus
Wie du es löst
Git zeigt dir den Konflikt
Die Datei hat jetzt diese Marker drin — du siehst beide Versionen
Du wählst — oder kombinierst
Einfach die Zeile behalten die du willst, den Rest löschen. VS Code hat dafür Buttons: "Accept Current / Incoming / Both"
Committen — fertig
💡 Konflikte entstehen nur wenn exakt dieselbe Zeile von zwei Personen geändert wurde. Verschiedene Zeilen → kein Konflikt, automatisches Merge.
Der Workflow
Neuen Zweig für das Feature erstellen
Mit KI coden, ausprobieren, anpassen
Funktioniert was? Snapshot!
Hochladen, Review, Merge
Best Practice #1
✗ Schlecht
✓ Gut
Tipp: Einfaches Prefix-System — feat: neues Feature · fix: Bugfix · style: nur Aussehen · docs: nur Texte
Best Practice #2
Schritt 1
Branch erstellen für jede neue Idee / jedes Feature
Schritt 2
Auf dem Branch committen bis es funktioniert
Schritt 3
Pull Request → Review → Merge in main
Notfall-Toolkit
"Was hab ich eigentlich geändert?"
"Welche Commits gibt es?"
"Letzten Commit rückgängig?"
"Alles wegschmeißen?"
"Zu altem Stand springen?"
Für Terminal-Phobiker
🖥️
Grafisches Tool direkt von GitHub. Drag & Drop Commits. Perfekt zum Einstieg.
desktop.github.com
💻
Direkt integriert. Klick auf das Branch-Icon unten links — und alles ist da.
Empfehlung für Vibe Coder
🐙
Dateien direkt im Browser bearbeiten. PRs reviewen. Issues tracken.
github.com
Bonus: Claude Code, Cursor und Windsurf haben Git direkt eingebaut — einfach fragen.
Best Practice #3
Ein Commit = eine Sache. Claude schreibt 300 Zeilen auf einmal — commit trotzdem nur was zusammengehört.
✗ Fetter Commit — schwer zu verstehen
→ Unmöglich einzeln rückgängig zu machen
→ Review ist eine Qual
→ "Was hat sich geändert?" — unklar
✓ Atomic Commits — klar & reversibel
→ Jeden Commit einzeln rückgängig: git revert
→ Claude macht einen Schritt → du commitest
→ Perfekte History zum Debuggen
Best Practice #4
Secrets & Keys
Einmal auf GitHub — für immer im Internet. Bots scannen Repos in Sekunden.
Echte Konsequenz: geklaute Keys kosten Geld
Große Dateien
Git speichert jede Version jeder Datei. 500 MB × 10 Commits = 5 GB Repo.
Repo wird unbrauchbar langsam
Generiertes
Wird automatisch neu generiert. Ins Repo gehört nur die Anleitung (package.json), nicht das Ergebnis.
Die Lösung
.env Dateien / API Keys
niemals committen
.env.example ins Repo
Vorlage mit leeren Werten — echte Keys in Vercel/Netlify/Railway als Environment Variables
Videos, Bilder, PDFs, Daten
> 1 MB gehört nicht ins Repo
Cloud Storage · Git LFS
S3, Cloudflare R2, Supabase Storage — oder Git LFS für versionierte Binaries
node_modules / dist / build
generiert, riesig, unnötig
.gitignore + package.json
In .gitignore eintragen, fertig. Jeder macht bun install / npm install lokal
gitignore.io — einfach Techstack eingeben und eine fertige .gitignore generieren lassen.
Best Practice #5
Jeder der dein Repo aufmacht liest zuerst das README. Wenn es fehlt oder schlecht ist — niemand versteht was das Ding macht.
README.md — Mindest-Standard
Was ist es? — Ein Satz.
Kein Roman. "Tool für X das Y macht." Fertig.
Wie startet man es?
Copy-paste-fähige Befehle. Keine Annahmen über Vorwissen.
Wo ist was?
Kurze Ordner-Übersicht. Fremde (und zukünftiges Ich) orientieren sich sofort.
Welche Env-Variablen braucht es?
.env.example erwähnen — verhindert "warum startet das nicht?"
README aktuell halten
Veraltetes README ist schlimmer als keins. Bei jedem größeren Change: kurz updaten.
💡 Frag einfach Claude: "Schreib mir ein README für dieses Projekt" — und paste die Ordnerstruktur dazu.
Die 3 Dinge die du heute mitnimmst
Commit oft.
Push immer.
Jeder Commit ist eine Sicherheitslinie. Du kannst nie zu viele haben — aber zu wenige kostet dich Stunden.
Secrets
nie auf Git.
.env in .gitignore, echte Keys nur als Environment Variables — einmal gecheckt ist einmal zu viel.
README
zuerst.
Ein gutes README ist Respekt gegenüber anderen — und gegenüber deinem zukünftigen Ich in 3 Monaten.
Bei uns im Unternehmen
Wir haben eine gemeinsame GitHub Organisation. Jedes Projekt das für TAWO gebaut wird gehört dorthin — nicht ins persönliche Profil.
Gemeinsamer Besitz
Wenn jemand die Firma verlässt, bleibt der Code. Kein Repo auf privaten Accounts.
Alles an einem Ort
Jeder im Team kann alle Projekte finden, reviewen und weiterarbeiten — ohne "kannst du mir mal Zugriff geben?"
Zugriff zentral verwaltet
Neue Teammitglieder einladen — und sie haben sofort Zugriff auf alle relevanten Repos.
Nicht: github.com/dein-name/tawo-projekt
Privates Profil = privater Besitz. Das ist für Side Projects, nicht für Firmensachen.
Unsere Organisation
TAWO-GmbH
github.com/TAWO-GmbH
Wenn du ein neues Projekt startest: Repo direkt unter github.com/TAWO-GmbH anlegen — nicht bei dir. Kurz bescheid sagen damit du eingeladen wirst.
Die Kurzfassung
Commit early.
Commit often.
Push always.
Jeder Commit ist eine Sicherheitslinie. Je mehr du machst, desto weniger kannst du verlieren.
git init — und die erste Zeitmaschine läuft.