Auf dieser Seite

Git-Befehle meistern: Ein praktischer Leitfaden

Ammar Najjar · Veröffentlicht am 8. Juli 2025

Git ist unverzichtbar für die Versionskontrolle: Änderungen nachverfolgen, effektiv zusammenarbeiten, Projektverwaltung. Die schiere Bandbreite an Funktionen kann überwältigen, aber wer die Schlüsselbefehle versteht, vereinfacht seinen Workflow enorm. Dieser Artikel stellt eine Auswahl praktischer Git-Befehle vor und erklärt, was sie tun, wie man sie einsetzt und wann sie am effektivsten sind.

1. Konfigurationsbefehle

Die richtige Einrichtung Ihrer Git-Umgebung ist der erste Schritt. Diese Befehle helfen Ihnen, Ihre Identität und Präferenzen zu definieren.

git config --global user.name "Your Name"
- Was es tut: Legt den globalen Benutzernamen für Ihre Git-Commits fest. Dieser Name wird in der Commit-Historie für alle Repositorys auf Ihrem System angezeigt.
- Wann zu verwenden: Typischerweise ist dies einer der ersten Befehle, die Sie nach der Installation von Git ausführen. Es stellt sicher, dass Ihre Commits Ihnen zugeordnet werden.
- Wie zu verwenden:
```
git config --global user.name "Ammar Najjar"
```
git config --local user.email <email>
- Was es tut: Legt die E-Mail-Adresse für Commits fest, die spezifisch für das aktuelle Repository sind. Dies überschreibt die globale E-Mail-Einstellung.
- Wann zu verwenden: Wenn Sie eine andere E-Mail-Adresse für ein bestimmtes Projekt verwenden möchten (z.B. eine Arbeits-E-Mail für ein Firmenprojekt und eine persönliche E-Mail für Open-Source-Beiträge).
- Wie zu verwenden:
```
git config --local user.email your.email@example.com
```
git config --local user.signingkey <key>
- Was es tut: Konfiguriert den GPG-Schlüssel, der zum Signieren von Commits lokal innerhalb eines bestimmten Repositorys verwendet wird.
- Wann zu verwenden: Wenn Ihr Projekt oder Ihre Organisation signierte Commits zur Überprüfung und Integrität erfordert und Sie einen bestimmten Schlüssel für dieses Repository verwenden müssen.
- Wie zu verwenden:
```
git config --local user.signingkey YOUR_GPG_KEY_ID
```

Verstehen und Verwenden von `user.signingkey`

Commit-Signierung mit GPG (GNU Privacy Guard) fügt Ihrer Git-Historie eine Ebene von Sicherheit und Vertrauen hinzu. Wenn Sie einen Commit signieren, beweisen Sie kryptografisch, dass Sie der Autor dieses Commits sind und dass der Inhalt des Commits seit der Signierung nicht manipuliert wurde.

1. Einen GPG-Schlüssel erstellen (falls Sie noch keinen haben): Wenn Sie noch keinen GPG-Schlüssel haben, müssen Sie einen erstellen. Dies ist eine einmalige Einrichtung.

gpg --full-generate-key

Befolgen Sie die Aufforderungen, um den Schlüsseltyp, die Schlüsselgröße, das Ablaufdatum auszuwählen und eine Passphrase festzulegen.

2. Ihre GPG-Schlüssel-ID abrufen: Sobald Sie einen GPG-Schlüssel haben, benötigen Sie seine ID, um Git mitzuteilen, welchen Schlüssel es verwenden soll.

gpg --list-secret-keys --keyid-format LONG

Suchen Sie nach einer Zeile wie sec rsa4096/YOUR_KEY_ID 2023-01-01 [SC], wobei YOUR_KEY_ID die 16-stellige hexadezimale Zeichenkette ist. Das ist die ID, die Sie verwenden werden.

3. Git konfigurieren, Ihren GPG-Schlüssel zu verwenden: Sie können Git global oder lokal für ein bestimmtes Repository konfigurieren.

Globale Konfiguration (für alle Repositorys):

git config --global user.signingkey YOUR_KEY_ID

Lokale Konfiguration (nur für das aktuelle Repository):
```
git config --local user.signingkey YOUR_KEY_ID
```

4. Automatische Commit-Signierung aktivieren (Optional, aber empfohlen): Um automatisch alle Ihre Commits zu signieren, können Sie eine globale Konfiguration setzen:

git config --global commit.gpgsign true

Wenn Sie dies nicht setzen, müssen Sie jeden Commit manuell mit git commit -S signieren.

5. Einen Commit signieren:

Wenn commit.gpgsign auf true gesetzt ist, führen Sie einfach aus:
```
git commit -m "Your commit message"
```
Sie werden nach Ihrer GPG-Passphrase gefragt.
Wenn commit.gpgsign auf false gesetzt ist, signieren Sie manuell mit:
```
git commit -S -m "Your commit message"
```

6. Einen signierten Commit überprüfen: Um zu sehen, ob ein Commit signiert ist und von wem, verwenden Sie:

git log --show-signature

Sie erhalten eine “Good signature from…”-Meldung, wenn die Signatur gültig und der Schlüssel vertrauenswürdig ist.

git config --global push.default current
- Was es tut: Legt das Standardverhalten für git push fest. Mit current pusht git push den aktuellen Branch auf seinen Upstream-Branch (einen Branch im Remote-Repository, den er verfolgt).
- Wann zu verwenden: Um Ihren Push-Workflow zu vereinfachen. Anstatt immer git push origin <branch-name> zu tippen, können Sie einfach git push tippen, und Git weiß, welchen Remote-Branch es pushen soll.
- Wie zu verwenden:
```
git config --global push.default current
```

Nach oben

Verzweigungen sind grundlegend für Git und ermöglichen parallele Entwicklung. Diese Befehle helfen Ihnen, sie zu verwalten und zu navigieren.

git rev-parse --abbrev-ref HEAD
- Was es tut: Zeigt den Namen des aktuellen Branches an. HEAD verweist auf den aktuellen Commit, und --abbrev-ref zeigt seinen symbolischen Namen (den Branchnamen) anstelle des vollständigen SHA-1-Hashes.
- Wann zu verwenden: Um schnell zu überprüfen, auf welchem Branch Sie sich befinden, besonders nützlich in Skripten oder wenn Sie Ihren Kontext bestätigen müssen.
- Wie zu verwenden:
```
git rev-parse --abbrev-ref HEAD
```
git rev-parse --abbrev-ref HEAD | sed 's/.*$PATTERN-HERE$.*/\1/'
- Was es tut: Extrahiert ein bestimmtes Muster aus dem aktuellen Branchnamen mit sed. Dies ist nützlich zum Parsen strukturierter Branchnamen (z.B. feature/JIRA-123-description).
- Wann zu verwenden: In Skripten oder Automatisierung, bei denen Sie bestimmte Kennungen (wie eine Ticketnummer) aus Ihrem Branchnamen extrahieren müssen.
- Wie zu verwenden: Ersetzen Sie PATTERN-HERE durch Ihren gewünschten regulären Ausdruck. Um zum Beispiel “JIRA-123” aus “feature/JIRA-123-add-feature” zu extrahieren:
```
git rev-parse --abbrev-ref HEAD | sed 's/.*$JIRA-[0-9]*$.*/\1/'
```
git config --global alias.gco = "!f() { git branch -a | grep -e $1 -m 1 | sed 's/remotes\\/origin\\///' | xargs git checkout; }; f"
- Was es tut: Erstellt einen globalen Git-Alias namens gco, mit dem Sie einen Branch durch Angabe eines teilweisen Musters auschecken können. Er durchsucht alle lokalen und Remote-Branches, wählt den ersten Treffer und checked ihn aus.
- Wann zu verwenden: Wenn Sie häufig zwischen Branches wechseln und sich nur an einen Teil des Branchnamens erinnern, oder wenn die Branchnamen lang und komplex sind.
- Wie zu verwenden: Nach dem Einrichten des Alias können Sie ihn so verwenden:
```
git gco PATTERN-HERE
# Example: git gco feature/my-new-feature (if your branch is feature/my-new-feature-branch)
```
git stash branch <branch-name>
- Was es tut: Erstellt einen neuen Branch vom Commit, der beim Erstellen des Stash aktuell war, und wendet dann die gestashten Änderungen auf diesen neuen Branch an. Der Stash-Eintrag wird dann gelöscht.
- Wann zu verwenden: Wenn Sie一些工作 gestasht haben und später entscheiden, dass diese Änderungen die Grundlage für einen neuen Feature-Branch bilden sollen, anstatt auf den aktuellen Branch angewendet zu werden.
- Wie zu verwenden:
```
git stash branch new-feature-branch
```

Nach oben

3. Commits und Historieninspektion

Das Verstehen der Projektgeschichte und das Durchführen von Änderungen sind zentrale Git-Operationen.

git commit --no-verify
- Was es tut: Erstellt einen Commit, umgeht aber alle für das Repository konfigurierten Pre-Commit-Hooks.
- Wann zu verwenden: Mit Vorsicht verwenden. Dies wird typischerweise verwendet, wenn ein Pre-Commit-Hook vorübergehend fehlschlägt oder wenn Sie wissen, dass die Änderungen, die Sie committen, absichtlich eine bestimmte Prüfung umgehen (z.B. Committing von Arbeit im Fortschritt, die das Linting noch nicht besteht).
- Wie zu verwenden:
```
git commit --no-verify -m "WIP: Bypassing hooks for now"
```
git diff --name-only
- Was es tut: Zeigt nur die Namen der Dateien an, die seit dem letzten Commit geändert wurden (gestaged oder nicht gestaged).
- Wann zu verwenden: Um schnell einen Überblick zu bekommen, welche Dateien Sie geändert haben, ohne die tatsächlichen Inhaltsänderungen zu sehen.
- Wie zu verwenden:
```
git diff --name-only
```
git log --follow <file>
- Was es tut: Zeigt die Commit-Historie für eine bestimmte Datei an, einschließlich Commits, in denen die Datei umbenannt oder verschoben wurde. Ohne --follow würde git log die Verfolgung der Dateihistorie einstellen, wenn sie umbenannt würde.
- Wann zu verwenden: Um die vollständige Entwicklung einer Datei zu verstehen, selbst wenn sich ihr Pfad im Laufe der Zeit geändert hat.
- Wie zu verwenden:
```
git log --follow src/main.js
```
git log -p --follow <file>
- Was es tut: Ähnlich wie git log --follow, zeigt aber auch den Patch (Diff) für jeden Commit an und detailiert die genauen Änderungen an der Datei.
- Wann zu verwenden: Wenn Sie nicht nur sehen möchten, wann eine Datei geändert wurde, sondern was in jedem Commit im Laufe ihrer Geschichte geändert wurde, einschließlich Umbenennungen.
- Wie zu verwenden:
```
git log -p --follow src/main.js
```
git show --remerge-diff
- Was es tut: (Verfügbar in Git 2.36.0 und später) Wenn auf einen Merge-Commit angewendet, zeigt dieser Befehl den Diff mit Merge-Konflikten und wie sie gelöst wurden.
- Wann zu verwenden: Nach einem Merge, um die spezifischen Änderungen zu überprüfen, die zur Lösung von Konflikten vorgenommen wurden, und Klarheit über die Merge-Strategie zu schaffen.
- Wie zu verwenden:
```
git show --remerge-diff <merge-commit-hash>
```
git log -p -Gword
- Was es tut: Findet Commits, in denen das angegebene “Wort” (oder der reguläre Ausdruck) im Diff (den tatsächlichen Änderungen am Code) erscheint.
- Wann zu verwenden: Um Commits zu identifizieren, die ein bestimmtes Stück Code, einen Variablennamen oder einen Funktionsaufruf eingeführt oder geändert haben.
- Wie zu verwenden:
```
git log -p -G"my_function_name"
```
git log --grep=word
- Was es tut: Findet alle Commits, deren Commit-Nachricht das angegebene “Wort” (oder den regulären Ausdruck) enthält.
- Wann zu verwenden: Um nach Commits zu suchen, die mit einem bestimmten Feature, einer Fehlerbehebung oder einem Thema basierend auf Schlüsselwörtern in ihren Commit-Nachrichten zusammenhängen.
- Wie zu verwenden:
```
git log --grep="bugfix"
```

Nach oben

4. Tagging und Hilfswerkzeuge

Tags werden verwendet, um bestimmte Punkte in der Historie zu markieren, typischerweise für Releases.

git tag -l | rg -e "2\d.\d.\d$" | sort | tail -n 10
- Was es tut: Dies ist eine Pipeline von Befehlen:
  - git tag -l: Listet alle Tags im Repository auf.
  - rg -e "2\d.\d.\d$": Filtert die Tags mit ripgrep (einem externen Werkzeug), um diejenigen zu finden, die einem Muster wie “2.x.x” entsprechen (z.B. 2.1.0, 2.36.0).
  - sort: Sortiert die gefilterten Tags alphabetisch.
  - tail -n 10: Zeigt die letzten 10 Einträge an und gibt Ihnen effektiv die 10 neuesten “stabil” aussehenden Tags basierend auf dem Muster.
- Wann zu verwenden: Um schnell aktuelle stabile Release-Tags in einem Repository zu identifizieren, das einem Semantischen Versionierungsschema folgt.
- Wie zu verwenden: Stellen Sie sicher, dass Sie ripgrep installiert haben.
```
git tag -l | rg -e "2\d.\d.\d$" | sort | tail -n 10
```

Nach oben

5. Essentielle tägliche Workflow-Befehle

Diese Befehle sind das tägliche Brot und Butter der Interaktion eines Software-Entwicklers mit Git und decken alles ab, vom Überprüfen des Status bis zum Pushen von Änderungen.

git status
- Was es tut: Zeigt den Status Ihres Arbeitsverzeichnisses und Staging-Bereichs an. Es teilt Ihnen mit, welche Änderungen gestaged wurden, welche nicht und welche Dateien von Git nicht verfolgt werden.
- Wann zu verwenden: Ständig! Dies ist Ihre primäre Methode, um den aktuellen Zustand Ihres Repositorys zu verstehen, bevor Sie committen oder andere Operationen durchführen.
- Wie zu verwenden:
```
git status
```
git add <file> / git add . / git add -p
- Was es tut: Fügt Änderungen aus dem Arbeitsverzeichnis zum Staging-Bereich hinzu und bereitet sie auf den nächsten Commit vor.
  - <file>: Staged bestimmte Datei(en).
  - .: Staged alle Änderungen im aktuellen Verzeichnis und seinen Unterverzeichnissen.
  - -p (patch): Ermöglicht es Ihnen, interaktiv bestimmte Teile (Hunks) von Änderungen in Dateien zum Stagen auszuwählen.
- Wann zu verwenden: Vor jedem Commit, um genau auszuwählen, welche Änderungen Sie einbeziehen möchten. -p ist unbezahlbar für das Erstellen sauberer, fokussierter Commits.
- Wie zu verwenden:
```
git add my_feature.js
git add .
git add -p
```
git commit -m "Your message" / git commit --amend
- Was es tut: Speichert die gestageden Änderungen als neuen Commit im Repository.
  - -m: Gibt direkt in der Befehlszeile eine Commit-Nachricht an.
  - --amend: Ermöglicht es Ihnen, den neuesten Commit zu ändern. Sie können seine Nachricht ändern, Dateien hinzufügen/entfernen oder vorhandene Änderungen modifizieren.
- Wann zu verwenden:
  - -m: Nach dem Stagen von Änderungen, um eine logische Arbeitseinheit abzuschließen.
  - --amend: Um einen Tippfehler in der letzten Commit-Nachricht zu beheben oder eine vergessene Datei/Änderung zum letzten Commit hinzuzufügen, bevor Sie ihn zu einem gemeinsamen Remote pushen.
- Wie zu verwenden:
```
git commit -m "Add user authentication feature"
git commit --amend -m "Fix typo in auth feature commit message"
```
git branch <new-branch-name>
- Was es tut: Erstellt einen neuen Branch, der auf den aktuellen Commit zeigt.
- Wann zu verwenden: Um mit der Arbeit an einem neuen Feature, einer Fehlerbehebung oder einem Experiment zu beginnen, ohne den Hauptcodebasis zu beeinträchtigen.
- Wie zu verwenden:
```
git branch feature/new-dashboard
```
git switch <branch-name> / git checkout <branch-name>
- Was es tut: Wechselt Ihr Arbeitsverzeichnis zum angegebenen Branch. git switch ist der neuere, sicherere Befehl zum Wechseln von Branches, während git checkout vielseitiger ist (kann auch Dateien wiederherstellen).
- Wann zu verwenden: Um zwischen verschiedenen Entwicklungslinien zu wechseln.
- Wie zu verwenden:
```
git switch main
git checkout feature/new-dashboard # Older but still common
```
git checkout -b <new-branch-name>
- Was es tut: Eine praktische Abkürzung, die einen neuen Branch erstellt und sofort zu ihm wechselt.
- Wann zu verwenden: Wenn Sie einen neuen Feature-Branch starten und direkt einsteigen möchten.
- Wie zu verwenden:
```
git checkout -b bugfix/login-issue
```
git pull
- Was es tut: Holt Änderungen vom Remote-Repository und führt sie automatisch mit Ihrem aktuellen Branch zusammen. Es ist eine Abkürzung für git fetch gefolgt von git merge.
- Wann zu verwenden: Um Ihren lokalen Branch mit seinem upstream Remote-Pendant zu synchronisieren und die neuesten Änderungen von Mitwirkenden herunterzuladen.
- Wie zu verwenden:
```
git pull origin main
# Or simply: git pull (if upstream is set)
```
git fetch
- Was es tut: Lädt Objekte und Referenzen von einem anderen Repository (dem Remote) in Ihr lokales Repository herunter. Es führt keine Zusammenführung durch oder ändert Ihre lokalen Arbeitsdateien.
- Wann zu verwenden: Um zu sehen, welche Änderungen im Remote stattgefunden haben, ohne sie in Ihre aktuelle Arbeit zu integrieren. Nützlich zum Überprüfen von Remote-Branches oder zur Vorbereitung auf eine Zusammenführung/Rebase.
- Wie zu verwenden:
```
git fetch origin
```
git push
- Was es tut: Lädt Ihre lokalen Commits zum Remote-Repository hoch.
- Wann zu verwenden: Um Ihre abgeschlossene Arbeit mit anderen zu teilen oder Ihre Änderungen zu sichern.
- Wie zu verwenden:
```
git push origin feature/my-new-feature
# Or simply: git push (if upstream is set)
```
git merge <branch>
- Was es tut: Integriert Änderungen aus dem angegebenen Branch in Ihren aktuellen Branch.
- Wann zu verwenden: Um abgeschlossene Feature-Branches mit einem Hauptentwicklungsbranch zu verbinden oder um Änderungen aus einem gemeinsamen Branch in Ihren eigenen zu ziehen.
- Wie zu verwenden:
```
git switch main
git merge feature/my-new-feature
```
git rebase <branch>
- Was es tut: Wendet die Commits Ihres aktuellen Branches erneut auf einem anderen Basis-Branch an. Dies schreibt die Historie Ihres Branches um und erstellt eine lineare Historie.
- Wann zu verwenden: Um Ihren Feature-Branch mit dem Hauptbranch aktuell zu halten, ohne Merge-Commits zu erstellen, was zu einer saubereren, linearen Historie führt. Vorsichtig bei Branches, die bereits gepusht und geteilt wurden.
- Wie zu verwenden:
```
git switch feature/my-new-feature
git rebase main
```
git reset --hard HEAD~1 / git revert HEAD
- Was es tut: Beide machen Änderungen rückgängig, aber auf unterschiedliche Weise:
  - git reset --hard HEAD~1: Bewegt den aktuellen Branch-Zeiger einen Commit zurück und verwirft alle Änderungen im Arbeitsverzeichnis und Staging-Bereich. Dies schreibt die Historie um.
  - git revert HEAD: Erstellt einen neuen Commit, der die Änderungen des angegebenen Commits rückgängig macht. Dies bewahrt die Historie.
- Wann zu verwenden:
  - git reset --hard: Um den letzten Commit (und alle nicht committeden Änderungen) lokal vollständig zu verwerfen, insbesondere wenn Sie ihn noch nicht gepusht haben. Mit äußerster Vorsicht verwenden, da Daten verloren gehen.
  - git revert: Um einen Commit rückgängig zu machen, der bereits zu einem gemeinsamen Remote gepusht wurde, da er einen neuen Commit erstellt, der die Änderungen explizit umkehrt und eine klare Historie beibehält.
- Wie zu verwenden:
```
git reset --hard HEAD~1 # Discard last commit
git revert HEAD         # Create a new commit that undoes the last one
```
.gitignore-Datei
- Was es tut: Eine reine Textdatei im Stammverzeichnis Ihres Repositorys, die Git mitteilt, welche Dateien oder Verzeichnisse ignoriert werden sollen. Git wird diese Dateien nicht verfolgen und sie auch nicht als unverfolgt anzeigen.
- Wann zu verwenden: Um zu verhindern, dass unnötige Dateien (wie Build-Artefakte, temporäre Dateien, IDE-Konfiguration oder sensible Anmeldeinformationen) ins Repository committed werden.
- Wie zu verwenden: Erstellen Sie eine Datei namens .gitignore in Ihrem Projektstamm und listen Sie Muster für zu ignorierende Dateien/Ordner auf.
```
# Example .gitignore content
/node_modules/
.env
*.log
build/
```

    <a href="#" class="go-to-top">Nach oben</a>

Diese Befehle stellen eine leistungsstarke Teilmenge der Fähigkeiten von Git dar. Indem Sie ihren Zweck verstehen und wissen, wann Sie sie anwenden, können Sie die Historie Ihres Projekts navigieren, Branches verwalten und effizienter zusammenarbeiten. Regelmäßige Übung mit diesen Befehlen wird Ihre Git-Vertrautheit festigen und Ihren Entwicklungsworkflow verbessern.

Git-Befehle meistern: Ein praktischer Leitfaden

1. Konfigurationsbefehle

Verstehen und Verwenden von user.signingkey

2. Verzweigungen und Navigation

3. Commits und Historieninspektion

4. Tagging und Hilfswerkzeuge

5. Essentielle tägliche Workflow-Befehle

Verstehen und Verwenden von `user.signingkey`