Git Cheatsheet — PS Angewandte Systemwissenschaften

1. Was ist Git?

Git ist ein Versionsverwaltungssystem (Version Control System). Es zeichnet jede Änderung an eurem Code auf und ermöglicht es, jederzeit zu einer früheren Version zurückzukehren.

Stellt euch Git wie die Versionshistorie in Google Docs vor, nur für Code. Jede gespeicherte Version (= Commit) ist ein Snapshot eures gesamten Projekts, den ihr jederzeit wiederherstellen könnt.

Warum brauchen wir Git?

Nachvollziehbarkeit: Wer hat wann was geändert?
Sicherheit: Fehler können rückgängig gemacht werden.
Zusammenarbeit: Mehrere Personen können gleichzeitig am selben Projekt arbeiten.
Backup: Der Code liegt sicher auf GitHub (= Remote-Server).

2. Wichtige Begriffe

Git verwendet englische Fachbegriffe. Hier die wichtigsten:

Repository (Repo)

Ein Projektordner, der von Git verwaltet wird. Enthält euren Code und die gesamte Änderungshistorie.

Clone

Eine Kopie eines Remote-Repositories auf euren Computer herunterladen. Der erste Schritt, um an einem Projekt zu arbeiten.

Commit

Ein gespeicherter Snapshot eurer Änderungen, mit einer kurzen Beschreibung (Commit Message). Wie ein "Speicherpunkt" in einem Spiel.

Push

Eure lokalen Commits auf GitHub hochladen, damit das Team sie sehen kann.

Pull

Die neuesten Änderungen eurer Teammitglieder von GitHub herunterladen.

Staging Area

Ein "Zwischenlager": Hier sammelt ihr Änderungen, bevor ihr sie committet. In VSCode: Klick auf + neben einer Datei.

Branch

Ein paralleler Entwicklungszweig. Der Hauptbranch heißt main. Für diesen Kurs arbeiten wir alle direkt auf main.

Merge Conflict

Entsteht, wenn zwei Personen gleichzeitig die gleiche Stelle in einer Datei ändern. Muss manuell gelöst werden.

Remote / Origin

Der Server (GitHub), auf dem das gemeinsame Repository liegt. "Origin" ist der Standardname für diesen Server.

.gitignore

Eine Datei, die Git sagt, welche Dateien nicht versioniert werden sollen (z.B. .venv/, __pycache__/).

3. Lokal vs. Remote

Git arbeitet immer mit zwei Orten: eurer lokalen Arbeitskopie auf dem eigenen Rechner und der gemeinsamen Kopie auf GitHub. Push schickt eure Änderungen nach GitHub, Pull holt neue Änderungen vom Team zurück auf euren Rechner.

4. Git zum ersten Mal verwenden

Bevor ihr mit Pull, Commit und Push arbeiten könnt, braucht ihr einmalig ein paar Startschritte. Diese Reihenfolge gilt für den ersten Start auf eurem Laptop.

1 Git installieren
Installiert Git einmal auf eurem Rechner. Unter Windows ist das meist der Installer von git-scm.com, auf macOS oft via Xcode Command Line Tools oder Homebrew.
2 Namen und E-Mail konfigurieren
Das macht ihr genau einmal pro Rechner. Git schreibt diese Angaben in eure Commits, damit nachvollziehbar ist, wer was geändert hat.

git config --global user.name "Vorname Nachname" git config --global user.email "name@beispiel.at"
3 Repository klonen
Am einfachsten geht das direkt in VSCode. Geht auf GitHub in euer Kurs-Repository und kopiert die URL über den grünen Code-Button.
1. Öffnet in VSCode die Befehlspalette mit Ctrl+Shift+P.
2. Sucht nach Git: Clone und bestätigt mit der Eingabetaste.
3. Fügt die kopierte GitHub-URL ein und bestätigt mit der Eingabetaste.
4. Wählt einen Speicherort auf eurem Computer aus. Wählt hier den Übergeordneten Ordner aus in dem das geklonte Repo sein soll, git legt für das Repo dann dort automatisch einen neuen Ordner an.
5. Klickt danach auf Open, damit VSCode den geklonten Ordner direkt öffnet.
Das Klonen macht ihr genau einmal pro Projekt. Danach habt ihr eine lokale Arbeitskopie mit Verbindung zu GitHub.
4 Prüfen, ob VSCode das Repo erkannt hat
Wenn der Ordner geöffnet ist, erkennt VSCode das Git-Repository automatisch. Unten links solltet ihr den Branch main sehen, und im Source-Control-Panel sind später eure Änderungen sichtbar.

Einmal pro Rechner

git config --global ...

Einmal pro Projekt

Git: Clone in VSCode

Bei jeder Arbeitssession

Pull, arbeiten, testen, committen, pushen

5. Der Git-Workflow

Wenn ihr das Repository bereits geklont und in VSCode geöffnet habt, funktioniert so der grundlegende Ablauf beim Arbeiten. Jeder Schritt bringt eure Änderungen einen Schritt näher zum gemeinsamen Repository.

6. Git in VSCode

VSCode hat eine eingebaute Git-Unterstützung. Hier sind die wichtigsten Elemente der Oberfläche.

6.1 Der Explorer

Im Explorer-Panel (links) seht ihr alle Dateien eures Projekts. Dateien, die geändert, hinzugefügt oder gelöscht wurden, werden mit einem Buchstaben markiert:

A = Added (neue Datei)
M = Modified (geänderte Datei)
D = Deleted (gelöschte Datei)

VSCode Explorer mit einer neuen Python-Datei (A = Added)

Der Explorer zeigt eine neue Datei mit dem Marker A (Added) — sie ist neu und noch nicht committet.

6.2 Source Control: Git-Panel

Klickt auf das Source Control-Symbol in der Seitenleiste (das Verzweigungs-Icon, drittes von oben), oder nutzt das Tastenkürzel Ctrl+Shift+G. Hier seht ihr alle Änderungen und könnt Commits erstellen.

VSCode Seitenleiste mit Source Control Icon

Das Source-Control-Icon (4. von oben) zeigt die Anzahl der Änderungen als Badge.

Die Statusleiste (unten links) zeigt den aktuellen Branch (main) und den Sync-Status.

6.3 Änderungen committen

1 Code schreiben & speichern
Bearbeitet eure Dateien ganz normal. Geänderte Dateien erscheinen automatisch im Source Control Panel unter "Changes".
2 Source Control öffnen
Klickt auf das Source-Control-Symbol in der Seitenleiste oder drückt Ctrl+Shift+G.
3 Änderungen stagen
Klickt auf das + neben jeder Datei, die ihr committen wollt (oder auf das + neben "Changes", um alle auf einmal zu stagen). Die Dateien wandern von "Changes" nach "Staged Changes".
4 Commit-Nachricht schreiben
Schreibt eine kurze, aussagekräftige Beschreibung eurer Änderungen in das Textfeld. Beispiel: Add fibonacci example script
5 Commit & Push
Klickt auf den "Commit"-Button und anschließend auf "Sync Changes" (oder direkt auf "Commit & Push", falls angezeigt). Eure Änderungen werden gespeichert und auf GitHub hochgeladen.

VSCode Source Control Panel mit Commit-Nachricht

Das Source Control Panel: Oben die Commit-Nachricht, darunter der "Commit & Push"-Button, und die geänderte Datei.

6.4 Änderungen vergleichen (Diff View)

Klickt auf eine geänderte Datei im Source Control Panel, um die Änderungen im Diff View zu sehen. Links ist die alte Version, rechts die neue. Grün markierte Zeilen sind neu hinzugefügt.

Der Diff View von fibonacci.py: Links die ursprüngliche Version, rechts die bearbeitete. Neue Zeilen (13–18) sind grün markiert.

7. Zusammenarbeit im Team

Ihr arbeitet zu fünft an einem gemeinsamen Repository auf GitHub. Alle pushen direkt auf den main-Branch. Das ist der einfachste Workflow, erfordert aber Absprache!

Wichtig: Immer zuerst Pull!
Bevor ihr anfangt zu arbeiten, holt euch immer die neuesten Änderungen eurer Teammitglieder mit Pull (in VSCode: Klick auf das Sync-Symbol in der Statusleiste oder Ctrl+Shift+P → "Git: Pull"). Sonst riskiert ihr Merge Conflicts! Beim allerersten Start auf einem neuen Projekt ist der erste Schritt allerdings Clone, nicht Pull.

Empfohlener Ablauf für jede Arbeitssession

1 Pull — Neueste Änderungen holen
2 Code schreiben — An euren Dateien arbeiten
3 Testen — Prüfen, ob euer Code funktioniert
4 Commit & Push — Änderungen speichern und hochladen

Tipp: Kommunikation.
Sprecht euch ab, wer gerade an welcher Datei arbeitet. Wenn zwei Personen gleichzeitig die gleiche Datei bearbeiten, kann es zu Konflikten kommen.

8. Merge Conflicts lösen

Ein Merge Conflict entsteht, wenn zwei Personen gleichzeitig die gleiche Stelle in einer Datei geändert haben. Git weiß dann nicht, welche Version richtig ist, und bittet euch, den Konflikt zu lösen.

Wann passiert das?

Ihr pullt die neuesten Änderungen (oder versucht zu pushen), und Git stellt fest, dass jemand anderes die gleiche Zeile bearbeitet hat wie ihr. VSCode zeigt euch dann im Source Control Panel an, dass es Konflikte gibt — die betroffenen Dateien sind mit einem C (Conflict) markiert.

So löst ihr den Konflikt mit dem VSCode Merge Editor:

1 Konflikt-Datei öffnen
Klickt auf die Datei mit dem Konflikt im Source Control Panel. VSCode erkennt den Konflikt automatisch und zeigt oben einen gelben Hinweis: "This file has merge conflicts".
2 Merge Editor öffnen
Klickt auf den Button "Resolve in Merge Editor" im gelben Hinweis. Es öffnet sich eine Drei-Wege-Ansicht:
- Links oben (Incoming): Die Änderung eurer Teammitglieder (von GitHub)
- Rechts oben (Current): Eure lokale Änderung
- Unten (Result): Das Ergebnis — hier seht ihr, wie die fertige Datei aussehen wird
3 Änderungen auswählen
Für jeden Konflikt könnt ihr per Checkbox entscheiden:
- Accept Incoming: Die Version vom Team übernehmen
- Accept Current: Eure eigene Version behalten
- Beide übernehmen: Beide Checkboxen anhaken — beide Änderungen werden eingefügt
Das Ergebnis seht ihr live im unteren Bereich (Result). Dort könnt ihr es auch noch manuell anpassen.
4 "Complete Merge" klicken
Wenn ihr mit dem Ergebnis zufrieden seid, klickt auf "Complete Merge" (Button unten rechts im Merge Editor). Die Datei wird als gelöst markiert.
5 Commit erstellen
Nachdem alle Konflikte gelöst sind, erstellt einen Commit im Source Control Panel. VSCode schlägt automatisch eine passende Commit-Nachricht vor (z.B. Merge branch 'main'...). Klickt auf "Commit" und dann "Push".

Tipp: Schaut euch das Ergebnis im unteren Bereich (Result) immer genau an, bevor ihr "Complete Merge" klickt. Stellt sicher, dass der Code sinnvoll ist und nichts fehlt.

Keine Panik! Merge Conflicts klingen schlimmer als sie sind. Der VSCode Merge Editor macht es einfach: ihr seht beide Versionen nebeneinander und wählt per Klick aus, was bleiben soll. Im Zweifelsfall sprecht euch im Team ab.

9. Wichtige Git-Befehle (Referenz)

Im Kurs arbeitet ihr hauptsächlich mit der VSCode-Oberfläche. Trotzdem ist es hilfreich, die zugrunde liegenden Befehle zu kennen. Ihr könnt alle Befehle auch im VSCode-Terminal (Ctrl+`) eingeben.

Befehl	Beschreibung	VSCode-Äquivalent
`git config --global user.name "..."`	Namen für alle künftigen Commits setzen	Einmalig im Terminal ausführen
`git config --global user.email "..."`	E-Mail für alle künftigen Commits setzen	Einmalig im Terminal ausführen
`git clone <url>`	Repository von GitHub herunterladen	`Ctrl+Shift+P` → "Git: Clone"
`git pull`	Neueste Änderungen vom Server holen	Sync-Icon in der Statusleiste
`git add <datei>`	Datei zur Staging Area hinzufügen	Klick auf `+` neben der Datei
`git commit -m "msg"`	Änderungen mit Nachricht speichern	Nachricht eingeben + Commit-Button
`git push`	Lokale Commits auf GitHub hochladen	"Commit & Push" oder Sync-Icon
`git status`	Status aller Dateien anzeigen	Source Control Panel (Seitenleiste)
`git log`	Commit-Historie anzeigen	Timeline (Explorer → unten)
`git diff`	Änderungen im Detail anzeigen	Klick auf geänderte Datei → Diff View

10. Tips & Typische Fehler

Immer zuerst Pull!

Bevor ihr anfangt zu arbeiten, holt euch immer die neuesten Änderungen. Das vermeidet die meisten Konflikte.

Committet oft & klein

Lieber viele kleine Commits als einen riesigen. Jeder Commit sollte eine logische Einheit sein.

Gute Commit Messages

Schreibt klar, was ihr geändert habt. Nicht: update — Besser: Add data loading for experiment 2

Sprecht euch ab!

Teilt euch die Arbeit auf. Wenn möglich, arbeitet an verschiedenen Dateien, um Konflikte zu vermeiden.

Nutzt .gitignore

Committet keine generierten Dateien (__pycache__/, .venv/, große Datenfiles). Die .gitignore-Datei regelt das automatisch.

Testet vor dem Push

Stellt sicher, dass euer Code funktioniert, bevor ihr ihn hochladet. Kaputten Code zu pushen blockiert das ganze Team.

Typische Fehler & Lösungen

Push wird abgelehnt ("rejected"): Ursache: Jemand hat vor euch gepusht. Eure lokale Version ist nicht aktuell. Lösung: Zuerst git pull ausführen (oder Sync in VSCode), eventuell Merge Conflicts lösen, dann erneut pushen.

"Ich habe auf dem falschen Branch gearbeitet": Für diesen Kurs arbeiten wir alle auf main, daher sollte dieses Problem nicht auftreten. Kontrolliert in der Statusleiste (unten links), dass dort main steht.

"Ich habe versehentlich etwas Falsches committet": Keine Panik! Macht die Änderung einfach rückgängig und erstellt einen neuen Commit. Git speichert alles — ihr könnt jederzeit zurück.

11. .gitignore und Repository-Start

Wenn ihr ein neues Projekt anlegt, braucht ihr meistens zwei Dinge: eine sinnvolle .gitignore-Datei und ein Git-Repository. Beides wird oft schon automatisch für euch vorbereitet.

Was macht .gitignore?

Die Datei .gitignore sagt Git, welche Dateien nicht versioniert werden sollen. Typische Beispiele sind .venv/, __pycache__/, Build-Artefakte oder große lokale Datenfiles.

Was macht uv init?

uv init erstellt für Python-Projekte normalerweise schon eine sinnvolle .gitignore-Datei und initialisiert meist auch direkt ein neues Git-Repository. In diesem Fall müsst ihr git init oft gar nicht mehr selbst ausführen.

Falls Git noch nicht initialisiert ist: Wenn ihr ein neues Projekt ohne uv init oder ohne bestehendes Repository habt, könnt ihr im Projektordner mit git init selbst ein neues Git-Repository anlegen.

uv init
# meist mit .gitignore und Git-Repository

git init
# nur nötig, wenn noch kein Git-Repository existiert

12. Remote-Repository auf GitHub anlegen

Wenn es auf GitHub noch kein Repository gibt, müsst ihr zuerst dort die gemeinsame Online-Kopie anlegen. Erst danach könnt ihr das Repository klonen oder euren lokalen Code dorthin pushen.

1 Auf GitHub einloggen und oben rechts auf New repository klicken
2 Repository-Namen vergeben und Sichtbarkeit wählen
3 Repository erstellen und danach die URL über den grünen Code-Button kopieren

Wenn ihr ein bestehendes lokales Projekt später mit GitHub verbinden wollt, ist es am einfachsten, auf GitHub ein leeres Repository anzulegen, also ohne zusätzlichen Beispielcode.