Folge 006: Zwei Ordner, ein GitHub: Pull, Push und kein Datenmüll

Git klingt erst nach Kauderwelsch. Wird aber easy, wenn du eine Idee akzeptierst: GitHub ist der Boss, dein Rechner ist die Werkstatt.

Nochmal klonen

Der Ordnername auf der Festplatte ist Git egal, zählt nur .git drin.

Die git …-Beispiele unten tippst du im Terminal. Git ist die CLI dafür.

• git clone <url>, neuer Unterordner. Private Repos und SSH: Folge 017.
• git clone <url> .. in den aktuellen Ordner (Punkt = hier).

Praktisch, wenn du einen frischen Stand willst, während du in einem anderen Ordner experimentiert hast.

Zwei Ordner, eine Wahrheit

Kurz als Beispiel:

1. Ordner A: Du arbeitest, pushst nicht.
2. Ordner B: Frischer Clone vom Server.
3. Push aus A. GitHub ist aktuell.
4. In B legst du test.txt an, willst pushen → Geht nicht. (Meldung oft rejected / fetch first.) Server ist neuer. Erst im Projektordner git pull oder in Cursor „Source Control“ (Quellcode-Verwaltung) → „⋯“ → „Pull“ (Pull).

Pull holt Remote-Änderungen. Oft kommt ein Merge — Git klebt Historien zusammen. Verschiedene Dateien? Meist kein Stress. Dieselbe Datei an beiden Enden? Du entscheidest, welche Zeilen bleiben.

In Cursor kannst du Änderungen verwerfen oder Dateien reverten, musst nicht jeden Git-Befehl auswendig kennen.

Merge vs. Rebase (Teaser)

• Merge: sichtbarer Merge-Commit, ehrliche Verzweigung.
• Rebase: lineare Historie, etwas fummeliger.

Für den Start: Merge reicht. Rebase macht die Historie linear, ist aber kniffeliger, nur anfassen, wenn du weißt, warum. Vertiefung mit Grafiken: Folge 007.

Keine Geheimnisse in Git

Gelöschte Dateien? Bleiben in der History. Öffentliches Repo? Jeder kann lesen. Also: keine Passwörter, keine Keys.