Repository in Git: Was es ist, welche Arten es gibt und wie sie funktionieren

Was ist ein Repository in Git

Git-Repository — ist eine Datenstruktur, in der das Versionskontrollsystem Metadaten und Objekte speichert, die die Historie der Dateiänderungen eines Projekts beschreiben. Wenn ein Entwickler ein Repository mit dem Befehl git init initialisiert, erstellt Git einen versteckten Ordner .git im Projektstammverzeichnis.

In diesem Ordner befinden sich alle Objekte, Referenzen und Konfigurationsdateien, die für den Betrieb des Systems erforderlich sind. Das Repository ist an keinen bestimmten Ort gebunden — der Entwickler kann es lokal erstellen und dann mit einem Remote-Server verbinden.

Git verwendet ein verteiltes Repository-Modell: Jeder Projektteilnehmer hat eine vollständige Kopie der Historie auf seinem Computer. Das bedeutet, dass die meisten Operationen — Commits, Historie anzeigen, Branches erstellen — lokal ohne Kontakt zum Server ausgeführt werden.

Laut der Git-Dokumentation macht die verteilte Architektur das System ausfallsicher: Fällt der Server aus, kann jedes lokale Repository als Quelle für die Wiederherstellung der vollständigen Projekthistorie dienen.

Lokales und entferntes Repository

Lokales Repository — ist eine Kopie des Projekts auf dem Computer des Entwicklers. Es enthält die gesamte Historie von Commits, Branches und Tags und ermöglicht die Ausführung von Commit-, Branch-, Merge- und Rebase-Operationen ohne Netzwerkverbindung.

Entferntes Repository — wird auf einem Server gehostet und dient als Synchronisationspunkt für alle Teammitglieder. Entwickler senden ihre Änderungen mit dem Befehl git push und holen Änderungen anderer mit git pull.

Die Verbindung zwischen lokalem und entferntem Repository wird über remote origin konfiguriert — die Server-URL, die in der Git-Konfiguration gespeichert ist. Ein lokales Repository kann mit mehreren entfernten Repositories verbunden sein, was bei der Arbeit mit Forks nützlich ist.

Der Hauptvorteil dieses Modells ist, dass der Entwickler offline am Code arbeiten und Änderungen erst dann synchronisieren kann, wenn er bereit ist, das Ergebnis zu senden.

Unterschiede zwischen lokalem und entferntem Repository

Wie Git Daten in einem Repository speichert

Das Speichermodell von Git unterscheidet sich grundlegend von anderen Versionskontrollsystemen. Anstatt eine Liste von Änderungen (Deltas) zwischen Versionen zu speichern, bewahrt Git vollständige Snapshots aller Projektdateien zum Zeitpunkt jedes Commits auf.

Jedes Objekt im Repository wird durch einen eindeutigen SHA-1-Hash mit 40 Zeichen identifiziert. Wenn sich der Inhalt einer Datei zwischen Commits nicht geändert hat, erstellt Git kein neues Objekt, sondern verwendet das vorhandene wieder — das spart Platz.

Git verwendet vier Objekttypen: blob (Dateiinhalt), tree (Verzeichnisstruktur), commit (Snapshot mit Metadaten) und tag (benannte Referenz auf einen Commit). Alle Objekte werden im Ordner .git/objects gespeichert.

Laut Git Internals gewährleistet das Objektmodell von Git die Datenintegrität: Jede Änderung des Dateiinhalts erzeugt einen neuen Hash, sodass eine unbemerkte Änderung der Historie unmöglich ist.

Struktur des .git-Ordners

Der .git-Ordner ist das Herz des Repositorys. Ohne ihn kann Git keine Änderungen verfolgen, und ein gewöhnliches Verzeichnis bleibt nur eine Sammlung von Dateien. Das Verständnis der Struktur dieses Ordners hilft bei der Diagnose von Repository-Problemen.

• objects/ — alle Repository-Objekte: blobs, trees, commits, tags. In komprimierter Form gespeichert.
• refs/ — Referenzen auf Commits: heads (Branches), tags (Markierungen), remotes (entfernte Branches).
• HEAD — Datei, die auf den aktuell aktiven Branch oder Commit verweist.
• config — Repository-Einstellungen: Remote-URL, Benutzername, E-Mail und andere Parameter.
• index — Staging-Area, in der Git Informationen über für den Commit vorbereitete Dateien speichert.
• logs/ — Referenzaktualisierungsprotokolle (reflog), die die Historie der HEAD- und Branch-Bewegungen speichern.

Die HEAD-Datei verdient besondere Aufmerksamkeit. Im Normalzustand enthält sie einen symbolischen Verweis auf einen Branch, z. B. ref: refs/heads/main. Im Detached-HEAD-Zustand verweist sie direkt auf einen Commit — das bedeutet, dass neue Commits an keinen Branch gebunden werden.

Grundlegende Repository-Operationen

Die Arbeit mit einem Git-Repository umfasst eine Reihe grundlegender Operationen, die der Entwickler täglich durchführt. Jede Operation ändert den Zustand des Repositorys, indem sie neue Objekte hinzufügt oder Referenzen verschiebt.

• git init — erstellt ein neues leeres Repository im aktuellen Verzeichnis. Git erstellt den .git-Ordner mit der Anfangsstruktur.
• git clone — kopiert ein vorhandenes entferntes Repository zusammen mit der gesamten Commit-Historie auf den lokalen Rechner.
• git add — fügt Dateiänderungen zur Staging-Area (Index) hinzu und bereitet sie für den Commit vor.
• git commit — erstellt einen Snapshot des Projekts basierend auf den Daten aus dem Index und speichert ihn als neues Commit-Objekt.
• git push — sendet neue Commits vom lokalen Repository an das entfernte und aktualisiert die Branches auf dem Server.
• git pull — holt neue Commits aus dem entfernten Repository und führt sie mit dem aktuellen lokalen Branch zusammen.

Die Operationen push und pull sind die einzigen, die eine Verbindung zum Remote-Server erfordern. Alle anderen Operationen werden vollständig lokal ausgeführt, was auch bei großem Historievolumen eine hohe Geschwindigkeit gewährleistet.

Lebenszyklus einer Datei im Repository

Jede Datei im Repository durchläuft vier Zustände: untracked (nicht verfolgt), modified (geändert), staged (vorbereitet) und committed (festgeschrieben). Git verfolgt nur Dateien, die explizit über git add hinzugefügt wurden oder sich bereits in der Commit-Historie befinden.

Das Verständnis dieses Modells ist der Schlüssel zur effektiven Arbeit mit Git. Der Entwickler kann selektiv nur einen Teil der geänderten Dateien für den Commit vorbereiten und logisch abgeschlossene Commits mit klarer Beschreibung erstellen.

Beliebte Plattformen zum Hosten von Repositories

Entfernte Repositories werden in der Regel auf spezialisierten Plattformen gehostet, die eine Weboberfläche, ein Zugriffsverwaltungssystem und zusätzliche Tools für die gemeinsame Entwicklung bereitstellen.

• GitHub — die größte Plattform mit über 100 Millionen Repositories. Bietet Actions, Pull Requests, Issues und Wiki. Kostenlos für öffentliche Projekte.
• GitLab — Plattform mit integrierter CI/CD, Container Registry und einer integrierten DevOps-Pipeline. Als SaaS und Self-Hosted-Version verfügbar.
• Bitbucket — Atlassian-Lösung mit Jira- und Trello-Integration. Aufgrund flexibler Zugriffseinstellungen in Unternehmensumgebungen beliebt.

Die Wahl der Plattform hängt von der Teamgröße, den Datenschutzanforderungen und den erforderlichen Integrationen ab. Für die mobile Entwicklung wird aufgrund der breiten Community-Unterstützung und der Integration mit CI/CD-Tools für iOS und Android häufig GitHub gewählt.

Befehlsbeispiele für die Arbeit mit einem Repository

Betrachten wir ein praktisches Szenario: Ein Entwickler klont ein vorhandenes Repository, erstellt einen neuen Branch, nimmt Änderungen vor und sendet sie an den Server. Jeder Befehl demonstriert die Arbeit mit verschiedenen Repository-Komponenten.

# Entferntes Repository klonen
git clone https://github.com/user/mobile-app.git

# In das Projektverzeichnis wechseln
cd mobile-app

# Neuen Feature-Branch erstellen und zu ihm wechseln
git checkout -b feature/auth

# Status der geänderten Dateien überprüfen
git status

# Alle Änderungen zur Staging-Area hinzufügen
git add .

# Commit mit Beschreibung erstellen
git commit -m "Add authentication module"

# Änderungen an das entfernte Repository senden
git push origin feature/auth

Der Befehl git status ist einer der nützlichsten im täglichen Gebrauch. Er zeigt, welche Dateien geändert wurden, welche für den Commit vorgemerkt sind und welche von Git gar nicht verfolgt werden.

Commit-Historie anzeigen

Zur Analyse der Repository-Historie wird der Befehl git log mit verschiedenen Formatierungsflags verwendet. Er zeigt die Chronologie der Commits, ihre Autoren, Daten und SHA-1-Identifikatoren an.

# Historie mit Visualisierung des Branch-Graphen anzeigen
git log --oneline --graph --all

# Änderungen in einem bestimmten Commit anzeigen
git show a1b2c3d

# Aktuellen Zustand mit dem letzten Commit vergleichen
git diff HEAD

# Historie einer bestimmten Datei anzeigen
git log --follow src/MainActivity.kt

Das Flag --graph zeigt einen ASCII-Graphen der Verzweigungen an, was besonders in Repositories mit aktiver Arbeit in mehreren Branches nützlich ist. Für mobile Projekte mit häufigen Releases hilft ein visueller Graph, die Entwicklungsstruktur schnell zu bewerten.