Git ist das weltweit meistgenutzte Versionskontrollsystem und gehört zum Standardwerkzeug jedes Entwicklers. Ob Einzelprojekt oder großes Team: Wer Git beherrscht, kann Änderungen nachvollziehen, gezielt zurücksetzen und parallel an mehreren Features arbeiten. Dieses Tutorial erklärt die wichtigsten Git-Befehle mit praxisnahen Beispielen und zeigt, wie du Git in PHP-Projekten richtig einsetzt.
Warum Git für Entwickler unverzichtbar ist
Ohne Versionskontrolle wird Softwareentwicklung schnell chaotisch. Wer schon einmal eine funktionierende Datei überschrieben hat oder nicht mehr weiß, welche Änderung einen Fehler verursacht hat, kennt das Problem. Git löst genau das: Jede Änderung wird in einem Commit festgehalten, und der gesamte Verlauf bleibt jederzeit abrufbar.
Git arbeitet dezentral. Jeder Entwickler hat eine vollständige Kopie des Repositories auf seinem Rechner. Das bedeutet: Du kannst offline arbeiten, Branches erstellen und Commits anlegen, ohne auf einen zentralen Server angewiesen zu sein. Erst wenn du bereit bist, synchronisierst du deine Änderungen mit dem Team.
Dieser Leitfaden eignet sich sowohl zum Lernen als auch zum Nachschlagen. Die Befehle sind nach typischen Arbeitsschritten geordnet, sodass du sie genau dann findest, wenn du sie brauchst.
Git installieren und einrichten
Bevor du mit Git arbeiten kannst, muss es auf deinem System installiert und konfiguriert sein. Die Installation ist auf allen gängigen Betriebssystemen unkompliziert.
Installation
Je nach Betriebssystem gibt es unterschiedliche Wege:
# Windows: Installer von https://git-scm.com herunterladen
# macOS: Ueber Homebrew
brew install git
# Linux (Debian/Ubuntu)
sudo apt install git
# Linux (Fedora/RHEL)
sudo dnf install git
# Version pruefen
git --version
Grundkonfiguration
Nach der Installation solltest du deinen Namen und deine E-Mail-Adresse hinterlegen. Git verwendet diese Angaben für jeden Commit.
git config --global user.name "Max Mustermann"
git config --global user.email "max@example.com"
/* Optionaler Standard-Editor */
git config --global core.editor "nano"
/* Alle globalen Einstellungen anzeigen */
git config --global --list
Die Option --global speichert die Werte in ~/.gitconfig. Wenn du für ein bestimmtes Projekt andere Angaben brauchst, lässt du --global einfach weg.
Den Git-Workflow verstehen
Bevor du mit den einzelnen Befehlen startest, hilft es, den grundlegenden Ablauf zu verstehen. Git arbeitet mit drei zentralen Ebenen:
Das Arbeitsverzeichnis ist dein Projektordner mit allen Dateien. Der Staging-Bereich (auch Index genannt) dient als Zwischenspeicher, in dem du auswählst, welche Änderungen in den nächsten Commit einfließen sollen. Das lokale Repository enthält die gespeicherten Commits mit der vollständigen Historie.
Der normale Arbeitszyklus lautet: Dateien bearbeiten, zum Staging hinzufügen, committen. Dieser Dreischritt wiederholt sich bei jeder Änderung.
Repositories erstellen und klonen
Jedes Git-Projekt beginnt mit einem Repository. Du kannst entweder ein neues anlegen oder ein bestehendes klonen.
Ein neues Repository anlegen
# Neues Repository im aktuellen Verzeichnis
git init
# Mit bestimmtem Branch-Namen (ab Git 2.28)
git init -b main
Der Befehl git init erstellt einen versteckten .git-Ordner. Dieser Ordner enthält die gesamte Versionshistorie und die Konfiguration des Repositories.
Ein bestehendes Repository klonen
# Repository von GitHub/GitLab klonen
git clone https://github.com/orga/projekt.git
# In ein bestimmtes Verzeichnis klonen
git clone https://github.com/orga/projekt.git mein-ordner
Beim Klonen wird automatisch ein Remote namens origin angelegt, der auf die Quell-URL zeigt. Der Standard-Branch (meist main oder master) wird ausgecheckt.
Änderungen verfolgen und vorbereiten
Im Arbeitsalltag verbringst du die meiste Zeit damit, Änderungen vorzunehmen und für den nächsten Commit vorzubereiten. Die folgenden Befehle helfen dir dabei.
Status prüfen
# Ausfuehrlicher Status
git status
# Kompakte Kurzform
git status -sb
Der Status zeigt dir, welche Dateien geändert, neu oder gelöscht wurden. Nutze ihn regelmäßig, um den Überblick zu behalten.
Dateien zum Staging hinzufügen
# Einzelne Datei stagen
git add index.php
# Alle Aenderungen stagen
git add .
# Interaktives Staging (Teile einer Datei)
git add -p
Mit git add -p kannst du einzelne Abschnitte (Hunks) einer Datei auswählen. Das ist nützlich, wenn eine Datei mehrere unabhängige Änderungen enthält, die in separate Commits gehören.
Unterschiede anzeigen
# Aenderungen im Arbeitsverzeichnis (nicht gestaged)
git diff
# Bereits gestagede Aenderungen
git diff --staged
# Unterschied zwischen zwei Branches
git diff main..feature/login
Änderungen speichern (Committen)
Ein Commit speichert den aktuellen Zustand des Staging-Bereichs dauerhaft im Repository. Jeder Commit erhält eine eindeutige ID (SHA-1-Hash) und eine Nachricht, die beschreibt, was geändert wurde.
# Commit mit Nachricht
git commit -m "Login-Formular validieren"
# Staging und Commit in einem Schritt
# (nur bereits getrackte Dateien)
git commit -am "Bugfix: E-Mail-Validierung"
# Letzte Commit-Nachricht aendern (nur lokal!)
git commit --amend -m "Neue Nachricht"
Gute Commit-Nachrichten erleichtern das Arbeiten später enorm. Verwende den Imperativ, halte die erste Zeile unter 50 Zeichen und beschreibe bei Bedarf Details im Body. Eine nachvollziehbare Historie hilft bei Code-Reviews, bei der Fehlersuche und beim Erstellen von Changelogs.
Historie ansehen
# Kompakte Ansicht mit Branch-Graph
git log --oneline --graph --decorate --all
# Letzte 5 Commits
git log -5
# Aenderungen eines bestimmten Commits anzeigen
git show abc1234
Nutze q, um die Log-Ansicht zu verlassen. Mit git log --oneline bekommst du eine schnelle Übersicht über die letzten Commits.
Arbeiten mit Remote-Repositorys
In den meisten Projekten arbeitest du nicht nur lokal, sondern synchronisierst deine Änderungen mit einem entfernten Repository auf GitHub, GitLab oder Bitbucket.
Remotes verwalten
# Bestehende Remotes anzeigen
git remote -v
# Neues Remote hinzufuegen
git remote add origin https://github.com/user/repo.git
# Remote-URL aendern
git remote set-url origin https://github.com/user/neues-repo.git
Lokale Commits hochladen (push)
# Ersten Push mit Tracking-Verbindung
git push -u origin main
# Danach reicht:
git push
Die Option -u (oder --set-upstream) verknüpft deinen lokalen Branch mit dem Remote-Branch. Nach dem ersten Push kannst du einfach git push ohne weitere Argumente verwenden.
Änderungen holen und integrieren
# Nur herunterladen (ohne Integration)
git fetch origin
# Herunterladen und integrieren
git pull origin main
# Pull mit Rebase (lineare Historie)
git pull --rebase origin main
git fetch lädt die Änderungen herunter, ohne sie in deinen Branch einzubauen. Du kannst die Änderungen dann in Ruhe prüfen, bevor du sie mit git merge integrierst. git pull kombiniert beide Schritte. In Teams ist fetch oft die sicherere Wahl, weil du vor dem Merge prüfen kannst, was sich geändert hat.
Mit Branches arbeiten
Branches sind eines der mächtigsten Features von Git. Sie ermöglichen dir, neue Funktionen oder Bugfixes isoliert vom Hauptzweig zu entwickeln, ohne den stabilen Code zu gefährden.
Branches erstellen und wechseln
# Alle lokalen Branches anzeigen
git branch
# Auch Remote-Branches anzeigen
git branch -a
# Neuen Branch erstellen
git branch feature/login
# Zum Branch wechseln
git switch feature/login
# Erstellen und wechseln in einem Schritt
git switch -c hotfix/bug42
Der Befehl git switch hat git checkout als empfohlene Variante zum Branch-Wechsel abgelöst. checkout funktioniert weiterhin, aber switch macht die Absicht klarer.
Branches zusammenführen (Merge)
# Feature-Branch in main integrieren
git switch main
git merge feature/login
Git unterscheidet zwei Merge-Typen: Ein Fast-Forward-Merge verschiebt den Branch-Zeiger einfach nach vorn, wenn keine parallelen Änderungen existieren. Ein Three-Way-Merge erstellt einen neuen Merge-Commit, wenn sich die Historien verzweigt haben.
Merge-Konflikte lösen
Wenn zwei Branches dieselbe Stelle einer Datei geändert haben, meldet Git einen Konflikt. Die betroffene Datei enthält dann Markierungen:
<<<<<<< HEAD
Deine Aenderung
=======
Aenderung aus dem anderen Branch
>>>>>>> feature/login
Bearbeite die Datei, entferne die Markierungen und wähle die richtige Variante. Dann speicherst du die Datei, fügst sie mit git add zum Staging hinzu und schließt den Merge mit git commit ab.
Branch löschen
# Sicher loeschen (nur gemergte Branches)
git branch -d feature/login
# Loeschen erzwingen
git branch -D feature/login
# Remote-Branch loeschen
git push origin --delete feature/login
Änderungen rückgängig machen
Fehler passieren. Git bietet mehrere Möglichkeiten, Änderungen rückgängig zu machen. Welcher Befehl der richtige ist, hängt davon ab, ob die Änderungen bereits committed oder sogar gepusht wurden.
Änderungen im Arbeitsverzeichnis verwerfen
# Einzelne Datei zuruecksetzen
git restore index.php
# Alle Aenderungen verwerfen
git restore .
Staging zurücksetzen
# Datei aus dem Staging entfernen
git restore --staged config.php
# Aeltere Syntax
git reset config.php
Die Datei bleibt dabei geändert im Arbeitsverzeichnis. Es wird nur die Staging-Markierung entfernt.
Commits rückgängig machen
Bei öffentlichen Commits (bereits gepusht) verwendest du git revert, weil es einen neuen Commit erstellt und die Historie nicht verändert. Bei rein lokalen Commits kannst du git reset nutzen.
# Oeffentlicher Commit: Neuen Gegen-Commit erstellen
git revert abc1234
# Lokaler Commit: HEAD zuruecksetzen
git reset --soft HEAD~1 # Aenderungen bleiben gestaged
git reset --mixed HEAD~1 # Aenderungen bleiben im Arbeitsverzeichnis
git reset --hard HEAD~1 # Alles verwerfen (Vorsicht!)
Faustregel: Verwende revert für geteilte Branches und reset nur für lokale Korrekturen.
Unfertige Arbeit zwischenspeichern (Stash)
Wenn du mitten in der Arbeit den Branch wechseln musst, kannst du deine Änderungen mit git stash beiseitelegen.
# Aenderungen weglegen
git stash
# Gespeicherte Stashes anzeigen
git stash list
# Anwenden und Stash behalten
git stash apply
# Anwenden und Stash loeschen
git stash pop
.gitignore für PHP-Projekte
Nicht jede Datei gehört ins Repository. Abhängigkeiten, die Composer verwaltet, Umgebungskonfigurationen mit Passwörtern und temporäre Cache-Dateien sollten ausgeschlossen werden. Dafür legst du im Projektroot eine .gitignore-Datei an.
# Composer-Abhaengigkeiten (werden per composer install geladen)
/vendor/
# Umgebungskonfiguration (enthaelt Passwoerter, API-Keys)
.env
.env.local
.env.*.local
# Cache und temporaere Dateien
/cache/
/tmp/
*.log
# PHPUnit und Analyse-Tools
.phpunit.result.cache
.php-cs-fixer.cache
phpstan.neon.local
# IDE-Konfigurationen
.idea/
.vscode/
*.swp
*.swo
# Betriebssystem-Dateien
.DS_Store
Thumbs.db
# Node.js (falls Frontend-Build vorhanden)
/node_modules/
/public/build/
Der wichtigste Eintrag ist /vendor/. Dieses Verzeichnis enthält alle per Composer installierten Pakete und kann jederzeit mit composer install wiederhergestellt werden. Es ins Repository aufzunehmen würde unnötig Speicher verbrauchen und Merge-Konflikte provozieren.
Die .env-Datei enthält häufig Datenbank-Zugangsdaten und API-Schlüssel. Stattdessen legst du eine .env.example ins Repository, die als Vorlage dient, aber keine echten Werte enthält.
Composer und Git
PHP-Projekte verwenden Composer zur Paketverwaltung. Im Zusammenspiel mit Git gibt es eine häufige Frage: Soll die composer.lock ins Repository?
Die Antwort: Ja, immer. Die composer.json beschreibt, welche Pakete dein Projekt braucht, oft mit flexiblen Versionsbereichen wie ^8.0. Die composer.lock dagegen enthält die exakten Versionen, die zuletzt installiert wurden. Wenn du sie committest, stellt composer install auf jedem Rechner und auf dem Server dieselben Versionen her.
# composer.lock gehoert ins Repository
git add composer.json composer.lock
git commit -m "Composer-Abhaengigkeiten aktualisieren"
# Auf einem anderen Rechner oder dem Server:
composer install # Installiert exakt die Versionen aus der Lock-Datei
Bei Merge-Konflikten in der composer.lock löst du den Konflikt am einfachsten so:
# composer.json manuell zusammenfuehren, dann:
git checkout --theirs composer.lock
composer update --lock
git add composer.lock
Der Feature-Branch-Workflow
Die einzelnen Git-Befehle zu kennen ist wichtig. Noch wichtiger ist es aber, sie im richtigen Zusammenspiel einzusetzen. Der Feature-Branch-Workflow ist das am häufigsten verwendete Arbeitsmodell in der Praxis.
Die Grundidee: Jede neue Funktion oder jeder Bugfix bekommt einen eigenen Branch. Erst wenn die Arbeit abgeschlossen und geprüft ist, wird sie in den Hauptbranch integriert. Das folgende Beispiel zeigt einen typischen Ablauf am Beispiel eines PHP-Projekts:
# 1. Aktuellen main-Branch holen
git switch main
git pull origin main
# 2. Feature-Branch erstellen
git switch -c feature/user-export
# 3. Arbeiten und committen
# (z.B. UserExportController.php anlegen)
git add src/Controller/UserExportController.php
git commit -m "Feature: CSV-Export fuer Benutzerliste"
# Weitere Aenderungen...
git add src/Service/CsvExporter.php
git commit -m "Service: CsvExporter implementieren"
# 4. Branch auf Remote pushen
git push -u origin feature/user-export
# 5. Pull Request auf GitHub/GitLab erstellen
# (ueber die Weboberflaeche)
# 6. Nach Approval: Branch mergen
git switch main
git merge feature/user-export
git push origin main
# 7. Feature-Branch aufraeumen
git branch -d feature/user-export
git push origin --delete feature/user-export
Dieser Workflow hat mehrere Vorteile: Der main-Branch bleibt stabil, weil nur geprüfter Code dort landet. Mehrere Entwickler können gleichzeitig an verschiedenen Features arbeiten, ohne sich gegenseitig zu behindern. Und durch Pull Requests entsteht eine natürliche Code-Review-Kultur im Team.
Rebase vs. Merge
Beim Integrieren von Änderungen aus einem Branch in einen anderen stehen zwei Strategien zur Verfügung: merge und rebase. Beide führen zum gleichen Ergebnis, unterscheiden sich aber in der entstehenden Historie.
git merge erstellt einen neuen Merge-Commit, der die Historien beider Branches zusammenführt. Die Verzweigung bleibt in der Historie sichtbar. git rebase dagegen setzt deine Commits auf die Spitze des Zielbranches und erzeugt eine lineare Historie ohne Merge-Commits.
# Variante 1: Merge
git switch main
git merge feature/login
# Ergebnis: Merge-Commit, Verzweigung sichtbar
# Variante 2: Rebase
git switch feature/login
git rebase main
git switch main
git merge feature/login # Fast-Forward
# Ergebnis: Lineare Historie, keine Verzweigung
Wann welche Strategie? Verwende rebase für lokale Branches, die noch nicht gepusht wurden. Die lineare Historie ist sauberer und leichter lesbar. Verwende merge für geteilte Branches, an denen andere Entwickler arbeiten. Ein Rebase auf einem geteilten Branch ändert die Commit-IDs, was für alle Teammitglieder Probleme verursacht.
Wichtig: Rebase niemals auf öffentliche Branches anwenden, die andere Entwickler bereits ausgecheckt haben. Die goldene Regel lautet: Rebase nur das, was noch nicht geteilt wurde.
Zusammenarbeit im Team
Git entfaltet seine volle Stärke in der Teamarbeit. Pull Requests, Code Reviews und der bewusste Umgang mit dem Hauptbranch sind zentrale Elemente professioneller Softwareentwicklung.
Pull Requests
Ein Pull Request (bei GitLab auch Merge Request genannt) ist die Bitte, deinen Feature-Branch in den Hauptbranch zu integrieren. Andere Teammitglieder können den Code reviewen, Kommentare hinterlassen und Änderungen vorschlagen. Erst nach der Freigabe wird der Branch gemergt.
Pull Requests lassen sich auch über die Kommandozeile erstellen, wenn du die GitHub CLI installiert hast:
# GitHub CLI: Pull Request erstellen
gh pr create --title "CSV-Export" --body "Benutzerliste als CSV exportieren"
# Offene PRs anzeigen
gh pr list
# PR lokal auschecken und testen
gh pr checkout 42
Code Reviews
Code Reviews verbessern die Codequalität und verteilen das Wissen im Team. Achte beim Review auf logische Fehler, fehlende Validierung, Namenskonventionen und die Testabdeckung. Konstruktives Feedback hilft allen Beteiligten, besser zu werden.
Fork-Workflow
Bei Open-Source-Projekten hast du oft keinen direkten Schreibzugriff auf das Repository. In diesem Fall erstellst du einen Fork (eine persönliche Kopie), arbeitest dort in einem Branch und erstellst dann einen Pull Request gegen das Original-Repository.
# Fork auf GitHub erstellen (Weboberflaeche)
# Eigenen Fork klonen
gh repo fork orga/projekt --clone
# Upstream-Remote hinzufuegen
git remote add upstream https://github.com/orga/projekt.git
# Upstream-Aenderungen holen
git fetch upstream
git rebase upstream/main
Fehlersuche mit git bisect
Wenn ein Bug aufgetaucht ist, du aber nicht weißt, welcher Commit ihn verursacht hat, hilft git bisect. Der Befehl führt eine binäre Suche durch die Commit-Historie und findet den fehlerhaften Commit in wenigen Schritten.
# Bisect starten
git bisect start
# Aktueller Stand: Bug vorhanden
git bisect bad
# Bekannt funktionierender Stand
git bisect good abc1234
# Git checkt automatisch einen Commit aus.
# Testen, dann markieren:
git bisect good # oder: git bisect bad
# Nach wenigen Schritten wird der
# fehlerhafte Commit identifiziert.
# Zurueck zum normalen Zustand
git bisect reset
Bei 1000 Commits braucht git bisect nur etwa 10 Schritte statt einer manuellen Suche. Du kannst den Prozess sogar automatisieren, indem du ein Testskript angibst:
# Automatisiert: Testskript entscheidet
git bisect start HEAD abc1234
git bisect run php vendor/bin/phpunit tests/LoginTest.php
Weitere nützliche Befehle
Neben den Kernbefehlen bietet Git eine Reihe weiterer Werkzeuge für spezielle Situationen.
# Einzelnen Commit in anderen Branch uebernehmen
git cherry-pick abc1234
# Datei loeschen und Loeschung stagen
git rm src/tmp.log
# Datei umbenennen/verschieben
git mv README.md docs/README.md
# Versionsmarke setzen (fuer Releases)
git tag v1.0.0
git push origin v1.0.0
# Versteckte Historie aller HEAD-Bewegungen
# (Lebensretter nach versehentlichem Reset)
git reflog
git cherry-pick ist besonders nützlich, wenn ein Bugfix-Commit aus einem Feature-Branch auch in den Release-Branch übernommen werden soll, ohne den gesamten Branch zu mergen. git reflog zeigt jede Bewegung des HEAD-Zeigers und hilft, versehentlich gelöschte Commits wiederherzustellen.
SSH-Key vs. HTTPS
Für die Verbindung zu GitHub oder GitLab gibt es zwei Authentifizierungsmethoden. HTTPS verwendet Benutzername und Personal Access Token. SSH verwendet ein Schlüsselpaar und ist nach der Einrichtung bequemer, weil du kein Passwort mehr eingeben musst.
# SSH-Key generieren
ssh-keygen -t ed25519 -C "max@example.com"
# Oeffentlichen Schluessel anzeigen
cat ~/.ssh/id_ed25519.pub
# (Diesen Schluessel bei GitHub/GitLab hinterlegen)
# Verbindung testen
ssh -T git@github.com
# Repository per SSH klonen
git clone git@github.com:user/projekt.git
GitHub hat die Passwort-Authentifizierung über HTTPS abgeschafft. Du brauchst jetzt entweder einen Personal Access Token oder SSH-Keys. SSH-Keys sind die empfohlene Variante, weil du dich nicht bei jedem Push neu authentifizieren musst.
Troubleshooting: Häufige Git-Fehler beheben
Auch erfahrenen Entwicklern passieren Fehler im Umgang mit Git. Die folgenden Situationen treten regelmäßig auf, und die Lösungen sind einfacher als gedacht.
Auf den falschen Branch committed
# Letzten Commit zuruecknehmen (Aenderungen bleiben)
git reset --soft HEAD~1
# Zum richtigen Branch wechseln
git switch feature/login
# Dort erneut committen
git commit -am "Feature: Login-Formular"
Versehentlich gepushte Datei entfernen
Wenn du eine Datei wie .env oder eine Log-Datei versehentlich committed hast, kannst du sie aus dem Repository entfernen, ohne sie vom lokalen System zu löschen:
# Datei aus Repository entfernen, lokal behalten
git rm --cached .env
echo ".env" >> .gitignore
git add .gitignore
git commit -m "Env-Datei aus Tracking entfernen"
Detached HEAD reparieren
Ein detached HEAD bedeutet, dass du auf einem einzelnen Commit statt auf einem Branch stehst. Das passiert zum Beispiel, wenn du mit git checkout abc1234 einen alten Commit auschecken hast.
# Zurueck zum Branch wechseln
git switch main
# Falls du im detached HEAD Aenderungen gemacht hast:
git switch -c rettungs-branch
Merge abbrechen
# Laufenden Merge abbrechen
git merge --abort
# Laufenden Rebase abbrechen
git rebase --abort
Versehentliches reset --hard rückgängig machen
# Reflog zeigt alle HEAD-Bewegungen
git reflog
# Commit wiederherstellen
git reset --hard HEAD@{2}
Das Reflog ist dein Sicherheitsnetz. Es speichert jede HEAD-Bewegung der letzten 90 Tage, auch nach einem reset --hard.
Git-Aliase für den Alltag
Git-Aliase sind Abkürzungen für häufig verwendete Befehle. Einmal eingerichtet, sparst du bei jeder Nutzung Tipparbeit.
git config --global alias.s "status -sb"
git config --global alias.co "checkout"
git config --global alias.br "branch"
git config --global alias.cm "commit -m"
git config --global alias.lg "log --oneline --graph --decorate --all"
git config --global alias.last "log -1 HEAD"
git config --global alias.unstage "restore --staged"
Danach kannst du zum Beispiel git s statt git status -sb oder git lg für eine grafische Log-Ansicht verwenden. Probiere aus, welche Aliase deinen Workflow am meisten beschleunigen.
Tipps für die tägliche Arbeit
Ein paar bewährte Vorgehensweisen machen den Alltag mit Git deutlich angenehmer:
Klein und häufig committen. Kleine Commits lassen sich leichter reviewen, revertieren und mit git bisect durchsuchen. Ein Commit pro logischer Änderung ist ideal.
Commit-Nachrichten sorgfältig formulieren. Verwende den Imperativ in der ersten Zeile (z.B. „Validierung für E-Mail hinzufügen“) und halte sie unter 50 Zeichen. Zusätzliche Details gehören in den Body nach einer Leerzeile.
Regelmäßig pullen. Je länger du ohne git pull arbeitest, desto größer werden potenzielle Merge-Konflikte. Ein täglicher Pull zu Arbeitsbeginn beugt dem vor.
Hooks nutzen. Git Hooks wie pre-commit und commit-msg können automatisch Tests und Linting-Checks ausführen, bevor ein Commit erstellt wird. Das verhindert, dass fehlerhafter Code ins Repository gelangt.
Fazit und weiterführende Ressourcen
Git lässt sich am besten durch regelmäßige Anwendung lernen. Die wichtigsten Befehle für den Alltag sind status, add, commit, push, pull, branch, merge und restore. Zusammen mit einem sauberen Branch-Workflow und guten Commit-Nachrichten bist du für die meisten Projekte bestens gerüstet.
Wer tiefer einsteigen möchte, findet hier weiterführende Ressourcen:
Die offizielle Git-Dokumentation findest du unter https://git-scm.com/doc. Das frei verfügbare Buch „Pro Git“ gibt es auf Deutsch unter https://git-scm.com/book/de/v2. Und auf https://git-scm.com findest du außerdem die aktuelle Version zum Download.
Häufige Fragen (FAQ)
Zum Abschluss die Antworten auf Fragen, die in der Praxis immer wieder auftauchen.
Wie ändere ich die Commit-Nachricht des letzten Commits?
Mit git commit --amend -m "Neue Nachricht". Verwende das nur, solange der Commit noch nicht gepusht wurde. Nach einem Push müsstest du mit --force-with-lease pushen, was für Teammitglieder Probleme verursachen kann.
Was bedeutet „detached HEAD“?
Du befindest dich auf einem einzelnen Commit statt auf einem Branch. Das passiert häufig bei git checkout <commit-hash>. Wechsle mit git switch main zurück oder erstelle einen neuen Branch mit git switch -c mein-branch.
Wie entferne ich sensible Daten aus der Git-Historie?
Verwende das Tool git filter-repo (empfohlen) oder BFG Repo-Cleaner, um sensible Daten aus allen Commits zu entfernen. Danach musst du die bereinigte Historie mit git push --force-with-lease hochladen und alle Teammitglieder informieren. Rotiere außerdem alle betroffenen Passwörter und API-Keys, da die alten Werte in gecachten Versionen weiterhin sichtbar sein können.
Was ist der Unterschied zwischen fetch und pull?
git fetch lädt Änderungen vom Remote herunter, ohne sie in deinen aktuellen Branch einzubauen. git pull macht beides: Es führt ein fetch und anschließend ein merge aus. In Teams ist fetch oft die sicherere Wahl, weil du die Änderungen zuerst prüfen kannst.
Wann verwende ich rebase statt merge?
Verwende rebase für lokale Branches, um eine saubere lineare Historie zu erhalten. Verwende merge für geteilte Branches, um die Historie nicht umzuschreiben. Die goldene Regel: Rebase nur das, was noch nicht geteilt wurde.
