Git — was es ist, Funktionsprinzipien und Befehle

Was ist Git?

Git ist ein verteiltes Versionskontrollsystem (VCS), das Änderungen in Dateien verfolgt und mehreren Entwicklern ermöglicht, gleichzeitig am selben Projekt zu arbeiten. Im Gegensatz zu zentralisierten Systemen hat in Git jeder Entwickler eine vollständige Kopie des Repositorys, einschließlich des gesamten Änderungsverlaufs, was das System resistent gegen Datenverlust macht und keine ständige Verbindung zu einem zentralen Server erfordert.

Die Geschichte von Git begann im Jahr 2005, als Linus Torvalds ein neues VCS erstellte, nachdem BitKeeper seine kostenlose Lizenz für Linux-Kernel-Entwickler entzogen hatte. Die Ziele waren: Geschwindigkeit, Einfachheit der Architektur, Unterstützung für nichtlineare Entwicklung durch Verzweigung und vollständige Verteilung. In 3 Monaten schrieb Torvalds den Kern von Git, und innerhalb eines Jahres wurde das Projekt unter der Leitung von Junio Hamano selbstverwaltet.

Laut der Stack Overflow-Umfrage (2024) wird Git von 93,9% der professionellen Entwickler verwendet, was es zum dominierenden Versionskontrollsystem in der Branche macht. Der nächste Konkurrent — Subversion (SVN) — wird nur in 5,2% der Projekte eingesetzt, hauptsächlich in großen Unternehmensumgebungen mit zentralisierten Prozessen.

Wie Git funktioniert: Repository und Commits

Git-Repository ist ein Verzeichnis, in dem Git Änderungen an allen Dateien verfolgt. Innerhalb des Verzeichnisses befindet sich ein versteckter Ordner .git, der alle Systemobjekte speichert: Commits, Bäume, Blobs und Referenzen. Wenn ein Entwickler einen Commit erstellt, kopiert Git die Dateien nicht vollständig — es erstellt einen Snapshot und speichert eine Referenz darauf.

Jeder Commit enthält: einen eindeutigen SHA-1-Hash (40 Zeichen), eine Referenz auf den vorherigen Commit (Parent), Autor, Datum, Commit-Nachricht und eine Referenz auf einen Baum, der den Zustand der Dateien zum Zeitpunkt des Commits beschreibt. Die Kette von Commits bildet einen gerichteten azyklischen Graphen, in dem jeder Commit auf einen oder mehrere Eltern zeigt.

# Repository-Initialisierung
git init my-project
cd my-project

# Commit erstellen
echo "Hallo, Git" > README.md
git add README.md
git commit -m "Initial commit"

# Verlauf anzeigen
git log --oneline --graph --all

Git verwendet drei Hauptbereiche: working directory (Dateien auf der Festplatte), staging area (Index, in den vorbereitete Dateien kommen) und repository (Commit-Verlauf). Der Befehl git add verschiebt Änderungen vom Arbeitsverzeichnis in den Staging-Bereich, und git commit zeichnet den Inhalt des Staging-Bereichs im Repository auf. Diese Trennung ermöglicht es dem Entwickler, aus einer Reihe von Änderungen einen sinnvollen Commit zusammenzustellen, ohne jede Bearbeitung einzeln zu committen.

Grundlegende Git-Befehle

Grundlegende Git-Befehle decken 90% der täglichen Operationen eines Entwicklers ab. Der Befehl git clone erstellt eine lokale Kopie eines entfernten Repositorys, git pull holt Änderungen vom Server und führt sie mit dem aktuellen Branch zusammen, und git push sendet lokale Commits an den Server. Diese drei Befehle bilden den Hauptzyklus der Arbeit mit Git.

Zur Anzeige des Status wird git status verwendet — es zeigt, welche Dateien geändert, welche zum Staging hinzugefügt und welche nicht verfolgt werden. git diff zeigt spezifische Änderungen in Dateien vor dem Hinzufügen zum Staging. Nachfolgend finden Sie eine Tabelle mit den am häufigsten verwendeten Befehlen:

Zum Rückgängigmachen von Änderungen bietet Git mehrere Optionen. git reset bewegt den Branch-Zeiger auf einen bestimmten Commit und kann den Staging-Bereich oder das Arbeitsverzeichnis zurücksetzen. git revert erstellt einen neuen Commit, der die Änderungen des angegebenen Commits rückgängig macht — dies ist eine sichere Methode zum Rückgängigmachen für gemeinsame Branches, da der Verlauf nicht umgeschrieben wird.

Verzweigung in Git: main, feature und release

Branches in Git sind leichte bewegliche Zeiger auf einen bestimmten Commit. Das Erstellen eines neuen Branches kopiert keine Dateien, sondern erstellt lediglich einen neuen Zeiger, was die Verzweigung praktisch augenblicklich macht. Der main-Branch (früher master) ist der Hauptzweig des Projekts, der stabilen, releasefertigen Code enthält.

Die Standardpraxis ist die Verwendung von Git Flow oder GitHub Flow. Git Flow verwendet Branches: main (Release-Code), develop (Integrationsbranch), feature/* (neue Funktionen), release/* (Release-Vorbereitung) und hotfix/* (dringende Korrekturen). GitHub Flow ist einfacher: nur main und Feature-Branches, und alle Änderungen werden über Pull Request ausgeliefert.

# Branch erstellen und wechseln
git branch feature-auth
git checkout feature-auth
# oder mit einem Befehl:
git checkout -b feature-auth

# Liste der Branches
git branch --list
git branch -a  # alle Zweige, einschließlich gelöschter

# Branch löschen
git branch -d feature-auth

Eine wichtige Eigenschaft der Git-Verzweigung ist Cherry-Pick: das Verschieben eines einzelnen Commits von einem Branch zu einem anderen mit dem Befehl git cherry-pick <hash>. Dies ist nützlich, wenn Sie einen Bugfix von einem Feature-Branch in einen Release übertragen müssen, ohne den gesamten Branch zusammenzuführen. Git unterstützt auch Rebasing und interaktives Rebasing (git rebase -i) zum Squashen, Neuordnen und Bearbeiten von Commits.

Merge und Rebase

Merge (Zusammenführung) erstellt einen speziellen Merge-Commit mit zwei Eltern. Dieser Commit zeichnet die Tatsache der Zusammenführung zweier Branches auf und bewahrt den vollständigen Verlauf — man kann sehen, wo und wann die Zusammenführung stattfand. Merge bewahrt den Verlauf so, wie er erstellt wurde, was die Prüfung vereinfacht, aber den Commit-Graphen komplexer macht.

Rebase verschiebt anstatt einen Merge-Commit zu erstellen, die Commits des aktuellen Branches an die Spitze des Zielbranches. Der Verlauf wird linear — es entsteht der Eindruck, dass die Entwicklung sequenziell verlief. Allerdings überschreibt Rebase den Verlauf, ändert die SHA-1-Hashes der Commits und macht ihn gefährlich für gemeinsame Branches, auf die andere Entwickler Zugriff haben.

Empfehlung: Verwenden Sie merge für öffentliche Branches, deren Verlauf für andere Entwickler sichtbar ist (feature → develop), und rebase für lokale Arbeit, wenn Sie frische Änderungen von main auf Ihren Feature-Branch anwenden müssen, bevor Sie einen Pull Request erstellen. Die Regel ist einfach: Wenn ein Commit bereits an den Server gesendet wurde — rebasen Sie ihn nicht.

Konfliktlösung

Merge-Konflikt tritt auf, wenn Git Änderungen in einer einzelnen Datei nicht automatisch zusammenführen kann. Git markiert konfliktbehaftete Abschnitte in der Datei mit speziellen Markierungen: <<<<<<< (unsere Änderungen), ======= (Trennzeichen), >>>>>>> (deren Änderungen). Der Entwickler bearbeitet die Datei manuell, wählt die gewünschte Option oder kombiniert beide, und schließt die Zusammenführung mit einem Commit ab.

Arbeiten mit entfernten Repositorys

Entferntes Repository (Remote) ist eine Kopie eines Git-Repositorys, die sich auf einem Server befindet. GitHub, GitLab und Bitbucket sind die beliebtesten Plattformen zum Hosten entfernter Repositorys. Sie bieten eine Weboberfläche zum Anzeigen von Code, Zugriffsverwaltung, Code-Review und Integration mit CI/CD-Systemen.

In Git können Sie mehrere entfernte Repositorys für ein Projekt konfigurieren. Standardmäßig heißt das Haupt-Remote origin. Der Befehl git remote add fügt ein neues Remote hinzu, git fetch holt Änderungen ohne Zusammenführung, und git pull ist eine Abkürzung für git fetch + git merge. Für die Arbeit mit Code über Pull Request erstellt ein Entwickler einen Fork des Repositorys, klont es, arbeitet in einem Feature-Branch und sendet eine Merge-Anfrage an das ursprüngliche Repository.

# Entferntes Repository hinzufügen
git remote add origin https://github.com/user/repo.git

# Entfernte Repositorys anzeigen
git remote -v

# Branch an Server senden
git push -u origin feature-auth

# Änderungen von einem entfernten Branch holen
git pull origin main

Entfernte Repositorys unterstützen Tagging zur Markierung von Release-Versionen. Tags können leichtgewichtig (nur ein Zeiger auf einen Commit) oder annotiert (enthalten Metadaten: Autor, Datum, Nachricht) sein. Annotierte Tags werden für Release-Versionen empfohlen, da sie vollständige Versionsinformationen tragen und mit einem GPG-Schlüssel zur Verifizierung der Autorenschaft signiert werden können.

Git Worktree für paralleles Arbeiten

Git Worktree ermöglicht es, gleichzeitig mit mehreren Branches in verschiedenen Verzeichnissen zu arbeiten, ohne zwischen ihnen wechseln zu müssen. Der Befehl git worktree add ../feature-auth feature-auth erstellt ein neues Arbeitsverzeichnis feature-auth, in dem Sie Code schreiben können, ohne den Branch im Hauptverzeichnis zu wechseln. Worktree ist nützlich für schnelle Korrekturen in einem Release-Branch, wenn das Hauptverzeichnis mit einer langfristigen Entwicklung beschäftigt ist.

Git Submodules für Abhängigkeiten

Git Submodules ist ein Mechanismus zum Einbinden eines Git-Repositorys in ein anderes. Ein Submodul speichert eine Referenz auf einen festen Commit eines externen Repositorys, was die Reproduzierbarkeit des Builds gewährleistet. Der Befehl git submodule add https://github.com/example/lib.git fügt eine externe Bibliothek als Submodul hinzu. Beim Klonen eines Projekts mit Submodulen muss git submodule update --init --recursive ausgeführt werden, um alle Abhängigkeiten herunterzuladen.