Projekt & CheatSheet merged (CheatSheet + Anleitung)

README.md

@@ -602,4 +602,138 @@ git push --force-with-lease
 
 ---
 
+
+# Anleitung - Git über das Terminal nutzen
+
+## Was ist Git?
+
+Git ist ein Versionskontrollsystem - ein Werkzeug, das jede Änderung an deinen Dateien festhält und es dir ermöglicht, mit anderen Menschen an demselben Projekt zu arbeiten, ohne dass ihr euch gegenseitig die Arbeit überschreibt. Du kannst es dir wie ein extrem detailliertes Tagebuch für deinen Code (oder beliebige andere Dateien) vorstellen, das jederzeit weiß, wer wann was geändert hat.
+
+## Schritt 1: Die Installation
+
+Auf einem Debian- oder Ubuntu-System installierst du Git mit dem Paketmanager `apt`.
+
+```bash
+sudo apt update
+sudo apt install git
+```
+
+Ob die Installation geklappt hat, prüfst du mit:
+
+```bash
+git --version
+```
+
+## Schritt 2: Die einmalige Grundkonfiguration
+
+Bevor du Git produktiv nutzen kannst, musst du dich ihm einmal vorstellen. Git speichert mit jedem Schnappschuss (jedem sogenannten *Commit*) den Namen und die E-Mail-Adresse der Person, die ihn erstellt hat - das ist später wichtig, wenn jemand verstehen will, wer welche Änderung gemacht hat. Diese Werte setzt du global, also für alle Projekte auf deinem Rechner, wie folgt:
+
+```bash
+git config --global user.name "Dein Name"
+git config --global user.email "deine@email.de"
+```
+
+Das `--global` ist hier der entscheidende Teil: Es bedeutet, dass diese Einstellungen in deinem Benutzerprofil landen (genauer gesagt in der Datei `~/.gitconfig`) und für jedes Projekt gelten, an dem du auf diesem System arbeitest. Du kannst die Werte jederzeit überschreiben, falls du in einem bestimmten Projekt mit einer anderen Identität arbeiten möchtest - dazu lässt du einfach das `--global` weg und führst den Befehl im Projektordner aus.
+
+## Schritt 3: Ein Projekt herunterladen (Klonen)
+
+Der erste Schritt ist immer das *Klonen*: Du erstellst eine vollständige lokale Kopie des Projekts inklusive seiner gesamten Geschichte. Der Befehl dafür sieht so aus:
+
+```bash
+git clone https://git.beispiel.de/benutzername/projekt.git
+```
+
+Git legt dir daraufhin einen Ordner mit dem Namen des Projekts an, lädt alle Dateien herunter und versetzt diesen Ordner gleich in einen Zustand, in dem Git ihn überwacht. Wechsel mit `cd projekt` in das Verzeichnis.
+
+Ein nützliches Detail: Wenn du nicht klonst, sondern in einem bestehenden Ordner ein neues Git-Projekt anlegen willst, nutzt du stattdessen `git init`. Das Klonen ist aber der typische Weg, wenn du an etwas Vorhandenem mitarbeitest.
+
+## Schritt 4: Den aktuellen Stand abholen (Pullen)
+
+Sobald du das Projekt geklont hast, kann es passieren, dass jemand anderes Änderungen vornimmt, während du etwas anderes tust. Bevor du deine eigene Arbeit weitermachst - und ganz besonders bevor du deine Änderungen hochlädst - solltest du daher den aktuellen Stand vom Server holen. Das geschieht mit:
+
+```bash
+git pull
+```
+
+Hinter diesem schlichten Befehl stecken eigentlich zwei Schritte: Git lädt zunächst die neuesten Änderungen vom Server herunter (`fetch`) und führt sie dann mit deinem lokalen Stand zusammen (`merge`). Solange ihr nicht dieselben Zeilen in derselben Datei bearbeitet habt, läuft das geräuschlos durch. Tut ihr es doch, meldet Git einen *Konflikt*, den du manuell auflösen musst - aber das ist ein eigenes Thema, das wir uns merken können.
+
+## Schritt 5: Eigene Änderungen hochladen (Pushen)
+
+Jetzt der spannende Teil: Du hast eine Datei geändert oder eine neue erstellt, und diese Änderung soll auf den Server. Dieser Vorgang besteht aus drei Schritten, und es lohnt sich, sie wirklich zu verstehen, weil viele Anfänger sie zusammenwerfen.
+
+Im ersten Schritt sagst du Git, *welche* deiner Änderungen du im nächsten Schnappschuss festhalten willst. Das nennt sich *staging*:
+
+```bash
+git add datei.txt
+```
+
+Wenn du alle geänderten Dateien auf einmal vormerken willst, schreibst du `git add .` - der Punkt steht für „alles im aktuellen Verzeichnis und darunter".
+
+Im zweiten Schritt erstellst du den eigentlichen Schnappschuss, den *Commit*, und gibst ihm eine Nachricht mit, die beschreibt, was du geändert hast:
+
+```bash
+git commit -m "Tippfehler in der Anleitung korrigiert"
+```
+
+Dieser Commit existiert nun zunächst nur lokal auf deinem Rechner. Erst der dritte Schritt schickt ihn auf den Server, wo andere ihn sehen können:
+
+```bash
+git push
+```
+
+Diese Trennung zwischen lokalem Festhalten und Hochladen ist eine der größten Stärken von Git: Du kannst auch ohne Internet arbeiten, mehrere Commits hintereinander machen und sie erst später gesammelt pushen.
+
+## Schritt 6: Den Login dauerhaft speichern
+
+Standardmäßig fragt Git dich bei jedem Pull und Push nach Benutzername und Passwort, wenn du HTTPS-URLs verwendest. Es gibt zwei sinnvolle Wege, das zu beheben, und ein dritter Weg, der noch besser ist.
+
+### Variante A: Der Credential-Helper „store"
+
+Die einfachste Lösung ist Git zu sagen, dass es deine Zugangsdaten in einer Datei speichern soll. Das geschieht mit einem einzigen Befehl:
+
+```bash
+git config --global credential.helper store
+```
+
+Beim nächsten Pull oder Push fragt Git dich noch ein letztes Mal nach Benutzername und Passwort - und merkt sich beides danach in der Datei `~/.git-credentials`. Du wirst nie wieder gefragt. Der Haken: Die Datei liegt im Klartext auf deiner Festplatte. Auf einem persönlichen Arbeitsplatzrechner mit verschlüsseltem Heimverzeichnis ist das vertretbar; auf einem Server, den sich mehrere Leute teilen, eher nicht.
+
+### Variante B: Der Credential-Helper „cache"
+
+Wenn du nicht magst, dass deine Zugangsdaten dauerhaft auf der Platte liegen, kannst du sie stattdessen für eine bestimmte Zeit im Arbeitsspeicher zwischenspeichern lassen:
+
+```bash
+git config --global credential.helper "cache --timeout=28800"
+```
+
+Der Wert `28800` sind Sekunden, also genau acht Stunden - ein praktischer Arbeitstag. Nach Ablauf dieser Zeit fragt Git wieder einmal nach. Das ist ein vernünftiger Kompromiss zwischen Bequemlichkeit und Sicherheit, kostet dich aber jeden Tag einmal eine Eingabe.
+
+### Variante C: SSH-Schlüssel (die elegante Lösung)
+
+Wenn du langfristig mit Git arbeitest, lohnt sich der Umstieg auf SSH. Statt eines Passworts nutzt du ein kryptografisches Schlüsselpaar: einen privaten Schlüssel, der auf deinem Rechner bleibt, und einen öffentlichen, den du beim Server hinterlegst. Die beiden erkennen sich gegenseitig automatisch, und du wirst nie mehr nach einem Passwort gefragt.
+
+Erzeugen tust du das Schlüsselpaar mit:
+
+```bash
+ssh-keygen -t ed25519 -C "deine@email.de"
+```
+
+Drücke bei den Rückfragen einfach Enter, um die Standardwerte zu akzeptieren. Den öffentlichen Schlüssel zeigst du dir dann an mit:
+
+```bash
+cat ~/.ssh/id_ed25519.pub
+```
+
+Diesen Text kopierst du und fügst ihn auf deinem Git-Server (Gitea, GitHub, GitLab) in den Einstellungen unter „SSH Keys" ein. Anschließend musst du nur noch dafür sorgen, dass du SSH-URLs statt HTTPS-URLs verwendest - sie beginnen mit `git@` statt `https://`. Bei einem bestehenden Klon kannst du die URL umstellen mit:
+
+```bash
+git remote set-url origin git@git.beispiel.de:benutzername/projekt.git
+```
+
+Ab diesem Moment funktionieren `git pull` und `git push` ohne jede Passworteingabe und gleichzeitig deutlich sicherer als mit gespeichertem Passwort. Wenn dir dein Setup wichtig ist, ist das der Weg, den ich dir wärmstens ans Herz legen würde.
+
+## Eine kleine Zusammenfassung als Denkmodell
+
+Wenn du den Ablauf einmal verinnerlicht hast, läuft jeder Arbeitstag im Grunde nach demselben Muster ab: Du holst dir mit `git pull` den aktuellen Stand, du arbeitest an deinen Dateien, du markierst die Änderungen mit `git add`, du hältst sie mit `git commit -m "Beschreibung"` fest, und du lädst sie mit `git push` hoch. Alles andere - Branches, Merges, Rebases, Tags - baut auf genau diesen Grundbefehlen auf. Wer diese fünf Schritte beherrscht, hat den weitaus größten Teil der täglichen Git-Arbeit bereits abgedeckt.
+
+
 *Erstellt: 04 Februar 2026*