Git

Was ist Git?

Git ist ein verteiltes Versionsverwaltungssystem, das Änderungen an Dateien über einen Zeitraum hinweg verfolgt. Es ermöglicht Ihnen, zu jedem beliebigen Zeitpunkt Snapshots Ihres Projekts zu speichern, Versionen zu vergleichen, Fehler rückgängig zu machen und mit anderen Personen zusammenzuarbeiten, ohne die Arbeit der anderen zu überschreiben.

Git wurde 2005 von Linus Torvalds entwickelt, um den Linux-Kernel zu verwalten, und hat sich zum weltweit am häufigsten verwendeten Versionsverwaltungssystem entwickelt. Egal, ob Sie ein Solo-Nebenprojekt aufbauen oder zu einer Codebasis mit tausenden Entwicklern beitragen – Git ist das Werkzeug, das dies ermöglicht.

Die Grundidee ist einfach: Anstatt eine einzige Kopie Ihres Projekts zu speichern, speichert Git eine Serie von Commits – Snapshots jeder verfolgten Datei zu einem bestimmten Zeitpunkt. Sie können in der Zeit zurückreisen, Versionen vergleichen, Branches erstellen, um neue Ideen auszuprobieren, und Ihre Arbeit wieder zusammenführen, wenn sie fertig ist. Dieses Modell skaliert von einer einzelnen Person bis hin zu Tausenden.

Warum Versionsverwaltung wichtig ist

Ohne Versionsverwaltung ist Zusammenarbeit pures Chaos. Wenn zwei Personen gleichzeitig an derselben Datei arbeiten, wird zwangsläufig die Arbeit von jemandem überschrieben. Ein Bug, der letzte Woche eingeschlichen wurde, bedeutet, dass man stundenlange Änderungen manuell rückgängig machen muss. Ein fehlgeschlagenes Feature-Experiment bedeutet, dass man wieder ganz von vorne anfangen muss.

Git löst all diese Probleme:

• Jede Änderung tracken — wer was, wann und warum geändert hat. Die vollständige Historie ist immer verfügbar.
• Sicher zurücksetzen — kehre zu jedem beliebigen früheren Zustand zurück, ohne aktuelle Arbeit zu verlieren.
• Parallel arbeiten — Branches ermöglichen es mehreren Personen, gleichzeitig an verschiedenen Features zu arbeiten.
• Angstfrei kollaborieren — Git führt Änderungen intelligent zusammen und markiert Konflikte, damit du sie lösen kannst.
• Offline arbeiten — alles bleibt lokal, bis du dich entscheidest, die Änderungen auf einen Remote-Server zu pushen.

Versionsverwaltung ist in der professionellen Entwicklung nicht optional. Es ist eine grundlegende Fähigkeit, die jeder Entwickler benötigt, unabhängig von Sprache, Framework oder Plattform.

Wie Git funktioniert

Git arbeitet mit drei Hauptbereichen: dem working directory, der staging area und dem repository.

Ihr working directory ist der Ort, an dem Sie Dateien bearbeiten. Wenn Sie git add ausführen, werden die Änderungen in die staging area verschoben – eine Vorbereitungszone für den nächsten Commit. Wenn Sie git commit ausführen, werden die gestagten Änderungen als neuer Snapshot im repository gespeichert.

# Edit a file in your working directory
echo "Hello, Git!" > hello.txt

# Stage the change
git add hello.txt

# Commit the staged change
git commit -m "Add hello.txt"

Dieser dreistufige Ablauf – bearbeiten, stagen, committen – gibt Ihnen die präzise Kontrolle darüber, was in jeden Snapshot einfließt. Sie können Teile einer Datei stagen, mehrere Dateien gemeinsam stagen und Commits erstellen, die jeweils eine einzelne logische Änderung repräsentieren.

Im Hintergrund speichert Git Daten als directed acyclic graph (DAG) von Commit-Objekten. Jeder Commit verweist auf seinen Parent und bildet so eine Historienkette. Branches sind lediglich leichtgewichtige Pointer auf spezifische Commits, und HEAD ist ein Pointer auf den Commit, auf dem Sie sich gerade befinden.

Git installieren

Git ist für alle gängigen Betriebssysteme verfügbar:

macOS:

# Using Homebrew
brew install git

# Or install Xcode Command Line Tools
xcode-select --install

Windows:

# Download from git-scm.com or use winget
winget install Git.Git

Linux:

# Debian/Ubuntu
sudo apt install git

# Fedora
sudo dnf install git

# Arch
sudo pacman -S git

Überprüfe die Installation:

git --version
# git version 2.45.0

Lege nach der Installation deine Identität fest – diese Informationen werden in jedem deiner Commits gespeichert:

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

Zentrale Git-Befehle

Ein Repository erstellen

# Start a new repository in the current directory
git init

# Clone an existing repository
git clone https://github.com/user/repo.git

git init erstellt einen versteckten .git/-Ordner, der alle Tracking-Daten von Git enthält. git clone kopiert ein bestehendes Repository – einschließlich der vollständigen Historie – auf deinen Rechner.

Änderungen tracken

# See which files are modified, staged or untracked
git status

# Stage a specific file
git add filename.js

# Stage all changes
git add .

# Commit with a message
git commit -m "Add user authentication"

git status ist der Befehl, den du am häufigsten ausführen wirst. Er zeigt dir, was sich geändert hat, was im Stage-Bereich liegt und was Git nicht trackt. Überprüfe immer den Status, bevor du einen Commit durchführst.

Historie einsehen

# Show commit history
git log

# Compact one-line format
git log --oneline

# Show changes in each commit
git log -p

# Show a visual branch graph
git log --oneline --graph --all

Die Commit-Historie ist die Timeline deines Projekts. Nutze sie, um zu verstehen, wie sich der Code entwickelt hat, wer Änderungen vorgenommen hat und warum bestimmte Entscheidungen getroffen wurden.

Änderungen vergleichen

# Diff between working directory and staging area
git diff

# Diff between staging area and last commit
git diff --staged

# Diff between two commits
git diff abc1234 def5678

git diff zeigt dir exakt an, was sich zeilenweise geändert hat. Das ist essenziell, um die eigene Arbeit vor dem Commit zu prüfen und um zu verstehen, was jemand anderes in einem Pull Request geändert hat.

Änderungen rückgängig machen

# Discard changes in working directory
git checkout -- filename.js

# Unstage a file
git reset HEAD filename.js

# Amend the last commit
git commit --amend -m "Updated commit message"

# Revert a commit (creates a new commit that undoes it)
git revert abc1234

Git macht Experimente sicher, da du jederzeit zurückkehren kannst. Der Schlüssel liegt darin, den Unterschied zwischen dem Verwerfen von Änderungen, dem Entfernen aus dem Stage-Bereich und dem Erstellen neuer Commits zu verstehen, die vorherige Änderungen rückgängig machen.

Mit Branches arbeiten

# List branches
git branch

# Create a new branch
git branch feature-login

# Switch to a branch
git checkout feature-login

# Create and switch in one command
git checkout -b feature-signup

# Delete a branch
git branch -d feature-login

Branches sind die Superkraft von Git. Sie ermöglichen es dir, an neuen Features zu arbeiten, Bugs zu fixen oder zu experimentieren, ohne die Haupt-Codebasis zu beeinflussen. Wenn deine Arbeit fertig ist, mergest du den Branch zurück.

Mergen und Rebasing

Wenn ein Branch fertig ist, integrierst du ihn zurück in den Hauptzweig. git merge erstellt einen Merge-Commit, der die beiden Historien zusammenführt, während git rebase deine Commits auf einen anderen Branch setzt, um eine lineare Historie zu erhalten:

# Merge a feature branch into main
git checkout main
git merge feature-login

# Rebase a feature branch onto the latest main
git checkout feature-login
git rebase main

Wenn dieselben Zeilen in beiden Branches geändert wurden, stoppt Git und markiert die Dateien als konflikthaft. Bearbeite die Dateien, um den korrekten Inhalt beizubehalten, entferne die Konfliktmarker (<<<<<<<, =======, >>>>>>>), setze sie dann in den Stage-Bereich und fahre fort:

git add .
git merge --continue   # or: git rebase --continue

Um die Historie übersichtlich zu halten, fasst ein Squash Merge jeden Commit eines Feature-Branches zu einem einzigen Commit auf dem Ziel-Branch zusammen:

git checkout main
git merge --squash feature-dark-mode
git commit -m "Add dark mode feature"

Nutze Merge, wenn du die vollständige Branch-Historie bewahren möchtest; nutze Rebase oder Squash, wenn du einen sauberen, linearen Haupt-Branch bevorzugst. Führe niemals ein Rebase oder Squash für Commits durch, die bereits in einen gemeinsamen Branch gepusht wurden.

Synchronisation mit Remotes

# Add a remote server
git remote add origin https://github.com/user/repo.git

# Push commits to remote
git push origin main

# Pull latest changes
git pull origin main

# Fetch without merging
git fetch origin

Remotes sind Kopien deines Repositories, die auf Servern gehostet werden. Der Standard-Remote heißt normalerweise origin. Push sendet deine Commits an den Remote, und Pull lädt Remote-Änderungen herunter und mergt sie in deinen Branch.

Die .gitignore-Datei

Nicht alles sollte versioniert werden. Abhängigkeiten, Build-Outputs, Environment-Dateien und IDE-Einstellungen werden typischerweise ignoriert:

# Dependencies
node_modules/
vendor/

# Build output
dist/
build/

# Environment variables
.env
.env.local

# IDE settings
.vscode/
.idea/

# OS files
.DS_Store
Thumbs.db

Erstelle eine .gitignore-Datei im Root-Verzeichnis deines Repositories. Git wird jede Datei oder jedes Verzeichnis überspringen, das diesen Mustern entspricht. Falls du Dateien bereits committet hast, die du nun ignorieren möchtest, entferne sie zuerst aus dem Tracking:

git rm -r --cached node_modules/
git commit -m "Remove node_modules from tracking"

Commits verstehen

Ein Commit ist die grundlegende Einheit von Git. Jeder Commit enthält:

• Einen eindeutigen Hash — eine 40-stellige SHA-1-Kennung wie a1b2c3d4e5f6...
• Eine Message — eine Beschreibung dessen, was geändert wurde und warum
• Einen Autor — wer die Änderung vorgenommen hat
• Einen Zeitstempel — wann die Änderung vorgenommen wurde
• Einen Parent — den Commit, auf dem er aufbaut (außer beim ersten Commit)
• Einen Snapshot — den Zustand aller getrackten Dateien zu diesem Zeitpunkt

Gute Commit-Messages folgen einer Konvention. Die erste Zeile ist eine kurze Zusammenfassung im Imperativ (unter 72 Zeichen). Ein optionaler Body erklärt den Kontext:

git commit -m "Fix null pointer in user authentication

The login endpoint was throwing a 500 error when the email
field was missing from the request body. Added a null check
before accessing user properties."

Jeder Commit sollte eine einzige logische Änderung repräsentieren. Dies erleichtert das Verständnis, das Review und das Revert einzelner Änderungen, ohne nicht zusammenhängende Arbeit zu beeinflussen.

Gängige Git-Workflows

Centralized Workflow

Alle arbeiten auf dem main-Branch. Einfach, aber für Teams riskant:

git pull origin main
# make changes
git add .
git commit -m "Update feature"
git push origin main

Feature Branch Workflow

Jedes Feature oder jeder Fix erhält einen eigenen Branch. Merges erfolgen über Pull Requests:

git checkout -b feature-user-profile
# make changes
git push origin feature-user-profile
# open a pull request on GitHub

Gitflow Workflow

Ein strukturiertes Modell mit main-, develop-, feature-, release- und hotfix-Branches. Am besten geeignet für Projekte mit geplanten Releases:

git checkout -b develop
git checkout -b feature-new-login
# work on feature
git checkout develop
git merge feature-new-login
git checkout -b release-v1.0
# finalize release
git checkout main
git merge release-v1.0
git tag v1.0.0

Trunk-based Development

Alle committen häufig direkt in den main (den Trunk) und nutzen kurzlebige Feature Flags. Besonders beliebt bei Unternehmen wie Google und Meta:

git checkout main
# make small, frequent changes
git add .
git commit -m "Add feature flag for new dashboard"
git push origin main

Best Practices

• Früh und oft committen — kleine Commits sind einfacher zu verstehen und rückgängig zu machen.
• Klare Commit-Messages schreiben — verwende den Imperativ und erkläre das „Warum“, nicht nur das „Was“.
• Ein Branch pro Feature — halte den main-Branch sauber und deploybar.
• Pull vor dem Push — integriere immer erst die Remote-Änderungen, bevor du deine Arbeit teilst.
• Den eigenen Diff prüfen — führe git diff --staged vor dem Commit aus, um Fehler abzufangen.
• Niemals Secrets committen — verwende Umgebungsvariablen und .gitignore.
• Releases taggen — nutze Semantic Version Tags wie v1.0.0 für einfaches Rollback.
• Historie sauber halten — rebase Feature-Branches vor dem Mergen, um unübersichtliche Merge-Commits zu vermeiden.

Häufige Fehler

• Zu viele nicht zusammenhängende Änderungen in einem einzigen Commit speichern.
• Vage Commit-Nachrichten wie „fix“ oder „update“ verwenden, die nichts aussagen.
• Force-Pushing in gemeinsam genutzte Branches, wodurch die Arbeit anderer überschrieben wird.
• Keine .gitignore einrichten, was dazu führt, dass node_modules oder .env-Dateien committet werden.
• Direkt auf main arbeiten, anstatt einen Feature-Branch zu erstellen.
• Vergessen, vor dem Pushen zu pullen, was zu Merge-Konflikten führt.
• Keine Backups von Remote-Repositories erstellen – lokal allein reicht nicht aus.

Was du als Nächstes lernen solltest

Du beherrschst nun die Git-Grundlagen: Repositories, Commits, Branches, Merging und Remotes. Der nächste logische Schritt ist GitHub für die Cloud-Kollaboration, Issues, Pull Requests und Actions. Such dir ein Projekt aus, baue etwas Reales und lass die praktische Erfahrung wachsen.