740 lines
18 KiB
Markdown
740 lines
18 KiB
Markdown
# Git CheatSheet
|
|
|
|
Übersicht der wichtigsten Git-Befehle mit praktischen Beispielen.
|
|
|
|
---
|
|
|
|
## Repository erstellen & klonen
|
|
|
|
```bash
|
|
# Neues Repository im aktuellen Verzeichnis initialisieren
|
|
git init
|
|
|
|
# Neues Repository mit Verzeichnis erstellen
|
|
git init mein-projekt
|
|
|
|
# Bestehendes Repository klonen
|
|
git clone https://github.com/user/repo.git
|
|
|
|
# Klonen in ein bestimmtes Verzeichnis
|
|
git clone https://github.com/user/repo.git mein-ordner
|
|
|
|
# Nur den neuesten Commit klonen (shallow clone)
|
|
git clone --depth 1 https://github.com/user/repo.git
|
|
```
|
|
|
|
---
|
|
|
|
## Konfiguration
|
|
|
|
```bash
|
|
# Benutzername setzen (global)
|
|
git config --global user.name "Max Mustermann"
|
|
|
|
# E-Mail setzen (global)
|
|
git config --global user.email "max@example.com"
|
|
|
|
# Konfiguration nur für aktuelles Repo
|
|
git config user.name "Max Mustermann"
|
|
|
|
# Alle Einstellungen anzeigen
|
|
git config --list
|
|
|
|
# Standard-Branch-Name setzen
|
|
git config --global init.defaultBranch main
|
|
|
|
# Editor festlegen
|
|
git config --global core.editor "code --wait"
|
|
|
|
# Aliase erstellen
|
|
git config --global alias.co checkout
|
|
git config --global alias.br branch
|
|
git config --global alias.st status
|
|
git config --global alias.lg "log --oneline --graph --all"
|
|
```
|
|
|
|
---
|
|
|
|
## Status & Änderungen
|
|
|
|
```bash
|
|
# Aktuellen Status anzeigen
|
|
git status
|
|
|
|
# Kurzform des Status
|
|
git status -s
|
|
|
|
# Änderungen anzeigen (noch nicht gestaged)
|
|
git diff
|
|
|
|
# Änderungen anzeigen (bereits gestaged)
|
|
git diff --staged
|
|
|
|
# Änderungen einer bestimmten Datei
|
|
git diff datei.txt
|
|
|
|
# Vergleich zwischen zwei Branches
|
|
git diff main..feature-branch
|
|
|
|
# Vergleich zwischen zwei Commits
|
|
git diff abc123 def456
|
|
```
|
|
|
|
---
|
|
|
|
## Dateien hinzufügen (Staging)
|
|
|
|
```bash
|
|
# Einzelne Datei hinzufügen
|
|
git add datei.txt
|
|
|
|
# Mehrere Dateien hinzufügen
|
|
git add datei1.txt datei2.txt
|
|
|
|
# Alle Dateien im aktuellen Verzeichnis
|
|
git add .
|
|
|
|
# Alle Änderungen (inkl. gelöschte Dateien)
|
|
git add -A
|
|
|
|
# Interaktiv Teile einer Datei hinzufügen
|
|
git add -p datei.txt
|
|
|
|
# Dateien nach Muster hinzufügen
|
|
git add *.js
|
|
git add src/
|
|
```
|
|
|
|
---
|
|
|
|
## Commits
|
|
|
|
```bash
|
|
# Commit mit Nachricht
|
|
git commit -m "Kurze Beschreibung der Änderung"
|
|
|
|
# Alle geänderten Dateien committen (ohne git add)
|
|
git commit -am "Änderungen committen"
|
|
|
|
# Letzten Commit ändern (Nachricht oder Dateien)
|
|
git commit --amend -m "Neue Nachricht"
|
|
|
|
# Leeren Commit erstellen (z.B. für CI-Trigger)
|
|
git commit --allow-empty -m "Trigger CI"
|
|
|
|
# Commit mit mehrzeiliger Nachricht
|
|
git commit -m "Titel" -m "Detaillierte Beschreibung"
|
|
```
|
|
|
|
---
|
|
|
|
## Branches
|
|
|
|
```bash
|
|
# Alle lokalen Branches anzeigen
|
|
git branch
|
|
|
|
# Alle Branches (lokal + remote)
|
|
git branch -a
|
|
|
|
# Neuen Branch erstellen
|
|
git branch feature-login
|
|
|
|
# Branch erstellen und wechseln
|
|
git checkout -b feature-login
|
|
# oder (neuere Syntax)
|
|
git switch -c feature-login
|
|
|
|
# Zu einem Branch wechseln
|
|
git checkout main
|
|
# oder
|
|
git switch main
|
|
|
|
# Branch umbenennen
|
|
git branch -m alter-name neuer-name
|
|
|
|
# Branch löschen (lokal)
|
|
git branch -d feature-login
|
|
|
|
# Branch löschen (forciert, auch ungemergte)
|
|
git branch -D feature-login
|
|
|
|
# Remote-Branch löschen
|
|
git push origin --delete feature-login
|
|
```
|
|
|
|
---
|
|
|
|
## Merging
|
|
|
|
```bash
|
|
# Branch in aktuellen Branch mergen
|
|
git merge feature-login
|
|
|
|
# Merge ohne Fast-Forward (behält Branch-Historie)
|
|
git merge --no-ff feature-login
|
|
|
|
# Merge abbrechen (bei Konflikten)
|
|
git merge --abort
|
|
|
|
# Merge-Konflikte anzeigen
|
|
git diff --name-only --diff-filter=U
|
|
```
|
|
|
|
---
|
|
|
|
## Rebasing
|
|
|
|
```bash
|
|
# Aktuellen Branch auf main rebasen
|
|
git rebase main
|
|
|
|
# Interaktives Rebase (letzte 3 Commits)
|
|
git rebase -i HEAD~3
|
|
|
|
# Rebase abbrechen
|
|
git rebase --abort
|
|
|
|
# Nach Konfliktlösung fortfahren
|
|
git rebase --continue
|
|
|
|
# Einzelnen Commit überspringen
|
|
git rebase --skip
|
|
```
|
|
|
|
---
|
|
|
|
## Remote-Repositories
|
|
|
|
```bash
|
|
# Remote-Repositories anzeigen
|
|
git remote -v
|
|
|
|
# Neues Remote hinzufügen
|
|
git remote add origin https://github.com/user/repo.git
|
|
|
|
# Remote-URL ändern
|
|
git remote set-url origin https://github.com/user/neues-repo.git
|
|
|
|
# Remote entfernen
|
|
git remote remove origin
|
|
|
|
# Remote umbenennen
|
|
git remote rename origin upstream
|
|
```
|
|
|
|
---
|
|
|
|
## Push & Pull
|
|
|
|
```bash
|
|
# Änderungen pushen
|
|
git push origin main
|
|
|
|
# Ersten Push mit Upstream setzen
|
|
git push -u origin main
|
|
|
|
# Danach reicht:
|
|
git push
|
|
|
|
# Force-Push (Vorsicht!)
|
|
git push --force
|
|
# Sicherer:
|
|
git push --force-with-lease
|
|
|
|
# Änderungen holen und mergen
|
|
git pull
|
|
|
|
# Änderungen holen ohne Merge
|
|
git fetch
|
|
|
|
# Alle Remotes fetchen
|
|
git fetch --all
|
|
|
|
# Mit Rebase statt Merge
|
|
git pull --rebase
|
|
```
|
|
|
|
---
|
|
|
|
## Stashing (Änderungen zwischenspeichern)
|
|
|
|
```bash
|
|
# Aktuelle Änderungen stashen
|
|
git stash
|
|
|
|
# Stash mit Beschreibung
|
|
git stash save "Arbeit an Feature X"
|
|
|
|
# Auch untracked Dateien stashen
|
|
git stash -u
|
|
|
|
# Stash-Liste anzeigen
|
|
git stash list
|
|
|
|
# Letzten Stash anwenden und behalten
|
|
git stash apply
|
|
|
|
# Letzten Stash anwenden und löschen
|
|
git stash pop
|
|
|
|
# Bestimmten Stash anwenden
|
|
git stash apply stash@{2}
|
|
|
|
# Stash löschen
|
|
git stash drop stash@{0}
|
|
|
|
# Alle Stashes löschen
|
|
git stash clear
|
|
|
|
# Stash als neuen Branch
|
|
git stash branch neuer-branch
|
|
```
|
|
|
|
---
|
|
|
|
## Historie & Logs
|
|
|
|
```bash
|
|
# Commit-Historie anzeigen
|
|
git log
|
|
|
|
# Kompakte Ansicht
|
|
git log --oneline
|
|
|
|
# Mit Graph
|
|
git log --oneline --graph --all
|
|
|
|
# Letzte n Commits
|
|
git log -5
|
|
|
|
# Commits eines Autors
|
|
git log --author="Max"
|
|
|
|
# Commits in Zeitraum
|
|
git log --since="2024-01-01" --until="2024-12-31"
|
|
|
|
# Commits mit bestimmtem Text
|
|
git log --grep="bugfix"
|
|
|
|
# Änderungen in Datei verfolgen
|
|
git log -p datei.txt
|
|
|
|
# Wer hat welche Zeile geändert
|
|
git blame datei.txt
|
|
|
|
# Kurze Statistik
|
|
git log --stat
|
|
|
|
# Änderungen pro Autor
|
|
git shortlog -sn
|
|
```
|
|
|
|
---
|
|
|
|
## Rückgängig machen
|
|
|
|
```bash
|
|
# Unstaged Änderungen verwerfen
|
|
git checkout -- datei.txt
|
|
# oder (neuere Syntax)
|
|
git restore datei.txt
|
|
|
|
# Staged Datei zurück zu unstaged
|
|
git reset HEAD datei.txt
|
|
# oder
|
|
git restore --staged datei.txt
|
|
|
|
# Letzten Commit rückgängig (behält Änderungen)
|
|
git reset --soft HEAD~1
|
|
|
|
# Letzten Commit rückgängig (verwirft Änderungen)
|
|
git reset --hard HEAD~1
|
|
|
|
# Zu bestimmtem Commit zurück
|
|
git reset --hard abc1234
|
|
|
|
# Commit rückgängig machen (neuer Commit)
|
|
git revert abc1234
|
|
|
|
# Alle lokalen Änderungen verwerfen
|
|
git checkout .
|
|
git clean -fd
|
|
```
|
|
|
|
---
|
|
|
|
## Tags
|
|
|
|
```bash
|
|
# Alle Tags anzeigen
|
|
git tag
|
|
|
|
# Lightweight Tag erstellen
|
|
git tag v1.0.0
|
|
|
|
# Annotated Tag mit Nachricht
|
|
git tag -a v1.0.0 -m "Version 1.0.0 Release"
|
|
|
|
# Tag für älteren Commit
|
|
git tag -a v0.9.0 abc1234 -m "Nachträglicher Tag"
|
|
|
|
# Tags pushen
|
|
git push origin v1.0.0
|
|
|
|
# Alle Tags pushen
|
|
git push origin --tags
|
|
|
|
# Tag löschen (lokal)
|
|
git tag -d v1.0.0
|
|
|
|
# Tag löschen (remote)
|
|
git push origin --delete v1.0.0
|
|
|
|
# Zu Tag wechseln
|
|
git checkout v1.0.0
|
|
```
|
|
|
|
---
|
|
|
|
## Cherry-Pick
|
|
|
|
```bash
|
|
# Einzelnen Commit in aktuellen Branch übernehmen
|
|
git cherry-pick abc1234
|
|
|
|
# Mehrere Commits
|
|
git cherry-pick abc1234 def5678
|
|
|
|
# Cherry-Pick ohne Commit (nur Änderungen übernehmen)
|
|
git cherry-pick -n abc1234
|
|
|
|
# Bei Konflikten fortfahren
|
|
git cherry-pick --continue
|
|
|
|
# Cherry-Pick abbrechen
|
|
git cherry-pick --abort
|
|
```
|
|
|
|
---
|
|
|
|
## Suchen
|
|
|
|
```bash
|
|
# In Dateien suchen
|
|
git grep "suchbegriff"
|
|
|
|
# Mit Zeilennummern
|
|
git grep -n "suchbegriff"
|
|
|
|
# In bestimmtem Commit suchen
|
|
git grep "suchbegriff" abc1234
|
|
|
|
# Commit finden, der einen Bug eingeführt hat
|
|
git bisect start
|
|
git bisect bad # Aktueller Commit ist kaputt
|
|
git bisect good abc1234 # Dieser Commit war noch OK
|
|
# Git führt dich durch die Commits
|
|
git bisect reset # Beenden
|
|
```
|
|
|
|
---
|
|
|
|
## Aufräumen
|
|
|
|
```bash
|
|
# Untracked Dateien anzeigen
|
|
git clean -n
|
|
|
|
# Untracked Dateien löschen
|
|
git clean -f
|
|
|
|
# Auch Verzeichnisse
|
|
git clean -fd
|
|
|
|
# Auch ignorierte Dateien
|
|
git clean -fdx
|
|
|
|
# Nicht mehr existierende Remote-Branches entfernen
|
|
git fetch --prune
|
|
|
|
# Alte Objekte aufräumen
|
|
git gc
|
|
|
|
# Aggressive Aufräumung
|
|
git gc --aggressive
|
|
```
|
|
|
|
---
|
|
|
|
## Submodules
|
|
|
|
```bash
|
|
# Submodule hinzufügen
|
|
git submodule add https://github.com/user/lib.git libs/lib
|
|
|
|
# Submodules beim Klonen initialisieren
|
|
git clone --recurse-submodules https://github.com/user/repo.git
|
|
|
|
# Submodules nachträglich initialisieren
|
|
git submodule init
|
|
git submodule update
|
|
|
|
# Alle Submodules aktualisieren
|
|
git submodule update --remote
|
|
|
|
# Submodule entfernen
|
|
git submodule deinit libs/lib
|
|
git rm libs/lib
|
|
```
|
|
|
|
---
|
|
|
|
## Nützliche Kombinationen
|
|
|
|
```bash
|
|
# Letzten Commit-Hash anzeigen
|
|
git rev-parse HEAD
|
|
|
|
# Aktuellen Branch-Namen anzeigen
|
|
git branch --show-current
|
|
|
|
# Anzahl Commits zählen
|
|
git rev-list --count HEAD
|
|
|
|
# Alle Dateien eines Commits auflisten
|
|
git diff-tree --no-commit-id --name-only -r abc1234
|
|
|
|
# Änderungen seit letztem Tag
|
|
git log $(git describe --tags --abbrev=0)..HEAD --oneline
|
|
|
|
# Dateien im Staging-Bereich anzeigen
|
|
git diff --cached --name-only
|
|
|
|
# Lokale Branches ohne Remote löschen
|
|
git fetch -p && git branch -vv | grep ': gone]' | awk '{print $1}' | xargs git branch -D
|
|
```
|
|
|
|
---
|
|
|
|
## .gitignore Beispiele
|
|
|
|
```gitignore
|
|
# Verzeichnisse
|
|
node_modules/
|
|
vendor/
|
|
.idea/
|
|
.vscode/
|
|
|
|
# Dateitypen
|
|
*.log
|
|
*.tmp
|
|
*.cache
|
|
|
|
# Spezifische Dateien
|
|
.env
|
|
.DS_Store
|
|
Thumbs.db
|
|
|
|
# Ausnahmen (nicht ignorieren)
|
|
!wichtig.log
|
|
|
|
# Muster
|
|
**/logs/
|
|
debug[0-9].log
|
|
```
|
|
|
|
---
|
|
|
|
## Häufige Workflows
|
|
|
|
### Feature-Branch Workflow
|
|
|
|
```bash
|
|
git checkout main
|
|
git pull
|
|
git checkout -b feature/neue-funktion
|
|
# ... Änderungen ...
|
|
git add .
|
|
git commit -m "Neue Funktion implementiert"
|
|
git push -u origin feature/neue-funktion
|
|
# Pull Request erstellen, dann:
|
|
git checkout main
|
|
git pull
|
|
git branch -d feature/neue-funktion
|
|
```
|
|
|
|
### Hotfix Workflow
|
|
|
|
```bash
|
|
git checkout main
|
|
git pull
|
|
git checkout -b hotfix/kritischer-bug
|
|
# ... Fix ...
|
|
git commit -am "Kritischen Bug behoben"
|
|
git checkout main
|
|
git merge hotfix/kritischer-bug
|
|
git tag -a v1.0.1 -m "Hotfix Release"
|
|
git push origin main --tags
|
|
git branch -d hotfix/kritischer-bug
|
|
```
|
|
|
|
### Rebase vor Merge
|
|
|
|
```bash
|
|
git checkout feature-branch
|
|
git fetch origin
|
|
git rebase origin/main
|
|
# Konflikte lösen falls nötig
|
|
git push --force-with-lease
|
|
```
|
|
|
|
---
|
|
|
|
## Tipps
|
|
|
|
- **Commit oft**: Kleine, fokussierte Commits sind besser als große.
|
|
- **Aussagekräftige Nachrichten**: Was wurde geändert und warum?
|
|
- **Branches nutzen**: Nie direkt auf main/master entwickeln.
|
|
- **Vor Push prüfen**: `git log origin/main..HEAD` zeigt ausstehende Commits.
|
|
- **Backup vor Reset**: Bei `--hard` gehen Änderungen verloren!
|
|
- **Force-Push vermeiden**: Nur auf eigenen Feature-Branches.
|
|
|
|
---
|
|
|
|
|
|
# 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*
|